Re: [cryptography] the spell is broken
On 3/10/13 01:23 AM, Jon Callas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 2, 2013, at 12:26 PM, coderman coder...@gmail.com wrote: On Wed, Oct 2, 2013 at 10:38 AM, Jared Hunter feralch...@gmail.com wrote: Aside from the curve change (and even there), this strikes me as a marketing message rather than an important technical choice. The message is we react to a deeper class of threat than our users understand. it is simpler than that. to signal integrity, and provide assurance, it is common not just to avoid impropriety, but to avoid the _appearance_ of impropriety. this change, while not materially affecting security (the weakest link in SilentCircle was never the crypto) succeeds in conveying the message of integrity as paramount. so yes, a marketing message, but a simple one. i have no problem with this as long as they're not implying that AES or SHA-2 are broken in some respect. Thank you very much for that assessment. I'm not implying at all that AES or SHA-2 are broken. If P-384 is broken, I believe the root cause is more that it's old than it was backdoored. But it doesn't matter what I think. This is a trust issue. A friend of mine offered this analogy -- what if it was leaked that the government replaced all of a vaccine with salt water because some nasty jihadis get vaccinated. This is serious and pretty horrifying. If you're a responsible doctor, and source your vaccines from the same place, even if you test them yourself you're stuck proving a negative and in a place where stating the negative can look like you're part of the conspiracy. Right, good analogy. Proving the negative is the trap that google, Apple, Facebook, etc are in. I see this as a way out of the madness. Yes, it's marketing if by marketing you mean non-technical. By pushing this out, we're letting people who believe there's a problem have a reasonable alternative. I would say it is risk management. As you say, we no longer have confidence in proving the negative because we are faced with a confirmed positive. Over on the other list, I thought about it more, and came to these conclusions: 1. the interference happened. 2. a key component was the perversion of a cryptography supplier. 3. NSA can influence suppliers that export and those that are large government contractors. 4. Therefore we can no longer have the confidence (prove the negative) in US exporters of crypto. 5. Avoid all USA crypto. This is far worse than BSAFE or NIST -- failure of confidence impacts Java's JCA and Microsoft's CAPI. Questions have even been raised about Linux's RNG. Which means most everyone in the application world is in trouble deep. If we, the crypto community, decide that the P-384+AES+SHA2 cipher suite is just fine, we can walk the decision back. It's just a software change. I have faith in AES. I played a small part in the project, it went well. We didn't need to change our Rijndael code at all, just rename it to AES. I have faith in SHA1, SHA2, and SHA3. They play relatively non-delicate parts in properly designed protocols, and their margin of safety is proven in the MD5/SHA1 history. PK algorithms are a different story... I certainly agree that choosing NIST EC curves raises questions about your entire process. Not for the American market, but the world market. Let me also add that I wouldn't fault anyone for deciding differently. We, the crypto community, need to work together with security and respecting each other's decisions even if we make different decisions and do different things. I respect the alternate decision, to stay the course. Dark clouds ahead. It's back to 1990s. I don't think they really had a grip on how much damage they could do. I wonder if NIST has a grip on how to recover this situation? iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On Wed, Oct 2, 2013 at 5:49 PM, James A. Donald jam...@echeque.com wrote: ... So, people who actually know what they are doing are acting as if they know, or have good reason to suspect, that AES and SHA-2 are broken. James this is not true. i challenge you to find reputable positions backing this assertion. where know what they are doing and reputable mean cryptographers who design and implement block ciphers and secure digests. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2/10/13 20:38 PM, Jared Hunter wrote: Aside from the curve change (and even there), this strikes me as a marketing message rather than an important technical choice. The message is we react to a deeper class of threat than our users understand. There is a wider concept here. The NSA has done stuff. Are we going to sit around and accept it? RSA did. They accepted what they were told by NIST and by their government purchasing contacts, without challenge. They ignored the warnings from the cryptographers. Now look where that got that them. Remember Arthur Anderson? The signal of the conviction in court collapsed the oldest most respected audit firm within weeks. That's what RSA is facing... Fair enough, but I'd hardly stop using AES or the larger SHA-2 variants on the back of recent news. So a supplier of integrity is also faced with a much wider question. It isn't just whether AES is scrunched or SHA-2 is fleeced. It's about who the supplier trusts and who the supplier is perceived to trust. In distancing itself from NIST in as many ways as it can think of, Silent Circle is saying we call the shots in our products. The upshot here is that some companies of good product are going to respond, and they are going to punish NIST and RSA and other suppliers by various and many means. Or, they are not. Which says what? Signals matter in security, we've got precious little else we can do with the security business than send out the right signals, because for the most part, our product can't be audited, can't be verified, and must be relied upon, without any foundation of trust except these are the good guys. Where do you stand? What signal do you send? iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-03 19:16, coderman wrote: On Wed, Oct 2, 2013 at 5:49 PM, James A. Donald jam...@echeque.com wrote: ... So, people who actually know what they are doing are acting as if they know, or have good reason to suspect, that AES and SHA-2 are broken. James this is not true. i challenge you to find reputable positions backing this assertion. where know what they are doing and reputable mean cryptographers who design and implement block ciphers and secure digests. http://silentcircle.wordpress.com/2013/09/30/nncs/ Jon Callas is a cryptographer who designs and implements block ciphers and secure digests - the skein hash and three fish. He does not believe that AES and SHA-2 rest are necessarily broken - but neither does he believe that they are not broken. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On Thu, Oct 3, 2013 at 4:28 AM, James A. Donald jam...@echeque.com wrote: ... He does not believe that AES and SHA-2 rest are necessarily broken - but neither does he believe that they are not broken. there is a significant difference between avoiding a cipher on principle, or association, or abundance of caution, or to avoid proving a negative, and avoiding a cipher because it is broken. perhaps i am being pedantic, but the details matter! the subterfuge and fail associated with Dual_EC_DRBG is a league apart from the lack of transparency around P-192 to P-521 curves/constants which in turn is entirely different from the meddling in cryptographic protocols like IPsec and SSL/TLS which is in turn very different from secret back|bugdoors in specific vendor cryptographic products and implementations, and so forth. this is complex; too often simplified to ingenuous elliptic curves are broken or NIST approved systems are backdoor'ed or AES and SHA-2 are broken. please don't propagate mis-information and mis-understanding via careless terms and qualifiers; we have paid professionals in the intelligence community for that! ;) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-03 21:56, coderman wrote: On Thu, Oct 3, 2013 at 4:28 AM, James A. Donald jam...@echeque.com wrote: ... He does not believe that AES and SHA-2 rest are necessarily broken - but neither does he believe that they are not broken. there is a significant difference between avoiding a cipher on principle, or association, or abundance of caution, or to avoid proving a negative, and avoiding a cipher because it is broken. To avoid proving a negative Means to avoid the need to prove it is not broken And why do we need to prove it is not broken? Because we do not trust the people who issued it. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
On 02/10/13 at 08:51am, Florian Weimer wrote: There is widespread belief that compressing before encrypting makes cryptanalysis harder, so compression is assumed to be beneficial. Any academic references? Applied Cryptography (2nd edition) contains this: | 10.6 Compression, Encoding, And Encryption | | Using a data compression algorithm together with an encryption | algorithm makes sense for two reasons: | | Cryptanalysis relies on exploiting redundancies in the plaintext; | compressing a file brfore encryption reduces these redundancies. | | Encryption is time-consuming; compressing a file before encryption | speeds up the process. | | The important thing to remember is to compress before encryption. […] Schneier doesn't cite any references for these claims, unfortunately. Bergen and Hogan, A Chosen Plaintext Attack on an Adapative Arithmetic Coding Compression Algorithm (2002) cite Witten and Cleary, On the privacy afforded by Adaptive Text Compression (1988) and Jones, An efficient coding system for long source sequences (1981). Neither paper appears to be available on the public Internet. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
Well I think there are two issues: 1. if the public key is derived from a password (like a bitcoin brainwallet), or as in EC based PAKE systems) then if the point derived from your password isnt on the curve, then you know that is not a candidate password, hence you can for free narrow the password search. (Which particularly for PAKE systems weakens their security). 2. if the software doesnt properly validate that the point is on the curve, and tries to do an operation involving a private key or secret, anyway, it may leak some of the secret. DJB has some slides saying he found some software does not check. This is what elligator is about, a more deterministic way to hash keys to curves. Which is an improvement with a more friendly curve to the approach used by eg http://tools.ietf.org/html/draft-harkins-tls-pwd-03 where the way you do it is x = hash2curve( password, counter ), test (x,y) on curve, start counter at 0, and repeat until the point is on the curve. Thats bad because you have to do it lots of times, to be fairly sure it'll work its timing dependent so that leaks password entropy etc. Its much easier to aim for constant time with elligator technique and curves. Adam On Thu, Oct 03, 2013 at 02:41:30PM +0100, Michael Rogers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/09/13 20:24, Nico Williams wrote: Just because curve25519 accepts every 32-byte value as a public key doesn't mean that every 32-byte value is a valid public key (one resulting from applying the curve25519 operation). The Elligator paper discusses several methods for distinguishing valid public keys from random. On 30/09/13 05:55, Trevor Perrin wrote: Phrasing this better: check that x^3 + 486662x^2 + x is a square modulo 2^255-19 Thanks Nico and Trevor for your replies. If I understand right, you're both pointing to the most severe distinguisher in section 1.1 of the Elligator 2 paper. I'm afraid I still don't understand what it means for curve25519 to accept a string as a public key if that string isn't a valid public key. Does it just mean that the function has a defined output for that input, even though that output isn't cryptographically useful? Silently accepting invalid input and producing useless output seems like a bug rather than a feature, so I feel like I must still be misunderstanding the real meaning of accepts. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTXQKAAoJEBEET9GfxSfMIJkH/jmClrIJ6kD3D/h5MMf7cvIp BVLMmGROGwIFhIrfFZwfqEFGQzBZNpMP06BYJsyPbMRf1uLxFixIYHhSYXCcA+IJ ZvcLMkMptNVb2xPr9jkdC3tXd47udo23Pxo8pP3uo0i265TMkdNOyY4WwJlrnCGQ B7FDXeNXRAtNxdbfrFR2hpCd6yyVk+rqDl3AxNCQ01Slf8HmfOKtcZu7WHHwxQFZ 4ECVtlQmdcAaO8JiNdhWzyzbFW7GEEzvCdzYl3hZTqyXfXM+asGFw90K4qXKAoZS l3S7Q5Pl7tg0KxDL6iHz0XVUMpxH31Mac09DM+dZWT9hp7PEFWiF79XzD0AGi+4= =qqWu -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/09/13 23:40, Trevor Perrin wrote: It'd be nice if Alice and Carol could use some additional, out-of-band channel to authenticate the ephemeral DH exchange. To fill in some background: the use case for this feature is introducing two people who aren't face-to-face right now and don't share an authenticated channel, but who each share a confidential and authenticated channel with a third party. Users aren't assumed to know which channels are confidential or authenticated, so we shouldn't create any opportunities for mistakes in that regard. I think that rules out PAKE. Best I can think of are short auth strings (SAS), public-key fingerprints (if you added long-term identity keys), and PAKE. The tradeoffs are something like: * Key fingerprints and SAS are non-secret (unlike PAKE passwords) * SAS and PAKE can use short strings of several chars (unlike fingerprints) * Fingerprints can be exchanged before *or* after the ephemeral DH handshake (unlike PAKE passwords or SAS) * Fingerprints can be confirmed with 3rd parties or public records (unlike PAKE passwords or SAS) * Fingerprints and PAKE can be compatible with a single, unordered handshake exchange of ephemeral DH values, unlike SAS Thanks, this is a really useful comparison. Perhaps we can combine some of the advantages of fingerprints and SAS: * The introducees exchange single-use public keys, signed with their long-term private keys, via the introducer * The introducees derive a shared secret, destroy their single-use private keys, and start key rotation * The introducees exchange acks via the introducer * The introducees can optionally obtain each other's long-term public keys from other third parties, before or after the introduction * If the introducees meet face-to-face, they can confirm each other's long-term public keys using SAS: - The users verbally exchange short codes to enable their devices to find each other over a short-range transport such as wifi - The devices exchange hash commitments and ephemeral public keys - The users verbally exchange short authentication strings - If the strings match, the devices derive symmetric encryption and authentication keys from the ephemeral shared secret - Within the ephemeral secure channel, the devices exchange long-term public keys and a value derived from the current temporary secret, signed with their long-term private keys, as verification that they own those keys and have the same shared secret * Nobody signs anything that proves who their contacts are Any thoughts on cryptographic or usability aspects? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTYr1AAoJEBEET9GfxSfMYx8H/0RxYl3gEqu7KUz/D5053o2T 2cZIUopdSiZs6SYH2gnTzrGPXAyd3xvGMmTFKV40EAWdix1+ZHpg6fs1i7wWZ6Q9 NbUNX5C1L8hbmMI4aK0ebq69J54N/iZqiQte/utQ3fwjq28U0xARuwq5VqPuJRlS 2TGt5tZG9tN5vAtb3R8I94OGwpF1PwFYEpUlyhG7LRRSoQBV5Xw5QwDaf7VKkeBM UoZ6JlAjI0wl17U01E6dYHmZpcq10EZ+BTomD+Kw1lioPGj15S97a4odOo0y2gd+ 0uW+yXoVRhRO4Hq2f9HPfMhoNE34eXt9ube1a6PrOmXMT2Dan/g10cVSOowZRMw= =O6PJ -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
On Thu, Oct 3, 2013 at 6:41 AM, Michael Rogers mich...@briarproject.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/09/13 20:24, Nico Williams wrote: Just because curve25519 accepts every 32-byte value as a public key doesn't mean that every 32-byte value is a valid public key (one resulting from applying the curve25519 operation). The Elligator paper discusses several methods for distinguishing valid public keys from random. On 30/09/13 05:55, Trevor Perrin wrote: Phrasing this better: check that x^3 + 486662x^2 + x is a square modulo 2^255-19 Thanks Nico and Trevor for your replies. If I understand right, you're both pointing to the most severe distinguisher in section 1.1 of the Elligator 2 paper. Yes. I'm afraid I still don't understand what it means for curve25519 to accept a string as a public key if that string isn't a valid public key. Suppose you are a good guy with a static curve25519 key, and a bad guy is sending you 32-byte strings, claiming them to be ephemeral curve25519 public keys for use in an ephemeral-static Diffie-Hellman. You repeatedly perform your side of the ephemeral-static DH. I.e., you perform a curve25519 operation betweeen the bad guy's alleged ephemeral public key and your private key. After each DH, you give the bad guy, say, some MAC based on the Diffie-Hellman result. At issue is whether this is safe without checking that the bad guy's strings correspond to possible public keys. And it is, with curve25519! But with some other curves, it isn't. In particular, if the bad guy's public key can have small order (eg generates a group with, say, 7 elements), then the resulting DH shared-secret will be confined to 7 values. The bad guy can easily test all 7 values for the MAC key, thus learning the value of your private key modulo 7. By repeating this with other public keys of small order, and using the Chinese Remainder Theorem, the bad guy could solve for your private key. Curve25519 prevents this without requiring an explicit check. See discussion of twist and small-subgroup attacks in the Curve25519 paper for more: http://cr.yp.to/ecdh/curve25519-20060209.pdf Trevor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/13 15:14, Adam Back wrote: Well I think there are two issues: 1. if the public key is derived from a password (like a bitcoin brainwallet), or as in EC based PAKE systems) then if the point derived from your password isnt on the curve, then you know that is not a candidate password, hence you can for free narrow the password search. (Which particularly for PAKE systems weakens their security). Presumably if you ensure that the private key is valid, the public key derived from it must be a point on the curve. So it's a matter of validating private rather than public keys. I understand what you're saying about a timing side-channel in the draft-harkins-tls-pwd approach, but here I'm not concerned with validating a public key after generating it, but rather with the puzzling statement that there's no need to validate a public key after receiving it: How do I validate Curve25519 public keys? Don't. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys. http://cr.yp.to/ecdh.html#validate 2. if the software doesnt properly validate that the point is on the curve, and tries to do an operation involving a private key or secret, anyway, it may leak some of the secret. DJB has some slides saying he found some software does not check. Hmm, so perhaps the statement quoted above simply means Curve25519 contains its own key validation code, and will complain if the string you give it isn't a valid public key? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTZLlAAoJEBEET9GfxSfM4dMH/jo83Jse5V6DqnZwaIkNesLY AufH8+amkMALbO8Db7r/sG+cGXMy8sSRWqPTJ0jXd3z4ZAgKbx3aW2eBEmIU9i3Y K0jkABVJty3XyvPAspoCUwZ+Fh7brUSCRHQJt0MWMQADPdoXJUY+iobmCGgO4Qbk +npDlo3pTNeEofsvkEM3uSPofR88JXvMC1sYhGr4+GMsBt330vG2Zd278AlVTlOb fVpwEtlad5Fb58RfGidMb4n7BUKKmkPI3KJewpJEXfc8CMP1ITsmX8hTzIz0wakz ubjwDu7ENUMkZhfkt4qNpTLeWQBOFrrfUDe9qrlTY5GpbNfy295K/aWMvi65c6g= =sxPV -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On Oct 2, 2013, at 6:23 PM, Jon Callas j...@callas.org wrote: [snipped quoted text] I'm not implying at all that AES or SHA-2 are broken. If P-384 is broken, I believe the root cause is more that it's old than it was backdoored. But it doesn't matter what I think. This is a trust issue. First, thanks for providing more insight into the decision here. I guess my point was that it's a confluence of trust issues: user trust, business stakeholder trust, and technical/cryptographic trust. And in part because it does matter what you think, relatively informed people have drawn strong and variable conclusions from the news that Silent Circle ditched AES and SHA-2 in favor of Twofish and Skein. [snipped interesting doctor analogy; Jeffrey's response to it was solid.] I see this as a way out of the madness. Yes, it's marketing if by marketing you mean non-technical. By pushing this out, we're letting people who believe there's a problem have a reasonable alternative. If we, the crypto community, decide that the P-384+AES+SHA2 cipher suite is just fine, we can walk the decision back. It's just a software change. I didn't mean marketing as a pejorative or as 'non-technical', but as a blend of brand signaling and (highly technical, in this case) product management in response to user demand. To that, and on positioning Twofish/Skein as an alternative: - Did users of Silent Circle threaten to leave if you stuck with AES and SHA-2? - Can users of Silent Circle choose to continue using AES and SHA-2? While it may be easy to roll back this software change in the future, wouldn't switching back be even more problematic (signaling-wise) than switching away? One of the biggest issues we're wrestling with, I think, is that the crypto community already decided that AES and SHA-2 are just fine. From where implementors are sitting, it decided good and hard. So what now? a) Maybe some new process will re-validate AES and SHA-2. The peer review will somehow get peer-ier or review-ier, and the NSA has magic math meme will suffer. - AND/OR - b) Celebrity cryptographers will make pronouncements that will enjoy uptake among implementors and their trusted advisors. The Silent Circle decision encourages NSA has magic thinking, and unintentionally promotes [b]. And maybe NSA does have anti-AES magic. But if they do, we've seen zero evidence that they're using it. Are they just rooting boxes, forcing people to give up private keys, and sabotaging RNGs as a smoke screen or performance optimization? Let me also add that I wouldn't fault anyone for deciding differently. We, the crypto community, need to work together with security and respecting each other's decisions even if we make different decisions and do different things. I respect the alternate decision, to stay the course. Jon Interesting times. Thanks again- -Jared ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/13 16:45, Trevor Perrin wrote: Suppose you are a good guy with a static curve25519 key, and a bad guy is sending you 32-byte strings, claiming them to be ephemeral curve25519 public keys for use in an ephemeral-static Diffie-Hellman. You repeatedly perform your side of the ephemeral-static DH. I.e., you perform a curve25519 operation betweeen the bad guy's alleged ephemeral public key and your private key. After each DH, you give the bad guy, say, some MAC based on the Diffie-Hellman result. At issue is whether this is safe without checking that the bad guy's strings correspond to possible public keys. And it is, with curve25519! Thanks! I think I finally understand what it means to say that all 32-byte values are allowed as public keys but not all are valid public keys. Sorry for taking so many round-trips. :-) Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTZXwAAoJEBEET9GfxSfMUQ4H/R+89hfxD8Wy8wjPt8Bj7gsx rLLquJlvVqlvWqAGXzZcW/zkiqqb8nR5fCU+J5d8dAdB9M1J6AAJC10sDMoj+5/z vIQMBIO+9W28bhaQbb3cWLsaG+tI4Uo/rkZrEPVkBvELXq33fBNjFd4VZFcNUX63 0ZZQwYZ08JzoDtOAIKLHjHq3xEkwi2a5TDGwQMy2p5KUmSf1kIRdyQIMMGoGmKua KWtnfbeledr65+iqFIYyZlntMeMxSrgIJ0CRnjk09sqbkkjz8Pzau4/JEcuLBYhd uJb7y73L2OdKjzWVdYWjLhThKDPnVOf3FVX6CHP121YxBa7zmEYxhhOmpBNOPqc= =PH7z -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Thu, Oct 3, 2013 at 8:19 AM, Michael Rogers mich...@briarproject.orgwrote: Perhaps we can combine some of the advantages of fingerprints and SAS: Sure, and I should point out that fingerprints, SAS, and PAKE could all be done in parallel. For example, OTR offers all three (session IDs = SAS; Socialist Millionaire's Protocol = PAKE). * The introducees exchange single-use public keys, signed with their long-term private keys, via the introducer * The introducees derive a shared secret, destroy their single-use private keys, and start key rotation Having each party sign an ephemeral public key with a long-term signing key is not, by itself, a good key agreement protocol, due to: * The identity misbinding possibility of an an attacker signing a victim's ephemeral key, tricking others into thinking the victim's communications originated from the attacker. * The lack of freshness on the authentication - if an attacker compromises one ephemeral private key, it can be reused without needing additional signatures. Earlier I was suggesting triple Diffie-Hellman as a better option. * The introducees exchange acks via the introducer * The introducees can optionally obtain each other's long-term public keys from other third parties, before or after the introduction * If the introducees meet face-to-face, they can confirm each other's long-term public keys using SAS: - The users verbally exchange short codes to enable their devices to find each other over a short-range transport such as wifi - The devices exchange hash commitments and ephemeral public keys - The users verbally exchange short authentication strings - If the strings match, the devices derive symmetric encryption and authentication keys from the ephemeral shared secret - Within the ephemeral secure channel, the devices exchange long-term public keys and a value derived from the current temporary secret, signed with their long-term private keys, as verification that they own those keys and have the same shared secret * Nobody signs anything that proves who their contacts are If you care about deniability I would avoid signatures entirely (e.g. use Diffie-Hellman based protocols). Trevor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Thu, Oct 3, 2013 at 9:57 AM, Michael Rogers mich...@briarproject.orgwrote: Great points, thanks! I'd forgotten about triple Diffie-Hellman (already, tut tut). Has it received any peer review other than being adopted by Moxie? It was analyzed in a paper by Kudla Paterson. See Section 5.1, and the note near the end that Protocol 1 can easily be extended to have perfect forward secrecy [...]. http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf The Ntor protocol by Goldberg et al is also similar. It's essentially a server-authenticated (instead of mutually-authenticated) version of this, so it's a double-DH (omitting the ephemeral-static DH that would involve the client's static key). I believe Ntor is being considered for use in Tor. http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf Have you patented it? ;-) No, nor am I aware of any patents or IPR covering it. So a triple-DH version of the protocol would look like this: * The introducees exchange single-use public keys and long-term public keys via the introducer * The introducees use triple-DH to derive a shared secret, destroy their single-use private keys, and start key rotation To state the obvious, you'll need to be quite careful with key derivation from the 3 ECDH secrets, e.g. also hash in all relevant public keys and other identifiers, handshake messages, etc., perhaps using something like HKDF. * The introducees exchange acks via the introducer * The introducees can optionally obtain each other's long-term public keys from other third parties, before or after the introduction * If the introducees meet face-to-face, they can confirm each other's long-term public keys using SAS: - The users verbally exchange short codes to enable their devices to find each other over a short-range transport such as wifi - The devices exchange hash commitments and ephemeral public keys - The users verbally exchange short authentication strings - If the strings match, the devices derive symmetric encryption and authentication keys from the ephemeral shared secret - Within the ephemeral secure channel, the devices exchange long-term public keys and a value derived from the current temporary secret as verification that they have the same shared secret * Nobody signs anything at all Nothing horrible jumps out at me, though I'm not saying that's a thorough review! Trevor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
On Thu, Oct 03, 2013 at 04:53:09PM +0100, Michael Rogers wrote: Presumably if you ensure that the private key is valid, the public key derived from it must be a point on the curve. So it's a matter of validating private rather than public keys. I understand what you're saying about a timing side-channel in the draft-harkins-tls-pwd approach, but here I'm not concerned with validating a public key after generating it, but rather with the puzzling statement that there's no need to validate a public key after receiving it: How do I validate Curve25519 public keys? Don't. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys. http://cr.yp.to/ecdh.html#validate Well consider an EC point is an x,y coordinate both coordinates modulo p, some 256-bit prime. There are a number of points on the curve l and for a given base point a number of points generated by that point n. For prime order curves typically the co-factor h = 1 so l=n. (This is analogous to the difference between p = 2q+1 in normal diffie hellman over prime fields. Ther are p values but the group generated by g will hold q possible values before wrapping around where q divides p-1.) So now back to EC to note that n and p are almost the same size (both 256-bit but np, however clearly the number of potential points is in fact 2p (because X=(x,y) and -X=(x,-y) are both points on the curve). But 2pn nearly 2p is nearly 2x n (n the number of points on the curve). So therefore around half of the points you could start from are not on the curve, there is no solution when you try to solve for y from the curve equation. As you see in the harkin draft in that type of curve it is because x^3+ax+b has no square root. So you know about point compression? Basically you can almost recover a point from the x-coord only because each point is (x,f(x)) but with one caveat that because its a symmetric curve about the x-axis you also need to say whether thats f(x) or -f(x). So people would send the x-coord and one bit for the sign. Its getting kind of complicated but it seems to me DJB ensures all 32 byte encoded points are points by a kind of definitional trick that a point is not the x-coord and sign bit, but the number x multiplied by a base point (9,f(9)) which of course is a valid point because (9,f(9)) is a generator. Its an equally valid encoding method and is probably faster. However if you call (9,f(9))=G, you cant use DJB point encoding when you're doing PAKE because well if password attempt pwd1 you get pwd1.G and then you do some DH thing with it, send to the otherside they do Y=x.pwd1.G and send back, thats bad because you can revise pwd1 to pwd2 by division: pwd2.pwd1^-1.Y = pwd2.pwd1^-1.x.G=x.pwd2.G and then you can offline grind the PAKE key exchange which is bad. So for that you really need to start from x = H(password) and point G=(x,f(x)) and that was what the hunt and peck algorithm in Harkins is about. DJB has a solution for that too in his Elligator paper which is constant time (as I recall worst case two tries) because he can use a different method relating to the more flexible and and more efficient curves he chose. Is it just me or could we better replace NIST by DJB ? ;) He can do that EC crypto, and do constant time coding (nacl), and non-hackable mail servers (qmail), and worst-time databases (cdb). Most people in the world look like rank amateurs or no-real-programming understanding niche-bound math geeks compared to DJB! Adam -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/13 15:14, Adam Back wrote: Well I think there are two issues: 1. if the public key is derived from a password (like a bitcoin brainwallet), or as in EC based PAKE systems) then if the point derived from your password isnt on the curve, then you know that is not a candidate password, hence you can for free narrow the password search. (Which particularly for PAKE systems weakens their security). 2. if the software doesnt properly validate that the point is on the curve, and tries to do an operation involving a private key or secret, anyway, it may leak some of the secret. DJB has some slides saying he found some software does not check. Hmm, so perhaps the statement quoted above simply means Curve25519 contains its own key validation code, and will complain if the string you give it isn't a valid public key? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSTZLlAAoJEBEET9GfxSfM4dMH/jo83Jse5V6DqnZwaIkNesLY AufH8+amkMALbO8Db7r/sG+cGXMy8sSRWqPTJ0jXd3z4ZAgKbx3aW2eBEmIU9i3Y K0jkABVJty3XyvPAspoCUwZ+Fh7brUSCRHQJt0MWMQADPdoXJUY+iobmCGgO4Qbk +npDlo3pTNeEofsvkEM3uSPofR88JXvMC1sYhGr4+GMsBt330vG2Zd278AlVTlOb fVpwEtlad5Fb58RfGidMb4n7BUKKmkPI3KJewpJEXfc8CMP1ITsmX8hTzIz0wakz ubjwDu7ENUMkZhfkt4qNpTLeWQBOFrrfUDe9qrlTY5GpbNfy295K/aWMvi65c6g= =sxPV -END PGP SIGNATURE- ___ cryptography mailing
Re: [cryptography] the spell is broken
On 2013-10-04 02:03, Jared Hunter wrote: One of the biggest issues we're wrestling with, I think, is that the crypto community already decided that AES and SHA-2 are just fine. In large part because we trusted NIST. If we do not trust NIST ... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04 00:13, Jeffrey Goldberg wrote: So unless you and Silent Circle have information that the rest of us don�t about AES and SHA-2, I�m actually pissed off at this action. It puts more pressure on us to follow suit, even though such a move would be pure security theater. You have to get off the NIST curves. If getting of the NIST curves, might as well get off AES and SHA-2 as well. If you are not using the NIST curves, the need to change is less urgent. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-03, at 1:28 PM, James A. Donald jam...@echeque.com wrote: On 2013-10-04 00:13, Jeffrey Goldberg wrote: So unless you and Silent Circle have information that the rest of us don’t about AES and SHA-2, I’m actually pissed off at this action. It puts more pressure on us to follow suit, even though such a move would be pure security theater. You have to get off the NIST curves. If getting of the NIST curves, might as well get off AES and SHA-2 as well. Fair point. As we aren’t doing any public key stuff, we don’t need to hunt down new curves or go back to DH or anything like that. And as you say, if you are changing something, it isn’t too hard to chance other things at the same time. But (and given that my previous message got MIME-mangled, I’ll repeat some points) the thought that Jon and Silent Circle are putting into curve replacement looks much more serious than the thought going into AES and SHA-2 replacement, which reek of security theater. I’ll grant that a priori any SHA-3 finalist will be an improvement on SHA-2, so really it’s the just AES move that reeks of security theater. If you are going to drop in a replacement for AES (same blocksize, same key sizes) then you should look at this as an opportunity to find the best replacement possible. Maybe AES with increased rounds and improved key schedule. That would have the advantage of taking advantage of a lot of existing hardware. Or maybe there are better alternatives. But picking Twofish out of a hat just seems like security isn’t the issue, but perception. If you are not using the NIST curves, the need to change is less urgent. Agreed, but for me the “less urgent” is “next to nil”. (Beyond the existing reasons for moving away from SHA-2.). But fine, I acknowledge your point, and perhaps I’m just whining because I’m lazy and this would be a difficult change to implement. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
On 3 October 2013 14:13, Florian Weimer f...@deneb.enyo.de wrote: On 02/10/13 at 08:51am, Florian Weimer wrote: There is widespread belief that compressing before encrypting makes cryptanalysis harder, so compression is assumed to be beneficial. Any academic references? Applied Cryptography (2nd edition) contains this: Oh boy. | 10.6 Compression, Encoding, And Encryption | | Using a data compression algorithm together with an encryption | algorithm makes sense for two reasons: | | Cryptanalysis relies on exploiting redundancies in the plaintext; | compressing a file brfore encryption reduces these redundancies. Yeah. So CRIME shows us how accurate this wild claim is. | | Encryption is time-consuming; compressing a file before encryption | speeds up the process. I haven't benchmarked it, but I find it unlikely that compression is faster than encryption. | The important thing to remember is to compress before encryption. […] Obvious. Schneier doesn't cite any references for these claims, unfortunately. Bergen and Hogan, A Chosen Plaintext Attack on an Adapative Arithmetic Coding Compression Algorithm (2002) cite Witten and Cleary, On the privacy afforded by Adaptive Text Compression (1988) and Jones, An efficient coding system for long source sequences (1981). Neither paper appears to be available on the public Internet. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] One Time Pad Cryptanalysis
* Ben Laurie: | 10.6 Compression, Encoding, And Encryption | | Using a data compression algorithm together with an encryption | algorithm makes sense for two reasons: | | Cryptanalysis relies on exploiting redundancies in the plaintext; | compressing a file brfore encryption reduces these redundancies. Yeah. So CRIME shows us how accurate this wild claim is. And it's not even the first attack of this type. I find the application voice codecs particularly cute. The recommendation is really puzzling. With a modern cipher, compression (even if it hasn't fingerprints of its own) should never make cryptanalysis harder. With a very weak cipher, it could make a difference, but even in the mid-90s, you hopefully wouldn't use one, even after consulting Applied Cryptography (which describes quite a few of them, admittedly). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 3, 2013, at 7:13 AM, Jeffrey Goldberg jeff...@goldmark.org wrote: Jeff, You might call it security theatre, but I call it (among other things) protest. I have also called it trust, conscience, and other things including emotional. I'm willing to call it marketing in the sense that marketing often means non-technical. I disagree with security theatre because in my opinion security theatre is *empty* or *mere* trust-building, but I don't fault you for being upset. I don't blame you for venting in my direction, either. I will, however, repeat that I believe this is something gentlepersons can disagree on. A decision that's right for me might not be right for you and vice-versa. Since the AES competition, NIST has been taking a world-wide role in crypto standards leadership. Overall, it's been a good thing, but one could have one's disagreements with a number of things (and I do), but it's been a good *standards* process. A good standard, however, is not necessarily the *best*, it's merely agreed upon. A standard that is everyone's second choice is better than a standard that is anyone's first choice. I don't think there are any problems with AES, but I think Twofish is a better choice. During the AES competition, the OpenPGP community as a whole, and I and my PGP colleagues put Twofish into OpenPGP *independently* of the then-unselected AES. It was thus our vote for it. When Phil, Alan, and I were putting ZRTP together, we put in Twofish as an option (RFC 6189, section 5.1.3). Thus in my opinion, if you know my long-standing opinions on ciphers, this shouldn't be a surprise. I think Twofish is a better algorithm than Rijndael. ZRTP also has in it an option for using Skein's one-pass MAC instead of HMAC-SHA1. Why? Because we think it's more secure in addition to being a lot faster, which is important in an isochronous protocol. Silent Phone already has Twofish in it, and is already using Skein-MAC. In Silent Text, we went far more to the one true ciphersuite philosophy. I think that Iang's writings on that are brilliant. As a cryptographer, I agree, but as an engineer, I want options. I view those options as a form of preparedness. One True Suite works until that suite is no longer true, and then you're left hanging. To be fair, there are few options in ZRTP -- it's only AES or Twofish and SHA1-HMAC or Skein-MAC, so the selection matrix is small when compared to OpenPGP. We have One True Elliptic Curve -- P-384, and options for AES-CCM in either 128 or 256 bits and paired with SHA-256 or SHA-512 as hash and HMAC as appropriate. There's a third option, AES-256 paired with Skein/Skein-MAC, which I don't think is in the code, merely defined as a cipher suite. I can't remember. So we have to add Twofish there, but it's in Silent Phone now. Now let me go back to my comment about standards. Standards are not about what's *best*, they're about what's *agreed*, and part of what's agreed on is that they're good enough. When one is part of a standards regime, one sublimates one's personal opinions to the collective good of the standard. That collective good of the standard is also security theatre in the sense that one uses it because it's the thing uses to be part of the community. I think Twofish is better than AES. I believe that Skein is better than SHA-2. I also believe in the value of standards. The problem one faces with the BULLRUN documents gives a decision tree. The first question is whether you think they're credible. If you don't think BULLRUN is credible, then there's an easy conclusion -- stay the course. If you think it is credible, then the next decision is whether you think that the NIST standards are flawed, either intentionally or unintentionally; in short, was BULLRUN *successful*. If you think they're flawed, it's easy; you move away from them. The hard decision is the one that comes next -- I can state it dramatically as Do you stand with the NSA or not? which is an obnoxious way to put it, as there are few of us who would say, Yes, I stand with the NSA. You can phrase less dramatically it as standing with NIST, or even less dramatically as standing with the standard. You can even state it as whether you believe BULLRUN was successful, or lots of other ways. Moreover, it's not all-or-nothing. Bernstein and Lange have been arguing that the NIST curves are flawed since before Snowden. Lots of people have been advocating moving to curve 25519. I want a 384-or-better curve because my One True Curve has been P-384. If I'm going to move away from the NIST/NSA curve (which seems wise), what about everything else? Conveniently, I happen to have alternates for AES and SHA-2 in my back pocket, where they've been *alternates* in my crypto going back years. They're even in part of the software, sublimated to the goodness of the standard. The work is merely pulling them to the
Re: [cryptography] the spell is broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree fully Jon, I short, I feel that all trust for NIST has to be broken. It doesn't matter if AES or SHA-2 is broken or not broken. You cannot go into a security environment with a tool that is known to be compromised (NIST) and just hope and pray that the pieces you are using aren't the compromised pieces. There are alternatives, it doesn't hurt to get them in place. On 03/10/2013 3:31 PM, Jon Callas wrote: On Oct 3, 2013, at 7:13 AM, Jeffrey Goldberg jeff...@goldmark.org wrote: Jeff, You might call it security theatre, but I call it (among other things) protest. I have also called it trust, conscience, and other things including emotional. I'm willing to call it marketing in the sense that marketing often means non-technical. I disagree with security theatre because in my opinion security theatre is *empty* or *mere* trust-building, but I don't fault you for being upset. I don't blame you for venting in my direction, either. I will, however, repeat that I believe this is something gentlepersons can disagree on. A decision that's right for me might not be right for you and vice-versa. Since the AES competition, NIST has been taking a world-wide role in crypto standards leadership. Overall, it's been a good thing, but one could have one's disagreements with a number of things (and I do), but it's been a good *standards* process. A good standard, however, is not necessarily the *best*, it's merely agreed upon. A standard that is everyone's second choice is better than a standard that is anyone's first choice. I don't think there are any problems with AES, but I think Twofish is a better choice. During the AES competition, the OpenPGP community as a whole, and I and my PGP colleagues put Twofish into OpenPGP *independently* of the then-unselected AES. It was thus our vote for it. When Phil, Alan, and I were putting ZRTP together, we put in Twofish as an option (RFC 6189, section 5.1.3). Thus in my opinion, if you know my long-standing opinions on ciphers, this shouldn't be a surprise. I think Twofish is a better algorithm than Rijndael. ZRTP also has in it an option for using Skein's one-pass MAC instead of HMAC-SHA1. Why? Because we think it's more secure in addition to being a lot faster, which is important in an isochronous protocol. Silent Phone already has Twofish in it, and is already using Skein-MAC. In Silent Text, we went far more to the one true ciphersuite philosophy. I think that Iang's writings on that are brilliant. As a cryptographer, I agree, but as an engineer, I want options. I view those options as a form of preparedness. One True Suite works until that suite is no longer true, and then you're left hanging. To be fair, there are few options in ZRTP -- it's only AES or Twofish and SHA1-HMAC or Skein-MAC, so the selection matrix is small when compared to OpenPGP. We have One True Elliptic Curve -- P-384, and options for AES-CCM in either 128 or 256 bits and paired with SHA-256 or SHA-512 as hash and HMAC as appropriate. There's a third option, AES-256 paired with Skein/Skein-MAC, which I don't think is in the code, merely defined as a cipher suite. I can't remember. So we have to add Twofish there, but it's in Silent Phone now. Now let me go back to my comment about standards. Standards are not about what's *best*, they're about what's *agreed*, and part of what's agreed on is that they're good enough. When one is part of a standards regime, one sublimates one's personal opinions to the collective good of the standard. That collective good of the standard is also security theatre in the sense that one uses it because it's the thing uses to be part of the community. I think Twofish is better than AES. I believe that Skein is better than SHA-2. I also believe in the value of standards. The problem one faces with the BULLRUN documents gives a decision tree. The first question is whether you think they're credible. If you don't think BULLRUN is credible, then there's an easy conclusion -- stay the course. If you think it is credible, then the next decision is whether you think that the NIST standards are flawed, either intentionally or unintentionally; in short, was BULLRUN *successful*. If you think they're flawed, it's easy; you move away from them. The hard decision is the one that comes next -- I can state it dramatically as Do you stand with the NSA or not? which is an obnoxious way to put it, as there are few of us who would say, Yes, I stand with the NSA. You can phrase less dramatically it as standing with NIST, or even less dramatically as standing with the standard. You can even state it as whether you believe BULLRUN was successful, or lots of other ways. Moreover, it's not all-or-nothing. Bernstein and Lange have been arguing that the NIST curves are flawed since before Snowden. Lots of people have been advocating moving to
Re: [cryptography] the spell is broken
On Thu, 3 Oct 2013, Kelly John Rose wrote: I short, I feel that all trust for NIST has to be broken. It doesn't matter if AES or SHA-2 is broken or not broken. You cannot go into a security environment with a tool that is known to be compromised (NIST) and just hope and pray that the pieces you are using aren't the compromised pieces. Reasoning that way, you're very quickly left with not but a tin foil hat. Let's say we agree on twofish. then NIST/NSA certifies it for FIPS. Are we than taking that as proof it is compromised and figure out something else? People forget the NSA has two faces. One side is good. NIST and FIPS and NSA are all related. One lesson here might be, only use FIPS when the USG requires it. That said, a lot of FIPS still makes sense. I'm surely not going to stick with md5 or sha1. There are alternatives, it doesn't hurt to get them in place. Yes, like the IETF brainpool drafts. The IETF is an independant body but only as good as the academic and open cryptography community. And for those crypto people complaining on the lack of crypto knowledge within the IETF, you have no excuse not to participate. IETF carefully tries to not invent crypto. Paul ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
Not quite. If people agree on Twofish and a generalized standard outside of NIST, then if NIST picks it up and agrees as well there isn't much concern. The problem is with older existing standards or if NIST provides unexplained changes or magic values to the standard. On 03/10/2013 4:04 PM, Paul Wouters wrote: Reasoning that way, you're very quickly left with not but a tin foil hat. Let's say we agree on twofish. then NIST/NSA certifies it for FIPS. Are we than taking that as proof it is compromised and figure out something else? -- Kelly John Rose Mississauga, ON Phone: +1 647 638-4104 Twitter: @kjrose Document contents are confidential between original recipients and sender. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04 07:31, Jon Callas wrote: absolutely, this is an emotional response. It's protest. Intellectually, I believe that AES and SHA2 are not compromised. Emotionally, I am angry and I want to distance myself from even the suggestion that I am standing with the NSA. As Coderman and Iang put it, I want to*signal* my fury. I am so pissed off about this stuff that I don't*care* about baby and bathwater, wheat and chaff, or whatever else. I also want to signal reassurance to the people who use my system that yes, I actually give a damn about this issue. By moving away from anything NIST has touched he deprives the NSA of leverage to insert backdoors, contributing to the general good, from which his company, and thus himself also benefits. By opposing the NSA, he gives his company credibility that they will not secretly play footsy with the NSA behind closed doors, reassuring his customers and contributing to the particular good of his company and himself. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] A question about public keys
On 2013-10-04 03:45, Adam Back wrote: Is it just me or could we better replace NIST by DJB ? ;) He can do that EC crypto, and do constant time coding (nacl), and non-hackable mail servers (qmail), and worst-time databases (cdb). Most people in the world look like rank amateurs or no-real-programming understanding niche-bound math geeks compared to DJB! Committees are at best inherently more stupid than their most stupid member, and are at worst also inclined to evil and madness. Linux was success because Linus is unelected president for life. Let us have Jon Callas as unelected president for life of symmetric cryptography, Bernstein as God King of public key cryptography. Recall the long succession of Wifi debacles. Has any committee ever done anything good in cryptography? IEEE 802.11 was stupid. If NIST was not stupid, it was because evil was calling the shots behind the scenes, overruling the stupid. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 10/03/2013 03:22 PM, James A. Donald wrote: By moving away from anything NIST has touched he deprives the NSA of leverage to insert backdoors, NSA can act through people outside NIST too. By focusing on NIST we miss the larger problem. Any cryptographer or security engineer can be compromised (or more likely, make a mistake). A good standard uses a public process, is well understood, has been examined by outside experts, and has no magic values. Following good standards hygiene will reduce the instances of flawed standards, both the accidental and the on purpose kind. We will end up less secure if the current fear of NIST has people throw out good standards and replace them with less studied ones or worse, home grown stuff. Eric ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04 08:04, Paul Wouters wrote: Reasoning that way, you're very quickly left with not but a tin foil hat. Let's say we agree on twofish. then NIST/NSA certifies it for FIPS. Are we than taking that as proof it is compromised and figure out something else? If people were adopting twofish Jon Callas did so, reason to believe in twofish. If people were adopting twofish because NIST was doing it, that would be reason to doubt twofish. If all shall follow Jon Callas as unelected president for life of symmetric cryptography then NIST is powerless, therefore irrelevant. If it does not set standards, cannot corrupt them. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
James A. Donald jam...@echeque.com writes: By moving away from anything NIST has touched he deprives the NSA of leverage to insert backdoors, Just as a bit of a counterpoint here, how far do you want to go down this rathole? Someone recently pointed me to the latest CERT vuln. summary (because of a few interesting entries there): https://www.us-cert.gov/ncas/bulletins/SB13-273 Now this is just a single weeks' worth, and yet look at all the remote-code- execution and seize-control-of-device issues in just that seven-day stretch. The NSA doesn't really need to backdoor crypto when the barn door isn't just propped wide open, it's entirely missing in some cases. (I completely support Jon's position in terms of being seen to do the right thing, but there are more things to worry about than just backdoored crypto). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
Jon, first of all thank you for your extremely thoughtful note. I suspect that we will find that we don’t actually disagree about much, and also my previous rant was driven by the general anger and frustration that all of us are experiencing. That is, I amy have been misdirecting my anger at the whole situation at you, a fellow victim. On 2013-10-03, at 4:31 PM, Jon Callas j...@callas.org wrote: You might call it security theatre, but I call it (among other things) protest.” I would put it more strongly than that. I think that NIST needs to be punished. Even if Dual_EC_DRBG were their only lapse, any entity that has allowed themselves to be used that way should be forced to exit the business of being involved in making recommendations on cryptography. I don’t have to think that they are bad people or even that they could have prevented what happened. But I think there needs to be an unambiguous signal to every other (potential) standards body about what happens if you even think of allowing for the sabotage of crypto. I imagine that everyone is looking at public protocols for picking curves now. Everyone is looking at how every step in the establishment of a recommendation can be made provably transparent. That is all a good thing, and it does require that NIST pay dearly. But it isn’t a trust issue. I don’t “trust” the NIST less than I trust any other standard’s body. The need to be put out of the crypto business as a signal and deterrent to others, but not because they are inherently less trustworthy. But not using AES is a protest that hurts only ourselves. It doesn’t punish where punishment is needed. I have also called it trust, conscience, and other things including emotional. I'm willing to call it marketing in the sense that marketing often means non-technical. Agreed. I disagree with security theatre because in my opinion security theatre is *empty* or *mere* trust-building, I still think the term is appropriate, and indeed I think that your sentence about conscience and emotions actually reinforces my claim that it is theater. But I think that it is largely a definitional question which isn’t worth pursuing. I’m using the term in a slightly different way than you are. but I don't fault you for being upset. I don't blame you for venting in my direction, either. I will, however, repeat that I believe this is something gentlepersons can disagree on. A decision that's right for me might not be right for you and vice-versa. Absolutely! Although I still stand by my “security theater” statement, I think I also mean it less pejoratively than it came across. Anyone (including me and the company that I work for) who has moved to 256 bit symmetric keys is engaging in “security theater” in my sense of the word. It’s nothing to be particularly proud of, but it doesn’t make us the TSA either. Since the AES competition, NIST has been taking a world-wide role in crypto standards leadership. Yep. And (sadly) that has go. As I said, they need to pay a heavy price so that it is absolutely clear that some behaviors are beyond the pale. A good standard, however, is not necessarily the *best*, it's merely agreed upon. That’s true. I think Twofish is a better algorithm than Rijndael. OK. I was flat out wrong. I was ignorant of your longstanding view of ciphers. I’m not competent to really have an opinion about whether your judgement is correct there, but that isn’t relevant. I thought Twofish was pulled out of a hat. I was wrong. And I also apologize for accusing you of pulling Twofish out of hat. ZRTP also has in it an option for using Skein's one-pass MAC instead of HMAC-SHA1. Why? Because we think it's more secure in addition to being a lot faster, which is important in an isochronous protocol. I agree that if you are changing ciphersuites, it’s as good a time as any to move to a SHA-3 candidate. And as there some questions that need to be answered about official SHA-3, I’m happy with Skein. Again, I’m not competent to judge the relative merits of SHA-3 candidates. Silent Phone already has Twofish in it, and is already using Skein-MAC. Ah. So yes, we are in very different starting places. Your choice seems very reasonable. In Silent Text, we went far more to the one true ciphersuite philosophy. I think that Iang's writings on that are brilliant. As a cryptographer, I agree, but as an engineer, I want options. I think I am in a different position. I’m neither an engineer nor a cryptographer. I’m the guy who can kinda sorta read bits of the cryptography literature and advise the engineers on what to do with respect to using these tools. And what we decide affects the security of a very large number of users. So for me, the “one true ciphersuite” notion was ideal. I could pay attention and follow the consensus advice. You may be competent to, say, pick Skein over Blake for some particular purpose, but I’m not.
Re: [cryptography] the spell is broken
On Thu, Oct 3, 2013 at 9:26 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: ... I would put it more strongly than that. I think that NIST needs to be punished. Even if Dual_EC_DRBG were their only lapse, any entity that has allowed themselves to be used that way should be forced to exit the business of being involved in making recommendations on cryptography. I don’t have to think that they are bad people or even that they could have prevented what happened. But I think there needs to be an unambiguous signal to every other (potential) standards body about what happens if you even think of allowing for the sabotage of crypto. We could not get rid of Trustwave in the public sector (so much for economics). There's no way we can get rid of the US agency responsible for crypto standards (government is not held responsible for the act or accountable after the act). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04 11:41, Jeffrey Walton wrote: We could not get rid of Trustwave in the public sector (so much for economics). What is wrong with trustwave? They are smart people, unlike the world bank economists who do not know the difference between negative feedback and positive feedback, or the IEEE 802.11 There's no way we can get rid of the US agency responsible for crypto standards If no one pays attention to their standards, we have gotten rid of them. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] the spell is broken
On 2013-10-04 11:26, Jeffrey Goldberg wrote: But not using AES is a protest that hurts only ourselves. I have always been inclined to believe that that twofish is better than AES. Refusing to use AES, or making it the non default choice, is rejecting NIST as a standards body. We need to reject NIST as a standards body. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
