Re: Scare tactic?
Ivan Krsti? wrote: On Sep 19, 2007, at 5:01 PM, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. If the affected software is doing DH with a malicious/compromised peer, the peer can make it arrive at a predictable secret -- which would be known to some passive listener. But hey, if the peer is malicious or compromised to begin with, it could just as well do DH normally and explicitly send the secret to the listener when it's done. Not much to see here. I agree that this is minutia, but there is a difference. If the peer can arrange the key to be some predictable secret, it can do so without revealing itself. Eve is happy. If however it has to leak the key some other way, it needs some covert channel. This channel is the sort of thing that security reviews might more easily stumble over. E.g., IDS guy asking why these strange packets emanate from the crypto server... Which is to say, it's worth closing off this particular form of attack if it can be done without undue cost. When I did a key exchange last in a protocol design, I attempted to address it by inserting some hashing steps. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Ivan Krstic ... But hey, if the peer is malicious or compromised to begin with, it could just as well do DH normally and explicitly send the secret to the listener when it's done. Not much to see here. But it gets more interesting if the endpoints are not completely and solely controlled by Alice and Bob. Suppose the computers and communication link are protected from tampering but that interfering with the power supply sometimes produces a DH private key of 0. What about a (covert and deniable) contribution to a project? Underhanded prime selection appears in the ElGamal-RSA discussion by Piper and Stephens in ISBN 0-19-853691-7. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Sidney Markowitz wrote, On 21/9/07 8:24 AM: Ben Laurie wrote, On 21/9/07 1:34 AM: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. The without i's knowledge part is critical to the argument, as the author is assuming that entity i is monitoring all of entity j's channels of communication Curse this non-standard notation! I of course meant entity l everywhere I said entity j to keep with the original author's nomenclature. Whatever happened to Alice, Bob, and Eve? -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, 19 Sep 2007, Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. I discovered this minor weakness in most of the open source IPSec implementations in May of last year (identical checks for degenerate exponents are actually recommended in RFC2142 section 2.3.1.1). It didn't seem like this weakness could be used for much - an evil IKE endpoint could use it to force disclosure of symmetrically encrypted exchanges that were keyed from DH, but such an endpoint has a myriad of other ways they could disclose this same information. Protocols that do not perform authentication after DH (e.g. Tor) get bit much harder though. Anyway, I fixed OpenBSD's isakmpd[1], tighened the checks in OpenSSH[2] and reported the problem to the security contacts of ipsec-tools/racoon and openswan (two other open source IKE implementations). Racoon and openswan never bothered bother to fix it despite me sending a patch for racoon at least. I recall a rather bizarre conversation with an openswan developer who said he would only accept a patch if I wrote him a testcase to go with it. OTOH Racoon/ipsec-tools would benefit from the extra sanity checks that Ben Laurie added to OpenSSL for the 0.9.8a release[3], assuming it was compiled against that version or later. -d [1] http://marc.info/?l=openbsd-cvsm=114675357804837w=2 [2] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/dh.c.diff?r1=1.35r2=1.36 [3] http://cvs.openssl.org/chngview?cn=14375 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Nate Lawson [EMAIL PROTECTED] writes: All this attack allows is for one side of a DH exchange to intentionally downgrade the security, You've forgotten Hanlon's razor, Never attribute to malice that which can be adequately explained by stupidity. So the comment should really be: All this attack allows is for one side of a DH exchange to inadvertently downgrade the security, This sort of thing has happened several times in the past (with RSA, not DH in this case), one example being the CA-issued exponent-one certs that I mentioned previously, the other being an implementation that shall go unnamed that sent out plaintext because the developers didn't do key paramter validation. So the problem isn't a deliberate attack, it's screwups by people implementing or deploying the crypto. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Scare tactic?
On 19 September 2007 22:01, Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? IANAAC. I don't feel qualified to judge. Nor do I, but I'll have a go anyway. Any errors are all my own work. AIUI, the weakness is that if you control one end of the DH exchange, you can force a weak key to be selected for the subsequent encrypted exchange that an external observer can easily guess. I would summarize the main findings as: If you are one participant in a DH key exchange, it is possible for you to reveal the agreed-upon shared secret. If you pwn an IKE server, you can decrypt and read all the traffic it is exchanging with peers. The clients of that server won't know that it's giving up all their data. Whether you do it by forcing the implementation to choose a weak key, or by just revealing the information that in each situation you already have under your control, seems to me like a mere technicality. I can't envisage any situation under which this would actually *increase* your exposure. However it is an implementation flaw and should be addressed just for the sake of tying up loose ends and doing things properly. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Sep 19, 2007, at 5:01 PM, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. If the affected software is doing DH with a malicious/compromised peer, the peer can make it arrive at a predictable secret -- which would be known to some passive listener. But hey, if the peer is malicious or compromised to begin with, it could just as well do DH normally and explicitly send the secret to the listener when it's done. Not much to see here. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. It seems to me that the requirement cited: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. is generally impossible to achieve in practice. Which is lucky: otherwise DRM would work. To address their particular complaint, one of the two parties must cooperate with the passive attacker to cause key leakage. If they are prepared to cooperate then they can leak the key anyway, and no amount of testing of public keys will prevent this. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, Sep 19, 2007 at 02:01:13PM -0700, Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. I am not a cryptographer, but the article appears silly. First the verification algorithm as stated is wrong: * Verify that 2 = K_a = p - 2 * Verify that (K_a)^g = 1 (mod p) The first condition is correct, but the second is not, that g should be a q, where q is a large prime divisor of p-1 and g is chosen so that the order of g mod p is q. The correct second test just verifies that K_a is an element of order q (true for all non-trivial powers of g). Even with the verification algorithm K_a can still be equal to a small power of g, which the passive eavesdropper can quickly brute-force. In fact the entire threat model is broken, because if Alice wants Eve to be able to crack Alice's key exchange with Bob, Alice can just send Eve her secret exponent. Why waste time with weak exponents that Bob may be able to detect if he so choses? So verification of the peer exponent has nothing to do with Allice colluding with passive eavesdroppers. Rather the issue is small-subgroup attacks, which are of interest in some cases (and not applicable in others). http://tools.ietf.org/html/rfc2785 Have not looked at IKE closely enough to comment on whether small subgroups are a concern in that context. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On 9/19/07, Nash Foster [EMAIL PROTECTED] wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. It's a real (old) vulnerability in DH, but I don't think it applies here. If you want to expose the cleartext of your IPsec traffic, you can just send a copy to the observer. It makes mitm easier on unauthenticated links, but that's not a new exposure of any kind. From the article: There are a number of real-world scenarios where an unknown key-share completely undermines the legitimacy of networking infrastructure which is designed to provide high security. Funny how they didn't provide any details. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, 19 Sep 2007, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. Not a single IKE implementation [...] were validating the Diffie-Hellman public keys that I sent. There are many ways to use DH key-agreement. The one described on the page is as follows: both A and B generate random values, exponentiate, exchange results, and derive the same value. In this case there is no point validating the `public key' A receives from B: if B colludes with an attacker (and generates the key belonging to a small subgroup), then B can as well tell the final secret to the attacker. The attack would make sense if it allows B to learn a long-term secret of A, but if the `private keys' are randomly generated on each exchange, then this problem does not exist. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Peter Gutmann wrote: Nash Foster [EMAIL PROTECTED] writes: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. It's quite possible that many implementations do this. When the Mozilla folks changed their code a year or two back to reject RSA keys with an exponent of one (which in itself means that they'd been accepting those keys for years), a number of certs broke because CAs were issuing exponent-one keys, which in turn means that many other implementations that never complained about these certs were freely accepting them. Windows CryptoAPI, for example, still allows exponent-one keys as a by-design feature to allow the export of wrapped keys in plaintext form. So it's quite believable that a number of DH implementations allow bad key parameter values, and that this has been going on for years. (Even the level of validation discussed on the web page doesn't help entirely, FIPS 186 provides extra parameters that you can use for checking the key (p,q,g) while the still widely-used PKCS #3 doesn't (p,g), so even just using PKCS #3 rather than FIPS 186 is a problem). I wrote a series of articles on the problem of not verifying padding with small-exponent RSA. In the conclusion, it listed a number of well-known attacks against other public key systems, including small subgroup confinement. http://www.matasano.com/log/528/rsa-signature-forgery-explained-with-nate-lawson-part-vi/ The author of the Mu article does not list all the verification steps needed, and even seems to infer that the values g and p are negotiated between the two parties. This would be a bad idea, versus choosing a set of values that were pre-verified. This type of attack was even discussed in the realm of IPSEC back in 1997: http://www.vpnc.org/ietf-ipsec/97.ipsec/msg00629.html All this attack allows is for one side of a DH exchange to intentionally downgrade the security, but there's no reason one of them couldn't just publish the secure derived value AFTER completing the entire exchange. Or, publish their secret exponent. If this is not authenticated DH, then you have other problems. -- Nate - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Ben Laurie wrote, On 21/9/07 1:34 AM: It seems to me that the requirement cited: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. The without i's knowledge part is critical to the argument, as the author is assuming that entity i is monitoring all of entity j's channels of communication and either entity j has no communication of any kind outside of that used for the DH protocol with entity i, or else entity i would be able to recognize whether any other communication with anyone is a revelation of the secret session key that entity i is sharing with entity j. Note that entity i would even have to be sure that entity j is not using any side channels such as variations in the timing of response packets during the subsequent encrypted session to communicate with a colluding passive attacker who is eavesdropping. That is an awfully impractical constraint on the threat model, which makes this issue moot in practice. Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
