Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
On Tue, Sep 10, 2013 at 10:59 PM, William Allen Simpson william.allen.simp...@gmail.com wrote: I suggest: ChaCha20 is run with the given key and sequence number nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The next 8 bytes of the output are saved to become the per-record input nonce for this ChaCha20 TLS record. Or you could use 16 bytes, and cover all the input fields There's no reason the counter part has to start at 1. Of course, this depends on not having a related-key attack, as mentioned in my previous messages It is the case that most of the bottom row bits will be zero. However, ChaCha20 is assumed to be secure at a 256-bit security level when used as designed, with the bottom row being counters. If ChaCha/Salsa were not secure in this formulation then I think they would have to be abandoned completely. Nobody worries that AES-CTR is weak when the counter starts at zero, right? Taking 8 bytes from the initial block and using it as the nonce for the plaintext encryption would mean that there would be a ~50% chance of a collision after 2^32 blocks. This issue affects AES-GCM, which is why the sequence number is used here. Using 16 bytes from the initial block as the full bottom row would work, but it still assumes that we're working around a broken cipher and it prohibits implementations which pipeline all the ChaCha blocks, including the initial one. That may be usefully faster, although it's not the implementation path that I've taken so far. There is an alternative formulation of Salsa/ChaCha that is designed for random nonces, rather than counters: XSalsa/XChaCha. However, since we have a sequence number already in TLS I've not used it. Cheers AGL ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
[attempt two, because I bounced off the mailing list the first time.] On Tue, Sep 10, 2013 at 9:35 PM, William Allen Simpson william.allen.simp...@gmail.com wrote: ChaCha20 is run with the given key and nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The remainder of the output is discarded. Why generate the ICV key this way, instead of using a longer key blob from TLS and dividing it? Is there a related-key attack? The keying material from the TLS handshake is per-session information. However, for a polynomial MAC, a unique key is needed per-record and must be secret. Using stream cipher output as MAC key material is a trick taken from [1], although it is likely to have more history than that. (As another example, UMAC/VMAC runs AES-CTR with a separate key to generate the per-record keys, as did Poly1305 in its original paper.) Authenticated decryption is largely the reverse of the encryption process: the Poly1305 key is generated and the authentication tag calculated. The calculated tag is compared against the final 16 bytes of the authenticated ciphertext in constant time. If they match, the remaining ciphertext is decrypted to produce the plaintext. If AEAD, aren't the ICV and cipher text generated in parallel? So how do you check the ICV first, then decipher? The Poly1305 key (ICV in your terms?) is taken from a prefix of the ChaCha20 stream output. Thus the decryption proceeds as: 1) Generate one block of ChaCha20 keystream and use the first 32 bytes as a Poly1305 key. 2) Feed Poly1305 the additional data and ciphertext, with the length prefixing as described in the draft. 3) Verify that the Poly1305 authenticator matches the value in the received record. If not, the record can be rejected immediately. 4) Run ChaCha20, starting with a counter value of one, to decrypt the ciphertext. An alternative implementation is possible where ChaCha20 is run in one go on a buffer that consists of 64 zeros followed by the ciphertext. The advantage of this is that it may be faster because the ChaCha20 blocks can be pipelined. The disadvantage is that it may need memory copies to setup the input buffer correctly. A moot advantage, in the case of TLS, of the steps that I outlined is that forgeries are rejected faster. Needs a bit more implementation details. I assume there's an implementation in the works. (Always helps define things with something concrete.) I currently have Chrome talking to OpenSSL, although the code needs cleanup of course. [1] http://cr.yp.to/highspeed/naclcrypto-20090310.pdf Cheers AGL ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] About those fingerprints ...
Gentlefolk, Fingerprint scanners have shipped on laptops and phones for years. Yesterday, Apple made the bold, unaudited claim that it will never save the fingerprint data outside of the A7 chip. Why should we trust Cook Co.? They are subject to the laws of the land and will properly respond to lawful subpoenas. What are they doing to ensure the user's confidence that they cannot spread my fingerprint data to the cloud? (POI frequently have fingerprints on file. Finding out which phone is used by whom when you have fingerprint data is a Big Data query away.) These questions also apply to things like keychain storage. Who has audited in a public fashion that Apple actually keeps keychains secure? How do we know whether Apple has perverted under secret court order the common crypto and other libraries in every phone and iPad? iOS 7 supports keychain storage in iCloud. Why should we trust Apple to keep our keys safe there? Where is the audit of their claims? Why should we trust Cook Co. without verifying their claims? IOW, where is the culture of public audit around security? Why did we ever trust the Canadian company RIM with our email without a public audit? Why do we trust Apple, MS, Google and others? The culture of secrecy around the security stack inside popular OSes needs to stop. (I am proposing after the fact audits of shipping OSes. They should never be an impediment to any organization shipping software in a timely fashion.) Sunlight on the libraries being used is the best disinfectant for security concerns. President Reagan had it right: Trust but verify. Why should we trust Apple? Because their executives said so in a video? We need something stronger. Anon, Andrew P.S.All you Android fanboys know how to globally replace Apple above with Google/Samsung. Andrew W. Donoho Donoho Design Group, L.L.C. a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho Download Retweever here: http://Retweever.com No risk, no art. No art, no reward. -- Seth Godin ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On Tue, Sep 10, 2013 at 09:01:49PM +0200, Guido Witmond wrote: My scheme does the opposite. It allows *total strangers* to exchange keys securely over the internet. With a FOAF routing scheme with just 3 degrees of separation there are not that many strangers left. If you add opportunistic encryption at a low transport layer, plus additional layers on top of you've protected the bulk of traffic. signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
2013/9/11 William Allen Simpson william.allen.simp...@gmail.com It bugs me that so many of the input words are mostly zero. Using the TLS Sequence Number for the nonce is certainly going to be mostly zero bits. And the block counter is almost all zero bits, as you note, (In the case of the TLS, limits on the plaintext size mean that the first counter word will never overflow in practice.) [...] In my PPP ChaCha variant of this that I started several months ago, the nonce input words were replaced with my usual CBCS formulation. That is, invert the lower 32-bits of the sequence number, xor with the upper 32-bits, add (mod 2**64) both with a 64-bit secret IV, count the bits, and variably rotate. [...] Chacha20 being a stream cipher, the only requirement we have on the ICV is that it doesn't repeat isn't ? This means that if there's a problem with setting 'mostly zeroed out' ICV for Chacha20 we shouldn't use it at all period. As far as your proposition is concerned, the performance penalty seems to largely depend on the target platform. Wouldn't using the same set of operations as Chacha prevent an unexpected performance drop in case of lots of short messages ? Cheers ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Introducing strangers. Was: Thoughts about keys
On 09/11/13 10:43, Eugen Leitl wrote: On Tue, Sep 10, 2013 at 09:01:49PM +0200, Guido Witmond wrote: My scheme does the opposite. It allows *total strangers* to exchange keys securely over the internet. With a FOAF routing scheme with just 3 degrees of separation there are not that many strangers left. How do you meet people outside your circle of friends? How do you stay anonymous? With FOAF, you have a single identity for it to work. I offer people many different identities. But all of them are protected, and all communication encrypted. That's what my protocol addresses. To introduce new people to one another, securely. You might not know the person but you are sure that your private message is encrypted and can only be read by that person. Of course, as it's a stranger, you don't trust them with your secrets. For example, to let people from this mailing list send encrypted mail to each other, without worrying about the keys. The protocol has already taken care of that. No fingerprint checking. No web of trust validation. If you add opportunistic encryption at a low transport layer, plus additional layers on top of you've protected the bulk of traffic. I don't just want to encrypt the bulk, I want to encrypt everything, all the time. It makes Tor traffic much more hidden. There is more The local CA (one for each website) signs both the server and client certificates. The client only identifies itself to the server after it has recognized the server certificate. This blocks phishing attempts to web sites (only a small TOFU risk remains). And that can be mitigated with a proper dose of Certificate Transparency. Kind regards, Guido Witmond, Please see the site for more details: http://eccentric-authentication.org/ signature.asc Description: OpenPGP digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
On Sep 10, 2013, at 6:43 PM, Nemo n...@self-evident.org wrote: GET / HTTP/1.1\r\n is exactly 16 bytes, or one AES block. If the IV is sent in the clear -- which it is -- that is one plaintext-ciphertext pair right there for every HTTPS connection. In fact, _any_ aligned 16 bytes of plaintext in the conversation that are known, or that are in a guessable range, represent a plaintext/ciphertext pair if either of the following are true: 1) You sent the IV in the clear 2) You used CBC mode Of the modes I know (CBC, CTR, GCM, et. al.), the only one that does not freely give up such plaintext/ciphertext pairs is OCB. according to http://en.wikipedia.org/wiki/Padding_(cryptography) , most protocols only talk about padding at the end of the cleartext before encryption. now, how about adding some random at the beginning of the cleartext, say, 2.5 times the block size, that is 40 bytes for the example above, of random stuff before the interesting text appears ? - Raphael smime.p7s Description: S/MIME cryptographic signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Tue, Sep 10, 2013 at 2:04 PM, Joe Abley jab...@hopcount.ca wrote: As an aside, I see CAs with Chinese organisation names in my browser list. I wouldn't pick on/fear/call out the Chinese specifically. Also, be aware that browsers must transitively trust all the issuers that the known trust anchors have issued issuing certificates for. That's a much bigger set, and is not currently fully knowable. (Another reason to crave Certificate Transparency.) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
On 9/11/13 6:00 AM, Alexandre Anzala-Yamajako wrote: Chacha20 being a stream cipher, the only requirement we have on the ICV is that it doesn't repeat isn't ? You mean IV, the Initialization Vector. ICV is the Integrity Check Value, usually 32-64 bits appended to the packet. Each is separately keyed. This means that if there's a problem with setting 'mostly zeroed out' ICV for Chacha20 we shouldn't use it at all period. I strongly disagree. In my network protocol security designs, I always try to think about weaknesses in the implementation and potential future attacks on the algorithm -- and try to strengthen the security margin. For example, IP-MAC fills every available zero space with randomness, while H-MAC (defined more than a year later) uses constants instead. IP-MAC was proven stronger than H-MAC. Sadly, in the usual standards committee-itis, newer is often assumed to be improved and better. So H-MAC was adopted instead. Of course, we know that H-MAC was chosen by an NSA mole in the IETF, so I don't trust it. Also, there's a certain silliness in formal cryptology that assumes we shouldn't have longer randomness keying than the formal strength of the algorithm. That might have been true in the days of silk and cyanide, where keying was a hard problem, but modern computing can generate lots of longer nonces without much effort. In reality, adding longer nonces may not improve the strength of the algorithm itself, but it improves the margin against attack. A nearly practical attack of order 2**80 could be converted to an impractical attack of order 2**96 As far as your proposition is concerned, the performance penalty seems to largely depend on the target platform. Wouldn't using the same set of operations as Chacha prevent an unexpected performance drop in case of lots of short messages ? I don't understand this part of your message. My ancient CBCS formulation that I'll probably use for PPP (Xor'ing a per-session key with a per-packet unique value) is demonstrably much faster than using ChaCha itself to do that same thing. We've been using stream ciphers and pseudo-stream ciphers (made by chaining MACs or chaining block ciphers) to create per-packet nonces for as long as I can remember (over 20 years). You'll see that in CHAP and Photuris and CBCS. So I'm not arguing with Adam's use of ChaCha for it. It just bugs me that we aren't filling in as much randomness as we could! ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
On 9/11/13 10:27 AM, Adam Langley wrote: [attempt two, because I bounced off the mailing list the first time.] On Tue, Sep 10, 2013 at 9:35 PM, William Allen Simpson william.allen.simp...@gmail.com wrote: Why generate the ICV key this way, instead of using a longer key blob from TLS and dividing it? Is there a related-key attack? The keying material from the TLS handshake is per-session information. However, for a polynomial MAC, a unique key is needed per-record and must be secret. Thanks, this part I knew, although it would be good explanatory text to add to the draft. I meant a related-key attack against the MAC-key generated by TLS? Thereby causing you to discard it and not key the ICV with it? Using stream cipher output as MAC key material is a trick taken from [1], although it is likely to have more history than that. (As another example, UMAC/VMAC runs AES-CTR with a separate key to generate the per-record keys, as did Poly1305 in its original paper.) Oh sure. We used hashes long ago. Using AES is insane, but then UMAC is -- to be kind -- not very efficient. My old formulation from CBCS was developed during the old IPsec discussions. It's just simpler and faster to xor the per-packet counter with the MAC-key than using the ChaCha cipher itself to generate per-packet key expansion. I was simply wondering about the rationale for doing it yourself. And worrying a little about the extra overhead on back-to-back packets. If AEAD, aren't the ICV and cipher text generated in parallel? So how do you check the ICV first, then decipher? The Poly1305 key (ICV in your terms?) is taken from a prefix of the ChaCha20 stream output. Thus the decryption proceeds as: 1) Generate one block of ChaCha20 keystream and use the first 32 bytes as a Poly1305 key. 2) Feed Poly1305 the additional data and ciphertext, with the length prefixing as described in the draft. 3) Verify that the Poly1305 authenticator matches the value in the received record. If not, the record can be rejected immediately. 4) Run ChaCha20, starting with a counter value of one, to decrypt the ciphertext. ICV = Integrity Check Value at the end of the packet. So ICV-key. Sometimes MAC-key. Anyway, good explanation! Please add it to the draft. An alternative implementation is possible where ChaCha20 is run in one go on a buffer that consists of 64 zeros followed by the ciphertext. The advantage of this is that it may be faster because the ChaCha20 blocks can be pipelined. The disadvantage is that it may need memory copies to setup the input buffer correctly. A moot advantage, in the case of TLS, of the steps that I outlined is that forgeries are rejected faster. Depends on how swamped the processor. I'm a big fan of rejecting forgeries (and replay attacks) before decrypting. Not everybody is Google with unlimited processing power. ;) Needs a bit more implementation details. I assume there's an implementation in the works. (Always helps define things with something concrete.) I currently have Chrome talking to OpenSSL, although the code needs cleanup of course. Excellent ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] ADMIN: Please pick appropriate Subject lines...
A quick note: many recent postings with very useful content have gone out with entirely inappropriate Subject: lines because of threads shifting topics. Always look at your Subject: line and ask yourself if it should be updated. (And thank all of you for not top posting. It is appreciated.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] About those fingerprints ...
On Sep 11, 2013, at 9:16 AM, Andrew W. Donoho a...@ddg.com wrote: Yesterday, Apple made the bold, unaudited claim that it will never save the fingerprint data outside of the A7 chip. By announcing it publicly, they put themselves on the line for lawsuits and regulatory actions all over the world if they've lied. Realistically, what would you audit? All the hardware? All the software, including all subsequent versions? This is about as strong an assurance as you could get from anything short of hardware and software you build yourself from very simple parts. Why should we trust Cook Co.? They are subject to the laws of the land and will properly respond to lawful subpoenas. What are they doing to ensure the user's confidence that they cannot spread my fingerprint data to the cloud? Apparently not enough to give *you* confidence. But concerned as I am with recent revelations, it doesn't particularly concern *me* nearly as much as many other attack modalities. These questions also apply to things like keychain storage. Who has audited in a public fashion that Apple actually keeps keychains secure? There's been some very limited auditing by outsiders. I found one paper a while back that teased apart the format of the file and figured out how the encryption worked. It appeared to be secure (if perhaps overly complicated), but damned if I can find the paper again. (Searching these days turns up tons of articles that center about the fact that when a keychain is unlocked, you can read its contents. The vulnerability issues are subtle, but they only apply at all if you're on the same machine as the unlocked keychain.) It would be a nice thing if Apple described the algorithms used to encrypt keychains. Perhaps this is the time to push them - and others - to be much more open about their security technologies. Apple seems to be making a point of *selling* on the basis of those technologies, so may be particularly willing/vulnerable on this front. How do we know whether Apple has perverted under secret court order the common crypto and other libraries in every phone and iPad?... You don't. Then again, you don't know if Intel has been forced to include something in its chips that allows someone with appropriate knowledge to download and run privileged code on your machine. All modern Intel server chips include a special management mode exactly to allow remote control over servers in a large datacenter, regardless of how screwed up the software, including the OS software, on them gets. Who's to say there isn't some other way to get into that code? Who you choose to trust and how much is ultimately your call. There are no answers to your questions. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why prefer symmetric crypto over public key crypto?
I agree that randomness-reuse is a major issue. Recently about 55 Bitcoin were stolen by exploiting this, for example: http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ However, it is quite straightforward to make yourself safe from re-used nonces in (EC)DSA, like this: https://github.com/trezor/python-ecdsa/commit/8efb52fad5025ae87b649ff78faa9f8076768065 Whenever the public-key crypto spec says that you have to come up with a random number, don't do it! Instead of just pulling a random number from your PRNG, mix the message into your PRNG to generate a random number which will therefore be unique to this message. Note that you don't have to get anyone else's cooperation in order to do this -- interoperating implementations can't tell how you chose your random number, so they can't complain if you do it this way. Wei Dai's Crypto++ library has done this for ages, for *all* nonces generated in the course of public-key operations. DJB's Ed25519 takes this one step further, and makes the nonce determined *solely* by the message and the secret key, avoiding the PRNG part altogether: http://ed25519.cr.yp.to/papers.html In my opinion, that's the way to go. It applies equally well to (EC)DSA, and still enjoys the above-mentioned interoperability. There is now a standard for this fully-deterministic approach in the works, edited by Thomas Pornin: https://tools.ietf.org/html/rfc6979 . Therefore, Ed25519 or RFC-6979-enhanced (EC)DSA is actually safer than RSA-PSS is with regard to this issue. Regards, Zooko ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] About those fingerprints ...
Yesterday, Apple made the bold, unaudited claim that it will never save the fingerprint data outside of the A7 chip. Why should we trust Cook Co.? I'm not sure it matters. If I want your fingerprint, I'll lift it off your phone. -- Principal Security Engineer Akamai Technology Cambridge, MA ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Squaring Zooko's triangle
From the title it sounds like you're talking about my 2007 proposal: http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two This uses key stretching to increase the work of generating a colliding identifier from 2^64 to 2^88 steps. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] SPDZ, a practical protocol for Multi-Party Computation
http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_result_in_more_secure_computing.asp Breakthrough in cryptography could result in more secure computing (9/10/2013) Tags: computer science, research, security, cryptography Nigel Smart, Professor of Cryptology New research to be presented at the 18th European Symposium on Research in Computer Security (ESORICS 2013) this week could result in a sea change in how to secure computations. The collaborative work between the University of Bristol and Aarhus University (Denmark) will be presented by Bristol PhD student Peter Scholl from the Department of Computer Science. The paper, entitled 'Practical covertly secure MPC for dishonest majority - or: Breaking the SPDZ limits', builds upon earlier joint work between Bristol and Aarhus and fills in the missing pieces of the jigsaw from the groups prior work that was presented at the CRYPTO conference in Santa Barbara last year. The SPDZ protocol (pronounced Speedz) is a co-development between Bristol and Aarhus and provides the fastest protocol known to implement a theoretical idea called Multi-Party Computation. The idea behind Multi-Party Computation is that it should enable two or more people to compute any function of their choosing on their secret inputs, without revealing their inputs to either party. One example is an election, voters want their vote to be counted but they do not want their vote made public. The protocol developed by the universities turns Multi-Party Computation from a theoretical tool into a practical reality. Using the SPDZ protocol the team can now compute complex functions in a secure manner, enabling possible applications in the finance, drugs and chemical industries where computation often needs to be performed on secret data. Nigel Smart, Professor of Cryptology in the University of Bristol's Department of Computer Science and leader on the project, said: We have demonstrated our protocol to various groups and organisations across the world, and everyone is impressed by how fast we can actually perform secure computations. Only a few years ago such a theoretical idea becoming reality was considered Alice in Wonderland style over ambitious hope. However, we in Bristol realised around five years ago that a number of advances in different areas would enable the pipe dream to be achieved. It is great that we have been able to demonstrate our foresight was correct. The University of Bristol is now starting to consider commercialising the protocol via a company Dyadic Security Limited, co-founded by Professor Smart and Professor Yehuda Lindell from Bar-Ilan University in Israel. Note: This story has been adapted from a news release issued by the University of Bristol signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Books on modern cryptanalysis
The recent flood of discussions has touched on many modern attacks on cryptosystems. I'm long out of the crypto world [I last had a crypto clearance *before* differential cryptanalysys was public info!]. Attacks that leak a bit at a time strike me as amazing. I remember reading about attacks that involved running chips at lower voltage than they were supposed to have and that somehow allowed them to be compromised, etc. Anyhow, are there any (not *too* technical) books on the modern techniques for attacking cryptosystems? Thanks. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA -- Too many people, too few sheep -- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Tue, Sep 10, 2013 at 12:56:16PM -0700, Bill Stewart wrote: I thought the normal operating mode for PFS is that there's an initial session key exchange (typically RSA) and authentication, which is used to set up an encrypted session, and within that session there's a DH or ECDH key exchange to set up an ephemeral session key, and then that session key is used for the rest of the session. This is not the case in TLS. The EDH or EECDH key exchange is performed in the clear. The server EDH parameters are signed with the server's private key. https://tools.ietf.org/html/rfc2246#section-7.4.3 In TLS with EDH (aka PFS) breaking the public key algorithm of the server certificate enables active attackers to impersonate the server (including MITM attacks). Breaking the Diffie-Hellman or EC Diffie-Hellman algorithm used allows a passive attacker to recover the session keys (break must be repeated for each target session), this holds even if the certificate public-key algorithm remains secure. -- Viktor. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Books on modern cryptanalysis
On 11 Sep 2013 18:37, Bernie Cosell ber...@fantasyfarm.com wrote: The recent flood of discussions has touched on many modern attacks on cryptosystems. I'm long out of the crypto world [I last had a crypto clearance *before* differential cryptanalysys was public info!]. Attacks that leak a bit at a time strike me as amazing. I remember reading about attacks that involved running chips at lower voltage than they were supposed to have and that somehow allowed them to be compromised, etc. Anyhow, are there any (not *too* technical) books on the modern techniques for attacking cryptosystems? How modern is modern? :-) I have modern cryptanalysys by Christopher Swenson (or at least did have before it was loaned and I moved) and it was an excellent book and crucially was very accessible. Also available in kindle format now. It is 5 years old now though. Regards Max Thanks. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA -- Too many people, too few sheep -- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] NIST reopens RNG public comment period
http://csrc.nist.gov/publications/PubsDrafts.html Sep. 9, 2013 SP 800-90 A Rev 1 B and C DRAFT Draft SP 800-90 Series: Random Bit Generators 800-90 A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators 800-90 B: Recommendation for the Entropy Sources Used for Random Bit Generation 800-90 C: Recommendation for Random Bit Generator (RBG) Constructions In light of recent reports, NIST is reopening the public comment period for Special Publication 800-90A and draft Special Publications 800-90B and 800-90C. NIST is interested in public review and comment to ensure that the recommendations are accurate and provide the strongest cryptographic recommendations possible. The public comments will close on November 6, 2013. Comments should be sent to rbg_comme...@nist.gov. In addition, the Computer Security Division has released a supplemental ITL Security Bulletin titled NIST Opens Draft Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, For Review and Comment (Supplemental ITL Bulletin for September 2013) to support the draft revision effort. Draft SP 800-90 A Rev. 1 (721 KB) Draft SP 800-90 B (800 KB) Draft SP 800-90 C (1.1 MB) signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 09/11/2013 12:54 PM, Alan Braggins wrote: On 10/09/13 15:58, james hughes wrote: On Sep 9, 2013, at 9:10 PM, Tony Arcieri basc...@gmail.com mailto:basc...@gmail.com wrote: On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie b...@links.org mailto:b...@links.org wrote: And the brief summary is: there's only one ciphersuite left that's good, and unfortunately its only available in TLS 1.2: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 A lot of people don't like GCM either ;) Yes, GCM does have implementation sensitivities particularly around the IV generation. That being said, the algorithm is better than most and the implementation sensitivity obvious (don't ever reuse an IV). I think the difficulty of getting a fast constant time implementation on platforms without AES-NI type hardware support are more of a concern. Is this any different from plain old AES-CBC? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote: Perfect Forward Secrecy is not perfect. In fact it is no better than regular public key. The only difference is that if the public key system is cracked then with PFS the attacker has to break every single key exchange and not just the keys in the certificates and if you use an RSA outer with an ECC inner then you double the cryptanalytic cost of the attack (theory as well as computation). I wouldn't mind if it had been called Pretty Good Forward Secrecy instead, but it really is a lot better than regular public key. The main difference is that cracking PFS requires breaking every single key exchange before the attack using cryptanalysis, while cracking the RSA or ECC outer layer can be done by compromising the stored private key, which is far easier to do using subpoenas or malware or rubber hoses than cryptanalysis. (Of course, any messages that were saved by the sender or recipient can still be cracked by non-cryptanalytic techniques as well, but that's a separate problem.) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Books on modern cryptanalysis
On Wed, 11 Sep 2013, Bernie Cosell wrote: Anyhow, are there any (not *too* technical) books on the modern techniques for attacking cryptosystems? Really depends what you mean by attacking; there are attacks at the protocol level (e.g., padding-oracle attacks), at the crypto level (e.g., differential cryptanalysis), and at the physical level (e.g., side-channel attacks). As a general introduction to modern crypto that covers the first two categories a bit, I recommend Introduction to Modern Cryptography by myself and Y. Lindell (soon to come out with a 2nd edition containing even more attacks!). For block-cipher cryptanalysis, I have been very impressed by the material in The Block Cipher Companion by Knudsen and Robshaw. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] About those fingerprints ...
On Sep 11, 2013, at 1:44 PM, Tim Dierks t...@dierks.org wrote: When it comes to litigation or actual examination, it's been demonstrated again and again that people can hide behind their own definitions of terms that you thought were self-evident. For example, the NSA's definition of target, collect, etc., which fly in the fact of common understanding, and exploit the loopholes in English discourse. People can lie to you without actually uttering a demonstrable falsehood or exposing themselves to liability, unless you have the ability to cross-example the assertions. I wouldn't take it quite that far. Government agencies always claim broader leeway than is granted to private actors - and even for NSA and friends, exactly how the courts will react to that language parsing isn't clear. Even their pet FISA court, we now know from declassified documents, has angrily rejected some of this game playing - a second report of this is in today's New York Times. Not that it did much good in terms of changing behavior. And Congress, of course, can interpret stuff as it likes. The standard for civil lawsuits and even more so for regulatory actions is quite a bit lower. If Apple says no fingerprint information leaves the phone, it's going to be interpreted that way. Another article in today's Times reports that Google has had its argument that WiFi is radio hence not subject to wiretap laws soundly rejected by an appeals court. I don't have a precise cite for the Apple claim... http://www.youtube.com/watch?v=TJkmc8-eyvE, starting at about 2:20, is one statement. I won't try to transcribe it here, but short of a technical paper, it's about a strong and direct a statement as you're going to get. People have a queasy feeling about fingerprint recognition. If Apple wants to get them to use it, they have to reassure them. It's a basic result of game theory that the only way you can get people to believe you is to put yourself in harm's way if you lie. ...[I]s the data indirectly accessible? What counts as indirect access? In one sense, the answer to this question is yes: You can use your fingerprint to authorize purchases - at least from the iTunes/App store. It's completely unclear - and Apple really should explain - how the authentication flows work. Since they promise to keep your fingerprint information on the phone, they can't be sending it off to their store servers. On the other hand, if it's a simple go ahead and authorize a charge for user U message, what's to prevent someone from faking such a message? (In other words: If the decision is made on the phone, how do you authenticate the phone?) ...Unless you can cross-examine the assertions with some kind of penalty for dissembling, you can't be sure that an assertion means what you think or hope it means, regardless of how straightforward and direct it sounds. Courts are not nearly as willing to let those before them hide behind complicated and unusual word constructions as you think - especially not when dealing with consumers. It is, in fact, a standard rule of contract law that any ambiguity is to be interpreted contrary to the interests of the drafter. None of this is specific to Apple. Commerce depends on trust, enforced ultimately by courts of law. The ability to govern depends on the consent of the governed - yes, even in dictatorships; they survive as long as enough of the population grudgingly accedes, and get toppled when they lose too much of the consent. And consent ultimately also requires trust. The games the intelligence community have been playing are extremely corrosive to that trust, which is why they are so dangerous. But we have to get beyond that and not see attackers behind every door. The guys who need to be stopped run the NSA and friends, not Apple or Facebook or Google - or even the Telco's. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] About those fingerprints ...
On Sep 11, 2013, at 6:16 AM, Andrew W. Donoho a...@ddg.com wrote: Yesterday, Apple made the bold, unaudited claim that it will never save the fingerprint data outside of the A7 chip. If you watch the video at http://www.apple.com/apple-events/september-2013/, Dan Riccio says at 61:08 that all fingerprint data is encrypted and stored in a secure enclave in the A7 SoC. The data is said to be accessable only by the TouchID sensor. He states that it is never available to other software, it's not stored on Apple servers, or backed up to iCloud. Although technical details are lacking at the moment, this secure enclave sounds a lot like a TPM to me. How will this be any different than storing a BitLocker key in TPM? While it is true that NSA TAO has the capability of penetrating individual iPhones to potentially retrieve this data, it would be much easier to collect those fingerprints from other sources, like your house, or if you drive, the DMV database. -- Ramsey ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Random number generation influenced, HW RNG
On 2013-09-10 4:30 PM, ianG wrote: The question of whether one could simulate a raw physical source is tantalising. I see diverse opinions as to whether it is plausible, and thinking about it, I'm on the fence. Let us consider that source of colored noise with which we are most familiar: The human voice. Efforts to realistically simulate a human voice have not been very successful. The most successful approach has been the ransom note approach, merging together a lot of small clips of an actual human voice. A software simulated raw physical noise source would have to run hundreds of thousands times faster. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart bill.stew...@pobox.comwrote: At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote: Perfect Forward Secrecy is not perfect. In fact it is no better than regular public key. The only difference is that if the public key system is cracked then with PFS the attacker has to break every single key exchange and not just the keys in the certificates and if you use an RSA outer with an ECC inner then you double the cryptanalytic cost of the attack (theory as well as computation). I wouldn't mind if it had been called Pretty Good Forward Secrecy instead, but it really is a lot better than regular public key. My point was that the name is misleading and causes people to look for more than is there. It took me a long time to work out how PFS worked till I suddenly realized that it does not deliver what is advertised. The main difference is that cracking PFS requires breaking every single key exchange before the attack using cryptanalysis, while cracking the RSA or ECC outer layer can be done by compromising the stored private key, which is far easier to do using subpoenas or malware or rubber hoses than cryptanalysis. That is my point precisely. Though the way you put it, I have to ask if PFS deserves higher priority than Certificate Transparency. As in something we can deploy in weeks rather than years. I have no problem with Certificate Transparency. What I do have trouble with is Ben L.'s notion of Certificate Transparency and Automatic Audit in the End Client which I imposes a lot more in the way of costs than just transparency and moreover he wants to push out the costs to the CAs so he can hyper-tune the performance of his browser. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Books on modern cryptanalysis
as amazing. I remember reading about attacks that involved running chips at lower voltage than they were supposed to have and that somehow allowed them to be compromised, etc. Voltage Glitching? A neighborly paper: http://events.ccc.de/congress/2008/Fahrplan/attachments/1191_goodspeed_25c3_bslc.pdf Anyhow, are there any (not *too* technical) books on the modern techniques for attacking cryptosystems? Thanks. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA -- Too many people, too few sheep -- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Laws and cryptography
Hello, Over the past year I was in contact with different cryptographers (I was designing a new symmetric algorithm) and they all told me in order to publish it no governmental authorization was needed. They also told me that they publish paper all the time without having an authorization. However there is the Wassenaar Arrangement between US, Europe and other countries that regulate the export and use of cryptography (http://www.wassenaar.org/introduction/index.html). The Article 3 of the chapter 2 of the european law says : An authorisation shall be required for the export of the dual-use items listed in Annex I (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:134:0001:0269:en:PDF). What they consider dual-use items is A ′′symmetric algorithm′′ employing a key length in excess of 56 bits (http://www.wassenaar.org/controllists/2012/WA-LIST%20%2812%29%201/08%20-%20WA-LIST%20%2812%29%201%20-%20Cat%205P2.doc). The department of the ministry of defense that handle this regulation can't answer if publishing a cryptographic algorithm needs an authorization. However the Wassenaar Arrangement clearly says that material, software and technology need an authorization to be exported / published. What is actually the status of the law about cryptography and publishing new algorithms ? Is the cryptographer that publish a paper without governmental authorization an outlaw ?___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
On 9/11/13 10:37 AM, Adam Langley wrote: On Tue, Sep 10, 2013 at 10:59 PM, William Allen Simpson william.allen.simp...@gmail.com wrote: Or you could use 16 bytes, and cover all the input fields There's no reason the counter part has to start at 1. It is the case that most of the bottom row bits will be zero. However, ChaCha20 is assumed to be secure at a 256-bit security level when used as designed, with the bottom row being counters. If ChaCha/Salsa were not secure in this formulation then I think they would have to be abandoned completely. I kinda covered this in a previous message. No, we should design with the expectation that there's something wrong with every cipher (and every implementation), and strengthen it as best we know how. It's the same principle we learned (often the hard way) in school: * Software designers, assume the hardware has intermittent failures. * Hardware designers, assume the software has intermittent failures. Taking 8 bytes from the initial block and using it as the nonce for the plaintext encryption would mean that there would be a ~50% chance of a collision after 2^32 blocks. This issue affects AES-GCM, which is why the sequence number is used here. Sorry, you're correct there -- my mind is often still thinking of DES with its unicity distance of 2**32, so you had to re-key anyway. Using 16 bytes from the initial block as the full bottom row would work, but it still assumes that we're working around a broken cipher and it prohibits implementations which pipeline all the ChaCha blocks, including the initial one. That may be usefully faster, although it's not the implementation path that I've taken so far. OK. I see the pipeline stall. But does poly1305 pipeline anyway? There is an alternative formulation of Salsa/ChaCha that is designed for random nonces, rather than counters: XSalsa/XChaCha. However, since we have a sequence number already in TLS I've not used it. Aha, I hadn't found this (XSalsa, there doesn't seem to be an XChaCha). Good reading, and some of the same points I was trying to make here. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Summary of the discussion so far
I have attempted to produce a summary of the discussion so far for use as a requirements document for the PRISM-PROOF email scheme. This is now available as an Internet draft. http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt I have left out acknowledgements and references at the moment. That is likely to take a whole day going back through the list and I wanted to get this out. If anyone wants to claim responsibility for any part of the doc then drop me a line and I will have the black helicopter sent round. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of cooperative end-points, PFS doesn't help)
On 08/09/2013 21:51, Perry E. Metzger wrote: I wrote about this a couple of weeks ago, see: http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html In short, https to a server that you /do/ trust. Problem is, joe average is not going to set up his own server. Making setting up your own server user friendly is the same problem as making OTR user friendly, with knobs on. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] About those fingerprints ...
On Wed, Sep 11, 2013 at 1:13 PM, Jerry Leichter leich...@lrw.com wrote: On Sep 11, 2013, at 9:16 AM, Andrew W. Donoho a...@ddg.com wrote: Yesterday, Apple made the bold, unaudited claim that it will never save the fingerprint data outside of the A7 chip. By announcing it publicly, they put themselves on the line for lawsuits and regulatory actions all over the world if they've lied. Realistically, what would you audit? All the hardware? All the software, including all subsequent versions? This is about as strong an assurance as you could get from anything short of hardware and software you build yourself from very simple parts. When it comes to litigation or actual examination, it's been demonstrated again and again that people can hide behind their own definitions of terms that you thought were self-evident. For example, the NSA's definition of target, collect, etc., which fly in the fact of common understanding, and exploit the loopholes in English discourse. People can lie to you without actually uttering a demonstrable falsehood or exposing themselves to liability, unless you have the ability to cross-example the assertions. I don't have a precise cite for the Apple claim, but let's take two summaries: first, from Andrew Apple made the bold, unaudited claim that it will never save the fingerprint data outside of the A7 chip. Initial questions: does this mean they won't send the data to third parties? How about give third parties the ability to extract the data themselves? Does the phrase fingerprint data include all data derived from the fingerprint, such as minutiae? second, from Macworldhttp://www.macworld.com/article/2048520/fingerprint-sensor-in-iphone-5s-is-no-silver-bullet-researchers-say.html: the fingerprint data is encrypted and locked in the device’s new A7 chip, that it’s never directly accessible to software and that it’s not stored on Apple’s servers or backed up to iCloud. Similar questions: is the data indirectly accessible? Is it stored on non-Apple servers? Etc. Unless you can cross-examine the assertions with some kind of penalty for dissembling, you can't be sure that an assertion means what you think or hope it means, regardless of how straightforward and direct it sounds. - Tim ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
On Wed, 11 Sep 2013 06:49:45 +0200 Raphael Jacquot sxp...@sxpert.org wrote: according to http://en.wikipedia.org/wiki/Padding_(cryptography) , most protocols only talk about padding at the end of the cleartext before encryption. now, how about adding some random at the beginning of the cleartext, say, 2.5 times the block size, that is 40 bytes for the example above, of random stuff before the interesting text appears ? The padding at the end is to make sure that you have a full block of data for a block cipher, since your actual message will usually be shorter than a full block. In symmetric systems, it is not per se a security feature. (Asymmetric Adding padding at the front to prevent cryptanalysts from using cribs (that is, known plaintext) seems useless to me. Even if the padding was of random length, it is of necessity going to be short. If you have a technique that depends on known plaintext, crib dragging (that is, trying all of the small number of possibilities) is easy. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Squaring Zooko's triangle
On 11/09/13 12:23, Paul Crowley wrote: From the title it sounds like you're talking about my 2007 proposal: http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two This uses key stretching to increase the work of generating a colliding identifier from 2^64 to 2^88 steps. That part is similar, though I go from 80 bits (actually 79.3 bits) to 100 bits ; and a GPG key fingerprint is similar too, though my mashes are shorter than either, in order to make them easy to input. There is another difference, mashes are easy to write and input without error - the mash alphabet only has 31 characters; A-Z plus 0-9, but 0=O, 1=I=J=L, 2=Z, 5=S. If one of those is misread as another in the subset it doesn't matter when the mash is input. Capitalisation is also irrelevant. However the main, big, huge difference is that a mash isn't just a hash of a public key - in fact as far as Alice, who doesn't understand public keys, is concerned: It's just a secure VIOP number. Maybe she needs an app to use the number on her iphone or googlephone. And another app to use it on her laptop or desktop - but the mash is your secure VOIP number. Or it's a secure email address. Or it's both. Alice need not ever see the real voip IP address, or the real email address - and unless she's a cryptographer and hacker she simply won't be able to contact you without using strong authenticated end-to-end encryption - if the only address she has for you is your mash. Contrast this with your proposal, or a PGP finger print. In order to use one of these, Alice has to have an email address or telephone number to begin with. She also has to find the key and compare it with the hash, in order to use it securely - but she can use the email address or telephone number without ever thinking about downloading or checking the public key. That's just not possible is all you give out is mashes. It's looking at the mash as an address, not as a public key or an adjunct to a public key service - which is why I think it's kind-of turning Zooko's Triangle on it's head (I had never heard of ZT before :( - but I know Zooko though, hi Zooko!). Or maybe not, looking at the web I see ZT in several slightly different forms. But it probably is turning the OP's problem - the napkin scribble - on it's head. You don't write your email and fingerprint on the napkin - just the mash. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
On Sep 11, 2013, at 5:57 PM, Nemo n...@self-evident.org wrote: The older literature requires that the IV be unpredictable (an ill-defined term), but in fact if you want any kind of security proofs for CBC, it must actually be random. Wrong, according to the Rogaway paper you cited. Pull up http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf and read the last paragraph of section I.6 (pages 20-21). Excerpt: We concur, without trying to formally show theorems, that all of the SP 800-38A modes that are secure as probabilistic encryption schemes -- namely, CBC, CFB, and OFB -- will remain secure if the IV is not perfectly random, but only unguessable. The real problem is that unpredictable has no definition. E(0) with the session key is unpredictable to an attacker, but as the paper shows, it cannot safely be used for the IV. Rogoway specifically says that if what you mean by unpredictable is random but biased (very informally), then you lose some security in proportion to the degree of bias: A quantitative statement of such results would “give up” in the ind$ advantage an amount proportional to the ε(q, t) value defined above. I do not think we will too find much guidance from the academic side on [secret IV's], because they tend to assume a can opener... Er, I mean a secure block cipher... And given that assumption, all of the usual modes are provably secure with cleartext IVs. Incorrect on multiple levels. See the paper I mentioned in my response to Perry. If you are going to call me wrong in a public forum, please have the courtesy to be specific. My statement was, in fact, correct in every detail. To rephrase: I actually have no problem with your rephrased statement. My concern was the apparently flippant dismissal of all academic work as assuming a can opener. Yes, there's some like that. There's also some that shows how given weaker assumptions you can create a provably secure block cipher (though in practice it's not clear to me that any real block cipher is really created that way). Beyond that, provably secure is slippery - there are many, many notions of security. Rogoway's paper gives a particular definition for secure and does indeed show that if you have a random IV, CBC attains it. But he also points out that that's a very weak definition of secure - but without authentication, you can't get any more. Do I wish we had a way to prove something secure without assumptions beyond basic mathematics? Absolutely; everyone would love to see that. But we have no idea how to do it. All we can do is follow the traditional path of mathematics and (a) make the assumptions as clear, simple, limited, and obvious as possible; (b) show what happens as the assumptions are relaxed or, sometimes, strengthened. That's what you find in the good cryptographic work. (BTW, if you think I'm defending my own work here - far from it. I left academia and theoretical work behind a very long time ago - I've been a nuts-and-bolts systems guy for decades.) On the matter of a secret IV: It can't actually help much. Any suffix of a CBC encryption (treated as a sequence of blocks, not bytes) is itself a valid CBC encryption. Considered on its own, it has a secret IV; considered in the context of the immediately preceding block, it has a non-secret IV. So a secret IV *at most* protects the very first block of the message. I doubt anyone has tried to formalized just how much it might help simply because it's so small. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Squaring Zooko's triangle
On 09/11/13 13:23, Paul Crowley wrote: From the title it sounds like you're talking about my 2007 proposal: http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two This uses key stretching to increase the work of generating a colliding identifier from 2^64 to 2^88 steps. Hi Paul, Reading your blog, you've came up with a way to encode a public key into a much more memorable string of words. Although the user is not free to choose the name. I go a bit furhter in that direction. In Eccentric Authentication, the usernames (nicknames) are composed of a domain name and an account name. Just like email addresses. The domain name is given by the site, the account name is your choice. As long as it is unique for the site. (There can be a foo at google, a foo at gmail, a foo at yahoo). Just as people expect email addresses to be unique too. To create a full name, the user chooses a site and opens an account there. The account name is free to choose by the user (subject to availabilty and site rules). If the requested account name is not yet given, the sites' local CA signs the name (and the users' public key) into a client certificate. You can use this certificate to log in at the site, but also to encrypt and sign messages. To make names Zooko-proof, you need to make sure that once a name is given (bound to a value), it cannot be changed anymore. For that I use a form of Certificate Registry for logging. Once you've acquired a client certificate, you send it to the registry. It stores the certificate keyed by it's full name. Ie, anyone can lookup the name at the registry and retrieve your certificate. This registry protects against man in the middle attacks. When you encounter a signed message somewhere, you lookup the certificate in the registry. You should expect a single answer, namely, the certificate that matches the signature on the message. If you receive the matching certificate, it is proof that the full name is unique and that the public key in the certificate can be used. If you receive a single answer with a different certificate, you know that someone is trying a mitm between you and the other party. You submit the one that you've discovered to the registry so it will be there for everyone to see. If there are multiple certificates (bearing that same full name) signed by the same CA, it's them who became dishonest. The protocol explicitly calls the site Dishonest. If there are multiple entries bearing the same name but from different CA's, there has been a DNSSEC registry hack. The site should change DNSSEC-registrar. And the key is useless. In general, every once in a while you check that your name is still unique, just to make sure that the site keeps its requirement to hand out each name only once. You also check out the names of new communication partners, just before and slightly longer after first contact. When you still only find your and their names with the expected nickname, there has been no mitm and you have validated that persons public key. (As described in my blog The Holy Grail of Cryptography [0]. You can keep using this persons public key, even if the site gets compromised later. Just add it in your address book. I hope it has become clear how I square the triangle. Feel free to point out omissions, request clarifications. With kind regards, Guido Witmond 0: http://eccentric-authentication.org signature.asc Description: OpenPGP digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
Jerry Leichter leich...@lrw.com writes: The older literature requires that the IV be unpredictable (an ill-defined term), but in fact if you want any kind of security proofs for CBC, it must actually be random. Wrong, according to the Rogaway paper you cited. Pull up http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf and read the last paragraph of section I.6 (pages 20-21). Excerpt: We concur, without trying to formally show theorems, that all of the SP 800-38A modes that are secure as probabilistic encryption schemes -- namely, CBC, CFB, and OFB -- will remain secure if the IV is not perfectly random, but only unguessable. Thank you for the reference, by the way; it is an excellent paper. Back to CBC mode and secret IVs. I do not think we will too find much guidance from the academic side on this, because they tend to assume a can opener... Er, I mean a secure block cipher... And given that assumption, all of the usual modes are provably secure with cleartext IVs. Incorrect on multiple levels. See the paper I mentioned in my response to Perry. If you are going to call me wrong in a public forum, please have the courtesy to be specific. My statement was, in fact, correct in every detail. To rephrase: Security proofs for block cipher modes never depend on keeping the IV confidential from the attacker. Standard practice (e.g. TLS, SSH) is to send it in the clear, and this is fine as far as provable security is concerned. Rogaway's paper does point out, among other things, that naive handling of the IV can break the security proofs; e.g., for the scheme you described earlier in this thread and incorrectly attributed to Rogaway. My point is that if the IV can be kept confidential cheaply, why not? (I am particularly thinking of CTR mode and its relatives.) - Nemo ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Killing two IV related birds with one stone
It occurs to me that specifying IVs for CBC mode in protocols like IPsec, TLS, etc. be generated by using a block cipher in counter mode and that the IVs be implicit rather than transmitted kills two birds with one stone. The first bird is the obvious one: we now know IVs are unpredictable and will not repeat. The second bird is less obvious: we've just gotten rid of a covert channel for malicious hardware to leak information. Note that if you still transmit the IVs, a misimplemented client could still interoperate with a malicious counterparty that did not use the enforced method for IV calculation. If you don't transmit the IVs at all but calculate them, the system will not interoperate if the implicit IVs aren't calculated the same way by both sides, thus ensuring that the covert channel is closed. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Radioactive random numbers
Another whacky idea... Given that there is One True Source of randomness to wit radioactive emission, has anyone considered playing with old smoke detectors? The ionising types are being phased out in favour of optical (at least in Australia) so there must be heaps of them lying around. I know - legislative requirements, HAZMAT etc, but it ought to make for a good thought experiment. -- Dave ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Summary of the discussion so far
Phillip Hallam-Baker hal...@gmail.com writes: I have attempted to produce a summary of the discussion so far for use as a requirements document for the PRISM-PROOF email scheme. This is now available as an Internet draft. http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt First, I suggest removing all remotely political commentary and sticking to technical facts. Phrases like questionable constitutional validity have no place in an Internet draft and harm the document, in my opinion. Second, your section on Perfect Forward Secrecy ignores the purpose of PFS, which has nothing to do with defense against cryptanalytic attacks. The purpose of PFS is this: Should an attacker compel you to disclose your private key, or should they compromise or confiscate the system where your private key is stored, they could then decrypt all of your earlier communications... unless you used PFS. - Nemo ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Radioactive random numbers
On Thu, 12 Sep 2013 08:47:16 +1000 (EST) Dave Horsfall d...@horsfall.org wrote: Another whacky idea... Given that there is One True Source of randomness to wit radioactive emission, has anyone considered playing with old smoke detectors? People have experimented with all sorts of stuff, and you can make any of hundreds of methods from cameras+lava lamp+hash function to sound cards to radioactive sources work if you have budget and time. The issue is not finding ways to generate entropy. The issue is that you need something that's cheap and ubiquitous. User endpoints like cell phones have users to help them generate entropy, but the world's routers, servers, etc. do not have good sources, especially at first boot time, and for customer NAT boxes and the like the price points are vicious. The attraction of methods that use nothing but a handful of transistors is that they can be fabricated on chip and thus have nearly zero marginal cost. The huge disadvantage is that if your opponent can convince chip manufacturers to introduce small changes into their design, you're in trouble. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Availability of plaintext/ciphertext pairs (was Re: In the face of cooperative end-points, PFS doesn't help)
Jerry Leichter leich...@lrw.com writes: The real problem is that unpredictable has no definition. Rogaway provides the definition in the paragraph we are discussing... Rogoway specifically says that if what you mean by unpredictable is random but biased (very informally), then you lose some security in proportion to the degree of bias: A quantitative statement of such results would 'give up' in the ind$ advantage an amount proportional to the e(q, t) value defined above. That e(q,t) value defined above is the probability that the attacker can predict the IV after q samples given time t. That appears to be a very precise definition of predictability, and the smaller it gets, the closer you get to random-IV security. But enough of this particular rat hole. I actually have no problem with your rephrased statement. My concern was the apparently flippant dismissal of all academic work as assuming a can opener. Fair enough; I apologize for my flippancy. Of course the assumption of a strong block cipher is justified by massive amounts of painstaking effort expended in attempts to crack them. Nonetheless, I think it would be wise to build in additional margin anywhere we can get it cheaply. Do I wish we had a way to prove something secure without assumptions beyond basic mathematics? Absolutely; everyone would love to see that. But we have no idea how to do it. I doubt we will have provable complexity lower bounds for useful cryptographic algorithms until well after P vs. NP is resolved. That is, not soon. Until then, provable security is purely about reductions. There is nothing wrong with that. And as I said before, I believe we should worry greatly about theoretical attacks that invalidate those reductions, regardless of how purely academic they may seem to an engineer. On the matter of a secret IV: It can't actually help much. Any suffix of a CBC encryption (treated as a sequence of blocks, not bytes) is itself a valid CBC encryption. Yes, obviously... which is why I wrote I am particularly thinking of CTR mode and its relatives. It's a pity OCB mode is patented. - Nemo ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Killing two IV related birds with one stone
On Sep 11, 2013, at 6:51 PM, Perry E. Metzger wrote: It occurs to me that specifying IVs for CBC mode in protocols like IPsec, TLS, etc. be generated by using a block cipher in counter mode and that the IVs be implicit rather than transmitted kills two birds with one stone. Of course, now you're going to need to agree on two keys - one for the main cipher, one of the IV-generating cipher. Seems like a great deal of trouble to go to to rescue a mode with few advantages. (Perry and I exchanged some private mail on this subject. He claims CBC has an advantage over CTR because CTR allows you to deterministically modify the plaintext under the encryption. I used to favor CBC for that reason as well, though in fact you can modify the text anyway by replaying a previous block - it's just harder to control. I've become convinced, though, the CBC without authentication is way too insecure to use. Once you require authentication, CBC has no advantages I can see over CTR.) But if you insist on CBC ... it's not clear to me whether the attack in Rogoway's paper goes through once authentication is added. If it doesn't, E(0) does just fine (and of course doesn't have to be transmitted). ...Note that if you still transmit the IVs, a misimplemented client could still interoperate with a malicious counterparty that did not use the enforced method for IV calculation. If you don't transmit the IVs at all but calculate them, the system will not interoperate if the implicit IVs aren't calculated the same way by both sides, thus ensuring that the covert channel is closed. Ah, but where did the session and IV-generating keys come from? The same random generator you now don't trust to directly give you an IV? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Killing two IV related birds with one stone
On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter leich...@lrw.com wrote: ...Note that if you still transmit the IVs, a misimplemented client could still interoperate with a malicious counterparty that did not use the enforced method for IV calculation. If you don't transmit the IVs at all but calculate them, the system will not interoperate if the implicit IVs aren't calculated the same way by both sides, thus ensuring that the covert channel is closed. Ah, but where did the session and IV-generating keys come from? The same random generator you now don't trust to directly give you an IV? Certainly, but if you remove most or all covert channels, you've narrowed the problem down to auditing the RNG instead of having to audit much more of the system. It is all a question of small steps towards better assurance. No one measure will fix everything. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
