9

Can we use the 3DES algorithm for exchanging confidential information? I am using it in my project. Security code reviewer has raised a bug saying that it is not secure but I see that it is mentioned as secured in CMMI.

Ekalavya
  • 164
  • 1
  • 1
  • 9

3 Answers3

12

NIST still recognizes 3DES (ANSI X9.52-1998) as a secure symmetric-key encryption algorithm when configured to operate as described in NIST SP 800-20. There are still Cryptographic Algorithm Validation Program (CAVP) certificates issued for 3DES in 2016. However, many open source projects (e.g. OpenSSL) and international certification standards (e.g. Common Criteria) already deprecated 3DES.

The reason 3DES is being phased out is due to various vulnerabilities (e.g. collision attacks like sweet32). While there are still ways to compensate (e.g. frequent rekey, disabling CBC mode) to prolong its life, there is no good reason not to switch to AES.

So are you vulnerable RIGHT NOW? Not if you correctly implemented and configured 3DES. Should you be planning your move to AES? Absolutely! It is only matter of time until 3DES is too broken to be considered secure.

Kirill Sinitski
  • 989
  • 6
  • 12
  • 1
    3DES configurations are upto the standards. but the security analyst says that it has to be updated to AES. To do that i need to change lot of code and whole implementation changes will be there. so i am searching for a better feasible solution in less time and it should be effective. – Ekalavya Dec 29 '16 at 15:17
  • 2
    Perhaps there are other compliance issues involved? Your 3DES might be securely configured, but you need to show compliance to some standard or spec that no longer allows its use. Also, in auditing "should/must" and "recommend/area of improvement" have different meanings. Are you sure your analyst telling you you MUST switch to AES instead of simply recommending you do it? – Kirill Sinitski Dec 29 '16 at 15:24
  • 4
    Sweet32 is the big deal here; it is a practical attack against many systems which use 64-bit block ciphers (e.g. DES, 3DES) for symmetric encryption. This applies to HTTPS as well as other cryptosystems. You should also consider the meet-in-the-middle attack which requires 2^112 operations with a 2^64 block storage requirement, despite it not being particularly feasible for all but targeted attacks by nation states. – Polynomial Dec 29 '16 at 15:30
  • 3
    And I would agree with Krill here; read the pentest report. Usually it will have language such as " **recommends** that block ciphers with 64-bit block sizes are not used, and that they are replaced with larger-block ciphers such as AES." – Polynomial Dec 29 '16 at 15:31
  • @KirillSinitski as polynomial mentioned it is 64bit block cipher so i think that is causing problem. that is why the security analyst is behind me to change the implementation. so now i am going through AES and bouncycastle algorithms to replace it with strong encryption – Ekalavya Dec 30 '16 at 04:14
  • @Ravi You are doing the right thing. – Kirill Sinitski Dec 30 '16 at 13:48
  • 1
    @Ravi, maybe the reviewer raised the issue since there is no reason for using a weaker algorithm in that situation. This kind of thing should have appeared during a security design review before starting implementation. This is exactly the reason to do security reviews on architecture and design to avoid these high costs of changing the implementation. – Silver Jan 06 '17 at 15:26
3

3DES official status was downgraded by NIST in the fall of 2017. According to SP 800-67 Rev. 2, the amount of data to be encrypted by by a single, 3-key set must be limited to 8Gb. Also, the version of 3DES that uses only two unique keys is now entirely deprecated.

The suitability of an algorithm for a particular use case is determined by the strength of the algorithm, against known attacks and an estimate of how long the encryption must remain strong. 3DES strength is described based on it's effective key length of 112 bits, which is the weakest allowable symmetric encryption algorithm. Since multiple attacks have been demonstrated, it's longevity must be considered very questionable. I don't know what NIST FISMA says about this point today, but IMPO, 3DES can not be viewed as strong protection for anything that will be kept any length of time.

JaimeCastells
  • 1,156
  • 1
  • 9
  • 16
  • 1
    Where are you getting the 8Gb number in the linked document? It says (sec. 3.4, p. 12) that a single key bundle should not be used to encrypt more than 2^20 (~ a million) 64-bit blocks (8 bytes). That's 8 MiB of data. – Luis Casillas Jun 22 '18 at 23:18
2

3DES is anyways an old algorithm which has many known loopholes like slowness, meet in the middle vulnerability etc. World has adopted AES now-a-days. In short it difficult to win an argument in favour of 3DES. But, for any reason, if you have to implement it (legacy or incompatibility issues) I suggest you take a look into NIST SP 800 - 67 , this is recommendations for 3DES\3DEA check usage guidance (3.5 Usage Guidance ) and ensure that you are in sync.

Second would be have a look into "NIST Special Publication 800-57" which are recommendation for key management. NIST has approved 3DES-CBC (Cipher Block Chaining) as mentioned in this paper.

In case you want to change your cryptography library check their FIPS 140 validation status. That way you can ensure that best practices are been followed. Crypto++ as suggested by @Kirill seems to have some FIPS validation passed for some algorithms.

Shailendra Bhardwaj
  • 100
  • 4
  • Bharadwaj so now i need to change my complete algorithm which affects lot of source code. is it wise option to change the algorithm or is there any other way to make 3DES better. – Ekalavya Dec 29 '16 at 15:06
  • 4
    @Ravi DO NOT write your own crypto. Use one of the many open source cryptographic libraries that offer certified implementations. For example, Bouncy Castle or Crypto++. – Kirill Sinitski Dec 29 '16 at 15:11
  • 1
    @Ravi , personally I always encourage custom implementation because that's how you can innovate. But professionally these matters are very mathematical and complex, so people often stay away from fiddling encryption algorithms. This is a separate debate however. So no matter what you do , please ensure they are FIPS 140 compliant. Like FSecure cryptolibrary here http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp437.pdf . That way you can always take a stand on your implementations. Otherwise cryptography always invites debate – Shailendra Bhardwaj Dec 29 '16 at 16:01
  • 2
    To be fair, those that designed ASE, 3DES, etc. wrote their own crypto and it was a good idea and proper for them to do that. However, one who is not specifically skilled in cryptography shouldn't because it is highly unlikely they will develop something superior in security and the security achieved is really just by obscurity. If transitioning from 3DES to AES is deeply complex for this particular application, to me that is a code smell. While you are redesigning to accommodate AES, at the same time also factor your encryption out and have it in one place instead of many. – Thomas Carlisle Dec 29 '16 at 16:35
  • I would not say slowness is a loophole. Perhaps reword loopholes to issues? – Uncle Iroh Jan 31 '18 at 19:29