1

I am aware that DES is considered as an insecure algorithm for encryption at the moment. So does that imply that we should stop using the class DESKeySpec in JCA for specifying a key for encryption? More specifically, is the below code snippet insecure due to the usage of DESKeySpec? If yes, why, and how should I rectify it?

public void setPassword(String p) throws FacesException {
byte\[\] s`your text`={(byte)0xA9,(byte)0x9B,(byte)0xC8,(byte)0x32,(byte)0x56,(byte)0x34,(byte)0xE3,(byte)0x03};
try {
KeySpec keySpec=new DESKeySpec(p.getBytes("UTF8"));
SecretKey key=SecretKeyFactory.getInstance("DES").generateSecret(keySpec);
e=Cipher.getInstance(key.getAlgorithm());
d=Cipher.getInstance(key.getAlgorithm());
e.init(Cipher.ENCRYPT_MODE,key);
d.init(Cipher.DECRYPT_MODE,key);
}
catch (  Exception e) {
throw new FacesException("Error set encryption key",e);
}
}
Catherine Chiramel
  • 13
  • 2

1 Answers1

1

Yes, DES is very insecure, and shouldn't be used in any new projects. Any new project should be using AES unless you have a very strong and informed reason for something else.

However, what you should do about the above code completely depends on what it's being used for. If this code is interoperating with a system that requires DES, you can't just change it without changing the other side as well. Similarly, if you have existing data encrypted in DES, you'll need a way to continue to decrypt that. You can't just swap AES for DES and have exiting encryptions continue to work. There are important systems in the world that still use DES (credit card magnetic stripes being probably the most ubiquitous).

That said, you can't just swap "AES" into the above code and have a secure cryptosystem. You need to choose a proper mode, a random IV, most likely a KDF, and some kind of authentication. Encryption algorithms like DES and AES are very low-level tools that are easy to misuse. They are just one piece of a secure cryptosystem. The proper solution depends on your specific situation, particularly what kinds of interoperability you need.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Thank you for your answer. I have a follow up question that may sound silly due to my lack of experience in cryptography. So as a rule, the class DESKeySpec from JCA is used to the specify keys for performing encryption using DES and DES algorithm only and not for any other algorithms? – Catherine Chiramel Mar 25 '22 at 14:32
  • 1
    Basically correct. If someone implemented DAA ("Data Authentication Algorithm"), they would probably also use a DESKeySpec, since DAA uses DES internally. But I don't know anything that does this. DESKeySpec is little more than a wrapper around 8 bytes and a tiny bit of metadata. https://cs.android.com/android/platform/superproject/+/master:libcore/ojluni/src/main/java/javax/crypto/spec/DESKeySpec.java But as you say, you're very unlikely to see a DESKeySpec without it being used for DES, as you see in this code (`getInstance("DES")`) – Rob Napier Mar 25 '22 at 15:06
  • 1
    BTW, this code is incredibly insecure for more reasons than DES. Its keyspace is tiny (just 8 UTF-8 encoded bytes, which is much, much smaller than the full DES keyspace, which is itself very small). And it silently truncates the password to 8 bytes without warning. This is one of the most insecure encryption functions I've ever seen. I hope it's not from live code. – Rob Napier Mar 25 '22 at 15:11
  • 1
    No. I merely took this example from a random website to demonstrate the usage of DESKeySpec in code. Thank you very much for your inputs. – Catherine Chiramel Mar 25 '22 at 16:41
  • Great. A very important lesson never to copy cryptography code from the internet. The vast majority of what you'll find is incredibly insecure. Best of luck! – Rob Napier Mar 25 '22 at 16:44
  • I agree. However, are the cryptography API documentations sufficient to produce secure code? In your opinion, what is a valid and reliable source to write secure code? I have been struggling to find correct information from the internet for a long time now when it comes to cryptography. – Catherine Chiramel Mar 25 '22 at 16:52
  • 1
    "are the cryptography API documentations sufficient to produce secure code?" Absolutely not. Almost universally, cryptography API documentation assumes the reader is well versed (if not an expert) in the subject and provides almost no guidance on correct usage. I tried to give a security novice-level introduction to the subject in this talk. https://www.softwaretalks.io/v/2629/itt-2017-rob-napier-practical-security There are also some high-level frameworks that are secure out of the box like https://www.cossacklabs.com/themis/ and https://doc.libsodium.org/secret-key_cryptography/secretbox – Rob Napier Mar 25 '22 at 17:06
  • This is really helpful. Thanks! – Catherine Chiramel Mar 25 '22 at 19:07
  • Don't forget to accept the answer if it answers the question (V mark to the left) – Maarten Bodewes Mar 26 '22 at 02:45
  • @RobNapier You mentioned UTF-8 encoded bytes in this code example is insecure. Could you tell me what is a more secure alternative for this? – Catherine Chiramel Aug 16 '22 at 09:14
  • @CatherineChiramel Random bytes. Legal UTF-8 sequences is a tiny subset of all possible sequences of bytes. Encryption keys should never be human comprehensible. They should always be completely random sequences of bytes, over the full range of 0 to 255. If you have a password (a think humans can type), you can convert it to a secure key using a PBKDF (password based key-derivation function). The most ubiquitous is PBKDF2. – Rob Napier Aug 16 '22 at 15:32