2

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.

  • "Does it mean for industrial applications that requirement doesn't hold?" Well, NIST guidelines are not law... – fkraiem Feb 16 '16 at 20:04
  • @fkraiem Sorry but I didn't get what you mean –  Feb 16 '16 at 20:09
  • 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... – poncho Feb 16 '16 at 20:11
  • @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? –  Feb 16 '16 at 20:15
  • @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. – Daffy Feb 17 '16 at 03:54

1 Answers1

3

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.

Daffy
  • 2,389
  • 17
  • 29
  • 1
    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. – fgrieu Feb 16 '16 at 21:22
  • 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? –  Feb 17 '16 at 06:54
  • @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? –  Feb 17 '16 at 08:20
  • @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. – Daffy Feb 17 '16 at 08:24
  • @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?? –  Feb 17 '16 at 08:25
  • @user200312 If anyone has public access to it (through a web service that uses it or otherwise) then it can still be reverse engineered. The point is, though, that once you have set a key to be the same across all clients, you're opening yourself up to unnecessary risk. Especially if you have the ability to generate keys on the fly (as you seem to for generating the other keys). – Daffy Feb 17 '16 at 08:30
  • @Daffy This is a dongle: https://www.google.com/search?q=dongle&ie=utf-8&oe=utf-8, how do you have access to it via web service? What do you mean? Other keys are also fixed but they are different per each client. –  Feb 17 '16 at 08:34
  • "3DES-CBC-MAC would be better if you can do that." This is a quote from your answer on my other question, did you change your mind?? –  Feb 17 '16 at 08:39
  • @user200312 It's how you're using the dongle that I'm referring to. If the keys are still different per client, then that's better. Having all clients share the same key is very dangerous, though. My argument against using 3DES for MACs is that, while it has a longer key than DES, it's block size is the same. Any (easy to implement) MACs involving 3DES will have a 64-bit output, which is too small. While not catastrophic, I'd certainly advise against it. – Daffy Feb 17 '16 at 08:40
  • @user200312 My comment before was assuming you have no other option than to use 3DES. While 3DES-CBC-MAC is better than the MAC construction you proposed, AES would still be orders of magnitude (literally) better. Again, 3DES is bad, but it isn't by itself catastrophic. – Daffy Feb 17 '16 at 08:41
  • @Daffy: I see but this is what you said in other thread: "3DES-CBC-MAC would be better if you can do that.". So I want to know how bad is it. You seem not to understand that there are some constraints from implementation point of view of choosing one algo ove another. So I need reason when discarding something like CBC MAC 3DES. For now in our system we have two 8 byte keys in system, one key is different for each client other is fixed, so I want to reuse it somehow if I go for CBC MAC 3DES –  Feb 17 '16 at 08:41
  • @Daffy: I didn't say I have option for AES yet. The problem I have now is keys. In my system I have 2 keys for each client, 8 byte keys, one is different for all clients other is fixed. How do you suggest I do with keys, if I take CBC MAC 3DES? –  Feb 17 '16 at 08:43
  • @user200312 For your scenario, it seems the best would be to use 3DES in keying option 1 (all 3 keys different), keep the keys unique per user (ideally per session), use 3DES in CBC mode for encryption, and CBC-MAC for the MAC (with a different key). AES would still be better, but if you're stuck with DES, this system is probably about as good as you can do for not much effort. It's not ideal but it's probably about "average" security. – Daffy Feb 17 '16 at 08:46
  • @Daffy: Thanks now we are on the same page. I may drop confidentiality requirement at all (otherwise I know I should not use same key for MAC and encryption). So I may only need integrity. For which I see 3DES CBC is the way now. But with different keys for each client. That is one option right? –  Feb 17 '16 at 08:59
  • @user200312 That's one way you could do it. Assuming you're alright with less than optimal security, using 3DES-CBC-MAC for integrity only should do what you want. However, I'm not sure what the implications are when you're not using encryption as well. Judging by how MACs are usually calculated on the ciphertext, it shouldn't make a difference, but I'm not completely sure. – Daffy Feb 17 '16 at 09:07
  • @Daffy: but still if K2 remains secure but fixed for all clients, what is the problem? extracting key from dongle is not possible. –  Feb 17 '16 at 15:36
  • @user200312 I don't see how it's possible for a client to both use the key and not have access to it. If a client gets access to a key, it's best to assume the user controlling the client also does. – Daffy Feb 17 '16 at 19:45
  • @Daffy the idea of dongle is that client doesn't see the key, it asks dongle to encrypt something, so the dongle does –  Feb 17 '16 at 19:46
  • Let us continue this discussion in chat. – Daffy Feb 17 '16 at 19:51