Re: [Cryptography] The paranoid approach to crypto-plumbing
On Mon, Sep 16, 2013 at 12:44 PM, Bill Frantz fra...@pwpconsult.com wrote: Symmetric encryption: Two algorithms give security equal to the best of them. Three protect against meet-in-the-middle attacks. Performing the multiple encryption at the block level allows block cyphers to be combined with stream cyphers. RC4 may have problems, but adding it to the mix isn't very expensive. A paper of mine on combining a stream cipher with a block cipher: http://eprint.iacr.org/2008/473 AES-256 uses 14 rounds vs. 10 for AES-128, so it is about 40% slower. Given 256 bits of key and a stream cipher that is 5x faster than AES, you can use AES-128 and have 128 bits to key the stream cipher. AES-128 plus whitening that changes for every block (two 128-bit blocks of stream cipher output) has roughly the same cost as AES-256. There are several ways to reduce the cost and/or increase the security from there; see the paper for details. I am still working on this notion and will have a new and much improved version of that paper sometime this year. Anyone I know moderately well who wants to review it can contact me off-list for the current draft. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
Tony Arcieri basc...@gmail.com writes: On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz fra...@pwpconsult.com wrote: After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests in the competition. Five level super encryption is probably overkill, but two or three levels can offer some real advantages. I wish there was a term for this sort of design in encryption systems beyond just defense in depth. AFAICT there is not such a term. How about the Failsafe Principle? ;) How about Stannomillinery? Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
Hi Bill, On 17/09/13 01:20 AM, Bill Frantz wrote: The idea is that when serious problems are discovered with one algorithm, you don't have to scramble to replace the entire crypto suite. The other algorithm will cover your tail while you make an orderly upgrade to your system. Obviously you want to chose algorithms which are likely to have different failure modes -- which I why I suggest that RC4 (or an extension thereof) might still be useful. The added safety also allows you to experiment with less examined algorithms. The problem with adding multiple algorithms is that you are also adding complexity. While you are perhaps ensuring against the failure of one algorithm, you are also adding a cost of failure in the complexity of melding. E.g., as an example, look at the current SSL search for a secure ciphersuite (and try explaining it to the sysadms). As soon as you add an extra algorithm, others are tempted to add their vanity suites, the result is not better but worse. And, as we know, the algorithms rarely fail. The NSA specifically targets the cryptosystem, not the algorithms. It also doesn't like well-constructed and well-implemented systems. (So before getting too exotic with the internals, perhaps we should get the basics right.) In contrast to the component duplication approach, I personally prefer the layering duplication approach (so does the NSA apparently). That is, have a low-level cryptosystem that provides the base encryption and authentication properties, and over that, layer an authorisation layer that adds any additional properties if desired (such as superencryption). One could then choose complementary algorithms at each layer. Having said all that, any duplication is expensive. Do you really have the evidence that such extra effort is required? Remember, while you're building this extra capability, customers aren't being protected at all, and are less likely to be so in the future. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On 17/09/13 01:40 AM, Tony Arcieri wrote: On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz fra...@pwpconsult.com mailto:fra...@pwpconsult.com wrote: After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests in the competition. Five level super encryption is probably overkill, but two or three levels can offer some real advantages. I wish there was a term for this sort of design in encryption systems beyond just defense in depth. AFAICT there is not such a term. How about the Failsafe Principle? ;) A good question. In my work, I've generally modelled it such that the entire system still works if one algorithm fails totally. But I don't have a name for that approach. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Sep 17, 2013, at 5:49 AM, ianG i...@iang.org wrote: I wish there was a term for this sort of design in encryption systems beyond just defense in depth. AFAICT there is not such a term. How about the Failsafe Principle? ;) A good question. In my work, I've generally modelled it such that the entire system still works if one algorithm fails totally. But I don't have a name for that approach. How about the X Property (Trust No One - with a different slant on One)? -- Jerry :-) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Mon, 16 Sep 2013 17:47:11 -0700 Bill Frantz fra...@pwpconsult.com wrote: Authentication is achieved by signing the entire exchange with DSA. -- Change the protocol to sign the exchange with both RSA and DSA and send and check both signatures. Remember to generate the nonce for DSA using a deterministic method. The current data exchange encryption uses SHA1 in HMAC mode and 3DES in CBC mode with MAC then encrypt. The only saving grace is that the first block of each message is the HMAC, which will make the known plain text attacks on the protocol harder. -- I would replace this protocol with one that encrypts twice and MACs twice. Using one of the modes which encrypt and MAC in one operation as the inner layer is very tempting with a different cypher in counter mode and a HMAC as the outer layer. I confess I'm not sure what the current state of research is on MAC then Encrypt vs. Encrypt then MAC -- you may want to check on that. Also, you may want to generate your IVs deterministically from a block cipher in counter mode, and not actually send them on the wire -- see earlier discussions for why that is good, but in addition to assuring the IVs are unpredictable and do not repeat, it prevents a bad actor from using the IV as a covert channel. (Some would argue against using CBC mode entirely -- see Rogaway's paper on block cipher modes.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On 2013-09-17 07:37, Peter Gutmann wrote: Tony Arcieri basc...@gmail.com writes: On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz fra...@pwpconsult.com wrote: After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests [...]. I wish there was a term for this sort of design in encryption systems beyond just defense in depth. AFAICT there is not such a term. How about the Failsafe Principle? ;) How about Stannomillinery? I like Stannopilosery better, but the first half is a keeper. Or, perhaps a bit incongruously, Stannopsaffery. Fun, Stephan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On 9/17/13 at 2:48 AM, i...@iang.org (ianG) wrote: The problem with adding multiple algorithms is that you are also adding complexity. ... Both Perry and Ian point out: And, as we know, the algorithms rarely fail. [but systems do] ... Absolutely! The techniques I suggested used the simplest combining function I could think of: XOR. But complexity is the mortal enemy of reliability and security. Do you really have the evidence that such extra effort is required? I don't have any evidence, which is why I included Paranoid it the message subject. I do know that NSA is well served when people believe things about cryptography which aren't true. If you believe TLS is broken[1] then you might use something much weaker in its place. If you believe AES/RSA/ECDSA etc. are strong when they aren't you will continue to rely on them. Remember, while you're building this extra capability, customers aren't being protected at all, and are less likely to be so in the future. I see this a the crux of our problem as responsible crypto people. The systems we thought were working are broken. For both professional and political reasons we need to fix them quickly. My morning paper includes the comic Non Sequitur. Today's strip has one of the regular characters being visited by two NSA agents. This story is front and center in the public's attention. There is no better time to press for whatever disruptive changes may be needed. What we need is working code we can get adopted. It can be prototype code with more complete versions to come later. But our best chance of adoption is now. On 9/17/13 at 8:54 AM, pe...@piermont.com (Perry E. Metzger) wrote: (Of course, if the endpoints are trusted hardware running a formally verified capability operating system and you still have time on your hands, hey, why not? Of course, when I posted a long message about modern formal verification techniques and how they're now practical, no one bit on the hook.) And I happen to have one in my back pocket. :-) Yes, CapROS[2] isn't proven, but it is mature enough to build Perry's household encryption box. (There are ports to both X86 and ARM. Device drivers are outside the kernel. The IP stack works. You probably don't need much more.) Any code that works in CapROS will probably port easily to a proven capability OS. [And yes Perry, I was very impressed by your arguments for program proving technology. It is a bit out of my area of expertise. But I have always thought that different ways of looking at programs can only help them be more reliable, and proving is a different way.] All that said, even I feel the temptation for low performance applications to do something like Bill Frantz suggests. It is in the nature of people in our community to like playing with such things. Just don't take them *too* seriously please. Hay, I like playing in the crypto sandbox, and redundancy is a classic technique. I have seen questions about DH -- factoring and key sizes, and EC -- cooked curves. If you worry about these issues, and don't have a third alternative, combining them seems like a good idea. [1] And TLS is big enough to share with the internet the characteristic that it can be two things. The internet is always up somewhere. Some parts of TLS are secure for certain uses. The internet is never all up. Some parts of TLS are seriously broken. [2] http://www.capros.org/ --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Sep 17, 2013, at 11:41 AM, Perry E. Metzger pe...@piermont.com wrote: I confess I'm not sure what the current state of research is on MAC then Encrypt vs. Encrypt then MAC -- you may want to check on that. Encrypt then MAC has a couple of big advantages centering around the idea that you don't have to worry about reaction attacks, where I send you a possibly malformed ciphertext and your response (error message, acceptance, or even time differences in when you send an error message) tells me something about your secret internal state. Perry --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Sep 17, 2013, at 6:21 PM, John Kelsey crypto@gmail.com wrote: I confess I'm not sure what the current state of research is on MAC then Encrypt vs. Encrypt then MAC -- you may want to check on that. Encrypt then MAC has a couple of big advantages centering around the idea that you don't have to worry about reaction attacks, where I send you a possibly malformed ciphertext and your response (error message, acceptance, or even time differences in when you send an error message) tells me something about your secret internal state. On a purely practical level, to reject a damaged message, with decrypt-then-MAC (ordering things on the receiver's side...) I have to pay the cost of a decryption plus a MAC computation; with MAC-then-decrypt, I only pay the cost of the MAC. On top of this, decryption is often more expensive than MAC computation. So decrypt-then-MAC makes DOS attacks easier. One could also imagine side-channel attacks triggered by chosen ciphertext. Decrypt-then-MAC allows an attacker to trigger them; MAC-then-decrypt does not. (Attacks on MAC's seems somewhat less likely to be data dependent, but who knows for sure. In any case, even if you had such an attack, it would get you the authentication key - and at that point you would be able to *start* your attack not the decryption key. MAC'ing the actual data always seemed more logical to me, but once you look at the actual situation, it no longer seems like the right thing to do. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Sep 17, 2013, at 7:18 PM, Jerry Leichter wrote: On Sep 17, 2013, at 6:21 PM, John Kelsey crypto@gmail.com wrote: I confess I'm not sure what the current state of research is on MAC then Encrypt vs. Encrypt then MAC -- you may want to check on that. Encrypt then MAC has a couple of big advantages centering around the idea that you don't have to worry about reaction attacks, where I send you a possibly malformed ciphertext and your response (error message, acceptance, or even time differences in when you send an error message) tells me something about your secret internal state. On a purely practical level, to reject a damaged message, with decrypt-then-MAC (ordering things on the receiver's side...) I have to pay the cost of a decryption plus a MAC computation; with MAC-then-decrypt, I only pay the cost of the MAC. On top of this, decryption is often more expensive than MAC computation. So decrypt-then-MAC makes DOS attacks easier. One could also imagine side-channel attacks triggered by chosen ciphertext. Decrypt-then-MAC allows an attacker to trigger them; MAC-then-decrypt does not. (Attacks on MAC's seems somewhat less likely to be data dependent, but who knows for sure. In any case, even if you had such an attack, it would get you the authentication key - and at that point you would be able to *start* your attack not the decryption key. People have made these attacks mildly practical (and note how old this and the cited paper are). http://kebesays.blogspot.com/2010/11/mac-then-encrypt-also-harmful-also-hard.html Dan ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On 9/17/13 at 4:18 PM, leich...@lrw.com (Jerry Leichter) wrote: MAC'ing the actual data always seemed more logical to me, but once you look at the actual situation, it no longer seems like the right thing to do. When I chose MAC then encrypt I was using the MAC to check the crypto code. CRC would have worked too, but the MAC was free. (I really don't trust my own code very much.) Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
For hash functions, MACs, and signature schemes, simply concatenating hashes/MACs/signatures gives you at least the security of the stronger one. Joux multicollisions simply tell us that concatenating two or more hashes of the same size doesn't improve their resistance to brute force collsion search much. The only thing you have to be sure of there is that the MAC and signature functions aren't allowed access to each others' secret keys or internal random numbers. Otherwise, MAC#1 can always take the value of MAC#2's key. This is just message, signature 1, signature 2 where the signatures are over the message only. For encryption algorithms, superencryption works fine. You can first encrypt with AES-CBC, then encrypt with Twofish-CFB, then with CAST5 in CFB mode. Again, assuming you are not letting the algorithms know each others' internal state or keys, if any of these algorithms are resistant to chosen plaintext attacks, then the combination will be. This doesn't guarantee that the combination will be any stronger than the strongest of these, but it will be no weaker. (Biham and later Wagner had some clever attacks against some chaining modes using single-DES that showed that you wouldn't always get anything stronger than one of the ciphers, but if any of these layers is strong, then the whole encryption is strong. An alternative approach is to construct a single super-block-cipher, say AES*Twofish*SERPENT, and use it in a standard chaining mode. However, then you are still vulnerable to problems with your chaining mode--the CBC reaction attacks could still defeat a system that used AES*Twofish*SERPENT in CBC mode, but not AES-CBC followed by Twofish-CFB followed by SERPENT-CTR. For key-encryption or transport, I think it's a little more complicated. If I need six symmetric keys and want to use three public key methods (say ECDH, NTRU, RSA) to transport the key, I've got to figure out a way to get the benefit from all these key exchange mechanisms to all six symmetric keys, in a way that I'm sure will not leak any information about any of them. Normally we would use a KDF for this, but we don't want to trust any one crypto algorithm not to screw us over. I think we can get this if we assume that we can have multiple KDFs that have secrets from one another. That is, I compute KDF1( key1, combined key exchange input) XOR KDF2( key2, combined key exchange input) The reason the two KDFs need keys that are secret from each other is because otherwise, KDF1 could just duplicate KDF2 and we'd get an all-zero set of keys. If KDF2 is strong, then KDF1 can't generate an output string with any relationship to KDF2's string when it doesn't know all the input KDF2 is getting. I agree with Perry that this is probably padlocking a screen door. On the other hand, if we want to do it, we want to make sure we guard against as many bad things as possible. In particular, it would be easy to do this in such a way that we missed chaining mode/reaction type attacks. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
Arggh! Of course, this superencryption wouldn't help against the CBC padding attacks, because the attacker would learn plaintext without bothering with the other layers of encryption. The only way to solve that is to preprocess the plaintext in some way that takes the attacker's power to induce a timing difference or error message away. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] The paranoid approach to crypto-plumbing
After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests in the competition. Five level super encryption is probably overkill, but two or three levels can offer some real advantages. So consider simple combinations of techniques which are at least as secure as the better of them. Unguessable (aka random) numbers: Several generators, each reseeded on its own schedule, combined with XOR will be as good as the best of them. Symmetric encryption: Two algorithms give security equal to the best of them. Three protect against meet-in-the-middle attacks. Performing the multiple encryption at the block level allows block cyphers to be combined with stream cyphers. RC4 may have problems, but adding it to the mix isn't very expensive. Key agreement: For forward security, using both discrete log and elliptic curve Diffie-Hellman modes combined with XOR to calculate keying material is as good as the better of them. Encrypting a session key with one public key algorithm and then encrypting the result with another algorithm has the same advantage for the normal mode of TLS key agreement if you don't want forward security (which I very much want). MACs: Two MACs are better than one. :-) All this has costs, some of them significant, but those costs should be weighted against the security risks. Introducing a new algorithm with interesting theoretical security properties is a lot safer if the data is also protected with a well-examined algorithm which does not have those properties. Cheers - Bill (who has finally caught up with the list) --- Bill Frantz| Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On 9/16/13 at 12:36 PM, leich...@lrw.com (Jerry Leichter) wrote: On Sep 16, 2013, at 12:44 PM, Bill Frantz fra...@pwpconsult.com wrote: After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests in the competition. Five level super encryption is probably overkill, but two or three levels can offer some real advantages. So consider simple combinations of techniques which are at least as secure as the better of them This is trickier than it looks. Joux's paper Multicollisions in iterated hash functions http://www.iacr.org/archive/crypto2004/31520306/multicollisions.ps shows that finding ... r-tuples of messages that all hash to the same value is not much harder than finding ... pairs of messages. This has some surprising implications. In particular, Joux uses it to show that, if F(X) and G(X) are cryptographic hash functions, then H(X) = F(X) || G(X) (|| is concatenation) is about as hard as the harder of F and G - but no harder. That's not to say that it's not possible to combine multiple instances of cryptographic primitives in a way that significantly increases security. But, as many people found when they tried to find a way to use DES as a primitive to construction an encryption function with a wider key or with a bigger block size, it's not easy - and certainly not if you want to get reasonable performance. This kind of result is why us crypto plumbers should always consult real cryptographers. :-) I am not so much trying to make the construction better than the algorithms being used, like 3DES is much more secure than 1DES, (and significantly extended the useful life of DES); but to make a construction that is at least as good as the best algorithm being used. The idea is that when serious problems are discovered with one algorithm, you don't have to scramble to replace the entire crypto suite. The other algorithm will cover your tail while you make an orderly upgrade to your system. Obviously you want to chose algorithms which are likely to have different failure modes -- which I why I suggest that RC4 (or an extension thereof) might still be useful. The added safety also allows you to experiment with less examined algorithms. Cheers - Bill --- Bill Frantz|The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345 Englewood Ave www.pwpconsult.com |from. - Andrew Tanenbaum| Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Mon, Sep 16, 2013 at 9:44 AM, Bill Frantz fra...@pwpconsult.com wrote: After Rijndael was selected as AES, someone suggested the really paranoid should super encrypt with all 5 finalests in the competition. Five level super encryption is probably overkill, but two or three levels can offer some real advantages. I wish there was a term for this sort of design in encryption systems beyond just defense in depth. AFAICT there is not such a term. How about the Failsafe Principle? ;) -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Sep 16, 2013, at 6:20 PM, Bill Frantz wrote: Joux's paper Multicollisions in iterated hash functions http://www.iacr.org/archive/crypto2004/31520306/multicollisions.ps shows that finding ... r-tuples of messages that all hash to the same value is not much harder than finding ... pairs of messages. This has some surprising implications. In particular, Joux uses it to show that, if F(X) and G(X) are cryptographic hash functions, then H(X) = F(X) || G(X) (|| is concatenation) is about as hard as the harder of F and G - but no harder. This kind of result is why us crypto plumbers should always consult real cryptographers. :-) Yes, this is the kind of thing that makes crypto fun. The feeling these days among those who do such work is that unless you're going to use a specialized combined encryption and authentication mode, you might as well use counter mode (with, of course, required authentication). For the encryption part, counter mode with multiple ciphers and independent keys has the nice property that it's trivially as strong as the strongest of the constituents. (Proof: If all the ciphers except one are cracked, the attacker is left with a known-plaintext attack against the remaining one. The need for independent keys is clear since if I use two copies of the same cipher with the same key, I end up sending plaintext! You'd need some strong independence statements about the ciphers in the set if you want to reuse keys. Deriving them from a common key with a one-way hash function is probably safe in practice, though you'd now need some strong statements about the hash function to get any theoretical result. Why rely on such things when you don't need to?) It's not immediately clear to me what the right procedure for multiple authentication is. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On Mon, Sep 16, 2013 at 4:02 PM, Jerry Leichter leich...@lrw.com wrote: On Sep 16, 2013, at 6:20 PM, Bill Frantz wrote: Joux's paper Multicollisions in iterated hash functions http://www.iacr.org/archive/crypto2004/31520306/multicollisions.ps shows that finding ... r-tuples of messages that all hash to the same value is not much harder than finding ... pairs of messages. This has some surprising implications. In particular, Joux uses it to show that, if F(X) and G(X) are cryptographic hash functions, then H(X) = F(X) || G(X) (|| is concatenation) is about as hard as the harder of F and G - but no harder. This kind of result is why us crypto plumbers should always consult real cryptographers. :-) Yes, this is the kind of thing that makes crypto fun. The feeling these days among those who do such work is that unless you're going to use a specialized combined encryption and authentication mode, you might as well use counter mode (with, of course, required authentication). For the encryption part, counter mode with multiple ciphers and independent keys has the nice property that it's trivially as strong as the strongest of the constituents. (Proof: If all the ciphers except one are cracked, the attacker is left with a known-plaintext attack against the remaining one. The need for independent keys is clear since if I use two copies of the same cipher with the same key, I end up sending plaintext! You'd need some strong independence statements about the ciphers in the set if you want to reuse keys. Deriving them from a common key with a one-way hash function is probably safe in practice, though you'd now need some strong statements about the hash function to get any theoretical result. Why rely on such things when you don't need to?) It's not immediately clear to me what the right procedure for multiple authentication is. -- Jerry The right procedure would be to use a universal hash function together with counter mode encryption. This has provable security relatable to the difficulty of finding linear approximations to the encryption function. But I personally don't think this is much use. We have ciphers that have stood up to lots of analysis. The real problems have been in modes of operation, key negotiation, and deployment. Sincerely, Watson Ladd ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety. -- Benjamin Franklin ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The paranoid approach to crypto-plumbing
On 9/16/13 at 4:02 PM, leich...@lrw.com (Jerry Leichter) wrote: The feeling these days among those who do such work is that unless you're going to use a specialized combined encryption and authentication mode, you might as well use counter mode (with, of course, required authentication). For the encryption part, counter mode with multiple ciphers and independent keys has the nice property that it's trivially as strong as the strongest of the constituents. (Proof: If all the ciphers except one are cracked, the attacker is left with a known-plaintext attack against the remaining one. Let me apply the ideas to the E communication protocol http://www.erights.org/elib/distrib/vattp/index.html. The code is available on the ERights site http://www.erights.org/. Cutting out the details about how IP addresses are resolved, the initiator sends a series of messages negotiating the details of the connection and uses Diffie-Hellman for session key agreement. -- Change the protocol to use both discrete log and elliptic curve versions of Diffie-Hellman, and use the results of both of them to generate the session key. I would love to have a key agreement algorithm other than Diffie-Hellman to use for one of the two algorithms to get a further separation of failure modes. Authentication is achieved by signing the entire exchange with DSA. -- Change the protocol to sign the exchange with both RSA and DSA and send and check both signatures. In all cases, use algorithm bit lengths acceptable by modern standards. The current data exchange encryption uses SHA1 in HMAC mode and 3DES in CBC mode with MAC then encrypt. The only saving grace is that the first block of each message is the HMAC, which will make the known plain text attacks on the protocol harder. -- I would replace this protocol with one that encrypts twice and MACs twice. Using one of the modes which encrypt and MAC in one operation as the inner layer is very tempting with a different cypher in counter mode and a HMAC as the outer layer. The need for independent keys is clear since if I use two copies of the same cipher with the same key, I end up sending plaintext! You'd need some strong independence statements about the ciphers in the set if you want to reuse keys. Deriving them from a common key with a one-way hash function is probably safe in practice, though you'd now need some strong statements about the hash function to get any theoretical result. Why rely on such things when you don't need to?) I'm not sure you can avoid that one-way hash function in practice. Either it will be distilling randomness in your RNG or it will be stretching the pre-master secret in your key/IV/etc generation. You could use several and XOR the results if you can prove that their outputs are always different. It's not immediately clear to me what the right procedure for multiple authentication is. The above proposal uses two different digital signature algorithms, sends both, and checks both. I think it meets the no worse than the best of the two test. Cheers - Bill --- Bill Frantz|We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.pwpconsult.com | learned anything about security? -- Bruce Schneier ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
