2
$\begingroup$

The official NIST publication I saw says for federal applications 3DES with three keys should be used. I have such questions:

  • what does it mean federal? Does it mean for industrial applications that requirement doesn't hold? What security do I get with 2 keys? by two keys I mean when K1==K3, but K2 is different? Is it average security?

  • Three key approach with (globally) fixed second key which is still different from each K1 and K3 pair: Imagine I have server which communicates with many clients. Is it ok if with each client i it uses distinct (K1[i],K3[i]) pairs (but K3[i]==K1[i] for each pair), and K2 I take such that it is different from each (K1[i], K3[i]) key pair in my system, but it is fixed (globally) for all clients?

EDIT: The crypto will be done by dongle so that someone will decompile my soft and get 2nd key doesn't hold as mentioned in one of the answers.

$\endgroup$
  • $\begingroup$ "Does it mean for industrial applications that requirement doesn't hold?" Well, NIST guidelines are not law... $\endgroup$ – fkraiem Feb 16 '16 at 20:04
  • $\begingroup$ @fkraiem Sorry but I didn't get what you mean $\endgroup$ – user31507 Feb 16 '16 at 20:09
  • $\begingroup$ FIPS is not mandatory to anyone other than US Government purchasers (and are, IIRC, officially encouraged for Canadian Government purchasers); it has no official power to anyone else... $\endgroup$ – poncho Feb 16 '16 at 20:11
  • $\begingroup$ @poncho Ok I understand but who will tell me if two keyed version 3DES is OK for industrial application then? Or if it gives average security? Also what about my second question? $\endgroup$ – user31507 Feb 16 '16 at 20:15
  • $\begingroup$ @user200312 "For federal use" means government officials will get in legal trouble if they fail to comply with NIST standards. You won't get in legal trouble, but you will be insecure. Just as you aren't required by law to lock your door at night, but it's recommended you do. Keying options 2 and 3 for 3DES are considered insecure for general use. $\endgroup$ – Daffy Feb 17 '16 at 3:54
3
$\begingroup$

For high security applications using 3DES, NIST recommends using keying option 1 (all keys are different). This is simply because it's the safest. For any application, keying option 1 should be used. If you set K1==K3, then you are reducing your key size to 112 bits, which is less than the smallest key size for AES. Worse still, due to cryptanalysis done on DES, setting K1==K3 (known as keying option 2), NIST has said this has an effective security of 80 bits. This is barely an improvement on plain DES.

So in short, yes, NIST claims for federal applications you should use 3 different keys. But this is true for any application.

Your second proposal has an effective security of 56 bits, which is just plain DES. A globally fixed K2 means that it has no security, and once one client is broken and decompiled (and trust me, this will happen), then they have K2 for all clients. This effectively makes it have 0 bits of security. K3, being the same as K1, also has 0 bits of security. The only security comes from K1, which is 56 bits. The EFF showed us that a 56 bit key is insecure and is susceptible to a brute force attack.

You really shouldn't be using 3DES though. It's only used in legacy applications where there are absolutely no other options. AES is currently the standard. If you must, and only if you must use 3DES, use 3 distinct keys that are randomly generated per session.

$\endgroup$
  • 1
    $\begingroup$ The view that 2-keys 3DES offer only about 80-bit security is I believe discounting the issue of memory and its bandwidth. For a discussion, see this question and tentative answer. $\endgroup$ – fgrieu Feb 16 '16 at 21:22
  • $\begingroup$ The crypto operation is done by HASP so nobody can decompile it. The server side can't be decompiled either. Can you please adapt your second part of the question based on this? $\endgroup$ – user31507 Feb 17 '16 at 6:54
  • $\begingroup$ @Daffy: Also it seems you are going against NIST by saying I can't use three key version of 3DES for MAC? Can you justify this? $\endgroup$ – user31507 Feb 17 '16 at 8:20
  • $\begingroup$ @user200312 I repeat, decompiling or reverse engineering will happen. Or at least, you should assume it will and prepare for it. And yes, I can justify it because 64-bit MACs are too small for use today. The absolute smallest in use today is 128-bits (MD5) and, while not entirely insecure when used in HMAC, is still being phased out in favor of SHA-2 (256 bit to 512 bit). So yes, 3DES is bad for use as a MAC. $\endgroup$ – Daffy Feb 17 '16 at 8:24
  • $\begingroup$ @Daffy: Why did you assume I have keys hardcoded in my app? I told you I have a dongle which does crypto - how do you decompile a dongle?? $\endgroup$ – user31507 Feb 17 '16 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy