Re: [Cryptography] Suite B after today's news
On 10 September 2013 11:29, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@links.org writes: We need to get an extension number allocated, since the one it uses clashes with ALPN. It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 anywhere. (In any case -encrypt-then-MAC got there first, these Johnny-come-lately's can find their own ID to squat on :-). Feel free to argue the toss with IANA: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml . In the meantime, I suggest getting a new number would be more productive. Which, apparently, means first getting adopted by the TLS WG. Alternatively, allocate a random number. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 9 September 2013 22:49, Stephen Farrell stephen.farr...@cs.tcd.iewrote: Hi Ben, On 09/09/2013 05:29 PM, Ben Laurie wrote: Perry asked me to summarise the status of TLS a while back ... luckily I don't have to because someone else has: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 In short, I agree with that draft. 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 I don't agree the draft says that at all. It recommends using the above ciphersuite. (Which seems like a good recommendation to me.) It does not say anything much, good or bad, about any other ciphersuite. Claiming that all the rest are no good also seems overblown, if that's what you meant. Other than minor variations on the above, all the other ciphersuites have problems - known attacks, unreviewed ciphers, etc. If you think there are other ciphersuites that can be recommended - particularly ones that are available on versions of TLS other than 1.2, then please do name them. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Seed values for NIST curves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Tony Arcieri wrote: The question is... suitable for what? djb argues it could be used to find a particularly weak curve, depending on what your goals are: http://i.imgur.com/o6Y19uL.png So, the question is then - how do we fix this? I (naively) see two approaches: 1. We as a community create a list of curves that we agree on are good. The list is placed in a document, for example an RFC that clearly states what criteria has been used, what the sources for the curves are and how they has been generated. This allows any user to check the validity and the provenance. 2. Create tools to easily create randomly generated curves including some tool to assess the goodness/quality. Either method should (I believe) be possisble to be integrated into TLS as part of the parameter exchange and negotiation. If I understand DJB correctly EC as such is sound and provides clear benefits compared to RSA. We just need curves that have completely open, traceable and varifiable specifications. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlIu9iIACgkQZoPr8HT30QHziQCeLg8PgNPa2Iz0eB+ZJdgF6caB h1MAoJB/WTs+KrFsG3QjO84PipmyXlY0 =SdNy -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
Ben Laurie b...@links.org writes: We need to get an extension number allocated, since the one it uses clashes with ALPN. It does? draft-ietf-tls-applayerprotoneg-01 doesn't mention ID 0x10 anywhere. (In any case -encrypt-then-MAC got there first, these Johnny-come-lately's can find their own ID to squat on :-). Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 09/10/2013 02:01 PM, Ben Laurie wrote: Claiming that all the rest are no good also seems overblown, if that's what you meant. Other than minor variations on the above, all the other ciphersuites have problems - known attacks, unreviewed ciphers, etc. There are issues, sure. And way too many ciphersuites certainly. If you think there are other ciphersuites that can be recommended - particularly ones that are available on versions of TLS other than 1.2, then please do name them. Since they're talking about it now on the TLS wg list, I'll leave that them (and to folks who're qualified to figure if the NIST, brainpool etc curves are ok, which doesn't include me :-) What I was pointing out is that there's a bit of a gap between no good and not what we'd recommend today. Since getting rid of deployment of old stuff takes years, I think its better that we don't overstate the issues that do exist. But I very much welcome Yaron's draft and hope it shoots along quickly. S. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
Hi Hanno, Please send any comments on this draft to the TLS Working Group mailing list, t...@ietf.org. Thanks, Yaron On 09/10/2013 12:14 AM, Hanno Böck wrote: On Mon, 9 Sep 2013 17:29:24 +0100 Ben Laurie b...@links.org wrote: Perry asked me to summarise the status of TLS a while back ... luckily I don't have to because someone else has: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 In short, I agree with that draft. 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 I don't really see from the document why the authors discourage ECDHE-suites and AES-256. Both should be okay and we end up with four suites: [...] ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Mon, Sep 09, 2013 at 06:41:23AM -0700, Andreas Davour wrote: So there *is* a BTNS implementation, after all. Albeit only for OpenBSD -- but this means FreeBSD is next, and Linux to follow. I might add that as far as I know, this work has not been picked up yet by neither FreeBSD, nor Linux, so if you feel like giving the project a hand pushing it into the mainstream, I'm pretty sure mc would be very happy. I.e. I don't think anything is following on this work unless someone reading this helps making that happen. Personally I have neither the skills nor the contacts needed. To use btns, you need iked installed: from http://hack.org/mc/projects/btns/howto.html Please note: The BTNS implementation is currently very experimental and should be used with caution. Doesn't sound like this is production ready? It isn't. Thus my addition to Eugen's suggestion that other operating system implementations are to follow, and my suggestion that you might want to hack on the project. But, I wanted to let people engaged by the topic of btns know of an implementaion, since at least there is a start! /andreas -- My son has spoken the truth, and he has sacrificed more than either the president of the United States or Peter King have ever in their political careers or their American lives. So how they choose to characterize him really doesn't carry that much weight with me. -- Edward Snowden's Father ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie 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 ;) So we're screwed! Well, aside from maybe this draft supporting Salsa20: http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02 -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
Hi Peter, We really have different designs. I'll comment inline. On 09/09/13 19:12, Peter Fairbrother wrote: On 09/09/13 13:08, Guido Witmond wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. There is only one to remember, your own. If I read it correctly, each participant has one *single identity*? Eccentric does it the other way around, with ecca, you have one or more different identities at *each* site. At least one. But if you want to blog different topics under different id's, no problem. Create another account. I think there are good reasons for having multiple *independent* identities. For example, if your writings get too hot for the blog site owner and they close one account, it doesn't affect the other accounts. If you want, you can destroy the private key so there is nothing that traces you to that account. Or if you want, you can post a proof of ownership of the private key of the account, to show that the site censured a really good post. They closed the account but can't invalidate your key. Again, other accounts are still unaffected. [Taken out technical description] He then checks that you are someone he thinks you are, eg from the photo, checks the fingerprint, and if he wants to contact you he has already got your public key. As you and I have never met, I can't validate your photo, neither half your claimed penis size. ;-) How do I know it's not a Man in the Middle using your picture? Regards, Guido. signature.asc Description: OpenPGP 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 10 September 2013 03:59, james hughes hugh...@mac.com wrote: On Sep 9, 2013, at 2:49 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 09/09/2013 05:29 PM, Ben Laurie wrote: Perry asked me to summarise the status of TLS a while back ... luckily I don't have to because someone else has: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 In short, I agree with that draft. 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 I retract my previous +1 for this ciphersuite. This is hard coded 1024 DHE and 1024bit RSA. It is not hard coded to 1024 bit RSA. I have seen claims that some platforms hard code DHE to 1024 bits, but I have not investigated these claims. If true, something should probably be done. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Random number generation influenced, HW RNG
On 10/09/13 06:29 AM, John Kelsey wrote: But I am not sure how much it helps against tampered chips. If I can tamper with the noise source in hardware to make it predictable, it seems like I should also be able to make it simulate the expected behavior. I expect this is more complicated than, say, breaking the noise source and the internal testing mechanisms so that the RNG outputs a predictable output stream, but I am not sure it is all that much more complicated. How expensive is a lightweight stream cipher keyed off the time and the CPU serial number or some such thing to generate pseudorandom bits? How much more to go from that to a simulation of the expectdd behavior, perhaps based on the same circutry used in the unhacked version to test the noise source outputs? 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. I'd say it might be an unstudied problem -- for us. It's sounding like an interesting EE/CS project, masters or PhD level? If anyone has studied it, I'd bet fair money that the NSA has. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Squaring Zooko's triangle
On 2013-09-10 3:12 AM, Peter Fairbrother wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. 1. And they run away screaming. 2. It only takes 2^50 trials to come up with a valid fingerprint that agrees with your fingerprint except at four non chosen places. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sep 9, 2013, at 9:17 AM, Kent Borg wrote: Which brings into the light the question: Just *why* have so many random number generators proved to be so weak. Your three cases left off an important one: Not bothering to seed the PRNG at all. I think the Java/Android cryptographic (!) library bug that just came up was an instance of that. I think the root of the problem is that programs are written, and bugs squashed, until the program works. Maybe throw some additional testing at it if we are being thorough, but then business pressures and boredom says ship it. That won't catch a PRNG that wasn't seeded, nor a hashed password that wasn't salted, the unprotected URL, the SQL injection path, buffer overflow, etc. Good observations, but I think you're being too pessimistic. All the examples you give *could* be tested - but not by ignorant black box testing - testing that ignores not just what's inside the box, but the actual requirements on what the box is supposed to produce. A non-seeded PRNG, and even one seeded with a very small amount of entropy, will be caught by a test that runs multiple instances of the PRNG from the system starting state and ensures that the ensemble of first outputs (and, for good measure, the first *couple* of outputs) has the right statistics. Similarly, a test that inserts the same password into multiple instances of the same system in the same state can check that the hashed versions have the right statistics. No, these can't catch deliberate attack code which produces random-looking values that the attacker can predict - no test can. But it will catch a broad class of common errors. The others aren't cryptographic issues and require different approaches. The fact that there are bad testing practices - and that those bad practices are used all too often - doesn't mean there aren't good practices, and that they could not be applied. Where the testing is bad because of ignorance of what is actually important and how to test for it, learning from the failures of the past is the way forward - which was exactly the point of PRMG failures classification. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The One True Cipher Suite
On Sep 9, 2013, at 12:00 PM, Phillip Hallam-Baker wrote: Steve Bellovin has made the same argument and I agree with it. Proliferation of cipher suites is not helpful. The point I make is that adding a strong cipher does not make you more secure. Only removing the option of using weak ciphers makes you more secure. I'm not so sure I agree. You have to consider the monoculture problem, combined with the threat you are defending against. The large burst of discussion on this list was set off by Perry's request for ways to protect against the kinds of broad-scale, gather-everything attacks that Snowden has told us the NSA is doing. So consider things from the side of someone attempting to mount this kind of attack: 1. If everyone uses the same cipher, the attacker need only attack that one cipher. 2. If there are thousands of ciphers in use, the attacker needs to attack some large fraction of them. As a defender, if I go route 1, I'd better be really, really, really sure that my cipher won't fall to any attacks over its operational lifetime - which, if it's really universal, will extend many years *even beyond a point where a weakness is found*. On the other hand, even if most of the ciphers in my suite are only moderately strong, the chance of any particular one of them having been compromised is lower. This is an *ensemble* argument, not an *individual* argument. If I'm facing an attacker who is concentrating on my messages in particular, then I want the strongest cipher I can find. Another way of looking at this is that Many Ciphers trades higher partial failure probabilities for lower total/catastrophic failure probabilities. Two things are definitely true, however: 1. If you don't remove ciphers that are found to be bad, you will eventually pollute your ensemble to the point of uselessness. If you want to go the many different ciphers approach, you *must* have an effective way to do this. 2. There must be a large set of potentially good ciphers out there to choose from. I contend that we're actually in a position to create reasonably good block ciphers fairly easily. Look at the AES process. Of the 15 round 1 candidates, a full third made it to the final round - which means that no significant attacks against them were known. Some of the rejected ones failed due to minor certificational weaknesses - weaknesses that should certainly lead you not to want to choose them as the One True Cipher, but which would in and of themselves not render breaking them trivial. And, frankly, for most purposes, any of the five finalists would have been fine - much of the final choice was made for performance reasons. (And, considering Dan Bernstein's work on timing attacks based on table lookups, the performance choices made bad assumptions about actual hardware!) I see no reason not to double-encrypt, using different keys and any two algorithms from the ensemble. Yes, meet-in-the-middle attacks mean this isn't nearly as strong as you might naively think, but it ups the resource demands on the attacker much more than on the defender. Now, you can argue that AES - the only cipher really in the running for the One True Symmetric Cipher position at the moment - is so strong that worrying about attacks on it is pointless - the weaknesses are elsewhere. I'm on the fence about that; it's hard to know. But if you're going to argue for One True Cipher, you must be explicit about this (inherently unprovable) assumption; without it your argument fails. The situation is much more worse for the asymmetric case: We only have a few alternatives available and there are many correlations among their potential weaknesses, so the Many Ciphers approach isn't currently practical, so there's really nothing to debate at this point. Finally, I'll point out that what we know publicly about NSA practices says that (a) they believe in multiple ciphers for different purposes; (b) they believe in the strength of AES, but only up to a certain point. At this point, I'd be very leery of taking anything NSA says or reveals about it practices at face value, but there it is. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Fw: how could ECC params be subverted other evidence
Forwarding because Adam apparently has distinct envelope and From: addresses and didn't notice the bounce. Note that anyone replying and attributing this message to *me* will be laughed at mercilessly as their message is rejected. Perry Begin forwarded message: Date: Tue, 10 Sep 2013 13:42:57 +0200 From: Adam Back a...@cypherspace.org To: Perry E. Metzger pe...@piermont.com Cc: Alexander Klimov alser...@inbox.ru, Cryptography List cryptography@metzdowd.com, Adam Back a...@cypherspace.org Subject: Re: [Cryptography] how could ECC params be subverted other evidence Perry wrote: The Times reported that a standard [...] had been subverted, and there had been much internal congratulation in a memorandum. [...]This was only an example, the context in the Guardian and the Times made it clear others are probably lurking. The important potential backdoor is NIST 186-3 curves in Peter Fairbrother's reply, and I think that would be a good place to focus analysis. (DRBG is largely irrelevant due suspected compromised state since 2007, and very limited use. It is also a different type of issue - not backdoored curves, arguably backdoored parameters). I would like to hear also from other readers, who may have a deeper understanding of EC math and parameter selection. I do think people should be careful to distinguish between three things: 1 political confirmed backdoor claims from whistleblower documents as interpreted by journalists (technical articles by eg Schneier exempted); 2 possible backdoor (showing that a parameter or key generation lacks sufficient fairness in its generation) 3 actual verifiable sabotage (the actual backdoor keys, previously unpublished implausible design failure, software backdoor etc.) We need accuracy because once the dust has settled people will be making crypto protocol design implementation decisions based on what is concluded. Speculate away, but be clear. Adam ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Reports: NSA, GCHQ used forged certs to impersonate Google
The story has been floating around for some days now. Apparently, Man in the Middle attacks have been used quite extensively, including against the Brazilian state oil company, and a major international wire transfer network. http://www.slate.com/blogs/future_tense/2013/09/09/shifting_shadow_stormbrew_flying_pig_new_snowden_documents_show_nsa_deemed.html I think this indicates that Certificate Transparency and similar techniques need to be deployed quickly. CAs have been dead as a form of real assurance for some time now, but at this point the dance party on the grave has gone on a bit too long. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On Sun, 8 Sep 2013 15:22:32 -0400 Perry E. Metzger pe...@piermont.com wrote: Ah, now *this* is potentially interesting. Imagine if you have a crypto accelerator that generates its IVs by encrypting information about keys in use using a key an observer might have or could guess from a small search space. Oh, and of course, if you're doing a DSA style algorithm, you can leak information in your choice of random nonce. This is yet more reason to force protocols to use nonces that are deterministic based on context, and to enforce that. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote: ➢ then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret ➢ services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. How would this work, in practice? Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing the plaintext through with interception is then straightforward. This would be detectable by Bob by the visible client address, but that could be obfuscated (Mallory could exit the session through something tor-like, for example, to avoid advertising their topological location; this would just make it look like Alice is using tor). In the case where Alice is presenting a certificate specifically trusted by Bob, this wouldn't work so well. But my observation is that many TLS-protected streams used by consumers don't use client certificate authentication. As an aside, I see CAs with Chinese organisation names in my browser list. I don't know how to distinguish between enterprises and government from this side of the Pacific (so, presumably, assume they are all government). I had always assumed that this was already happening at the Great Firewall, as a working example of government-sponsored TLS interception with no requirement for expensive crunching of large integers. Joe ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On 10/09/13 14:03, Ben Laurie wrote: On 10 September 2013 03:59, james hughes hugh...@mac.com mailto:hugh...@mac.com wrote: [...] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I retract my previous +1 for this ciphersuite. This is hard coded 1024 DHE and 1024bit RSA. It is not hard coded to 1024 bit RSA. I have seen claims that some platforms hard code DHE to 1024 bits, but I have not investigated these claims. If true, something should probably be done. Yes - hard code them all to 1024-bit. Then dump TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 in the bin where it belongs. Then replace it with a suite such as TLS_DHE2048_WITH_RSA2048_WITH_AES_128_GCM_SHA256. Would a non-cryptographer know what TLS_DHE2048_WITH_RSA2048_WITH_AES_128_GCM_SHA256 meant? No. So for heaven's sake call it Ben's_suite or something, with a nice logo or icon, not TLS_DHE2048_WITH_RSA2048_WITH_AES_128_GCM_SHA256. They won't know what Ben's_suite means either, but they may trust you (or perhaps not, if you are still Working for Google ...) The problem with TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 is that you don't know what you are getting. [ The other problem is of course that the main browsers don't make it easy to find out which suite is actually in use ... :( ] Hmmm, can a certificate have several keylengths to choose from? And, if the suite allows it, can a certificate have an RSA key for authentication and a different RSA key for session key setup (cf RIPA)? -- 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 10, 2013, at 5:49 PM, Perry E. Metzger pe...@piermont.com wrote:
Phil Rogoway has a paper somewhere discussing the right way to
implement cryptographic modes and API's.
It would be useful to get a URL for it.
In particular, he recommends changing the definition of CBC...to
E_0 = E(IV) # Not transmitted
E_{i+1} = E(E_i XOR P_{i+1})
You make no mention there of whether the key used to encrypt the IV
is the same as that used for the plaintext.
As I recall the proposal, it was the same key. (Generating a different one for
this purpose is pointless - it would have to be random, in which case you might
as well generate the IV randomly.)
I presume if you need a lot of IVs (see protocols like IPsec), and have
enough key material, a second key might be of value for that -- but I don't
know what all the ins and outs are, and would prefer to read the literature...
I searched around but couldn't find it; the proposal apparently was not
Rogoway's. It apparently appears in NIST 800-38A (2001), with no citation. In
searching around, I came across a recent, unpublished paper by Rogoway:
http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf
That paper - which does detailed analyses of a large number of modes -
indicates that more recent work has shown that this technique for choosing an
IV is *not* secure (against a certain class of attacks) and recommends against
using it.
I highly recommend that paper. In fact, I highly recommend everything Rogoway
has written. We've been discussing authentication and session key exchange -
he and Bellare wrote about the problem in 1993
http://cseweb.ucsd.edu/users/mihir/papers/eakd.pdf giving provably secure
algorithms for the 2-party case, and two years later
http://www.cs.ucdavis.edu/~rogaway/papers/3pkd.pdf extending the work to the
3-party case.
-- Jerry
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What TLS ciphersuites are still OK?
On Sep 9, 2013, at 9:10 PM, Tony Arcieri basc...@gmail.com wrote: On Mon, Sep 9, 2013 at 9:29 AM, Ben Laurie 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).___ 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 12: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.
Phil Rogoway has a paper somewhere discussing the right way to implement
cryptographic modes and API's. In particular, he recommends changing the
definition of CBC from:
E_0 = IV # Not transmitted
E_{i+1} = E(E_i XOR P_{i+1})
to
E_0 = E(IV) # Not transmitted
E_{i+1} = E(E_i XOR P_{i+1})
This eliminates known plaintext in the first block. If you use this definition
for chained CBC - where you use the final block of a segment as the IV for the
next segment - it also eliminates the known attack (whose name escapes me - it
was based on an attacker being able to insert a prefix to the next segment
because he knows the IV it will use before it gets sent) that even caused
problems for CBC modes in either SSH or TLS.
Beyond this, it changes the requirements on the IV as provided by the user from
random to never repeated for any given key - an easier requirement that's
much less likely to be accidentally violated.
The cost of this is one extra block encryption at each end of the link, per CBC
segment - pretty trivial. When I implemented a protocol that relied on CBC, I
made this the exposed primitive. When I later learned of the prefix attack, I
was gratified to see that my code was already immune.
It actually amazes me that anyone uses the raw IV for the first XOR any more.
-- Jerry
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59 AM, Marcus D. Leech mle...@ripnet.com wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. I have not looked at that. A well thought out well documented RNG based on a sound card is: http://www.av8n.com/turbid/paper/turbid.htm I wrote a very simple one (perhaps not yet trustworthy because it has not had much analysis) based on timer calls. Its documentation discusses a few others: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Squaring Zooko's triangle
On 10/09/13 05:38, James A. Donald wrote: On 2013-09-10 3:12 AM, Peter Fairbrother wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. 1. And they run away screaming. Sorry, I misspoke: you can of course give them your name, just not your telephone number or email address. You give them the hash instead of those. 2. It only takes 2^50 trials to come up with a valid fingerprint that agrees with your fingerprint except at four non chosen places. And that will help an attacker how? To use a hash to contact you Bob has to ask the semi-trusted server to find the hash and then return your matching input string - if he gets it wrong even in one place the server will return a different hash, or no hash at all. Bob can't use a hash which doesn't match exactly. Sound too restrictive? But Bob can't use a telephone number or email address which is wrong in one place, never mind four, either. I was even thinking of using a 60-bit hash fingerprint (with a whole lot of extra work added, to make finding a matching tailored preimage about 2^100 or so total work), so a hash would look like s-NN4H-JS7Y-OTRH but I haven't convinced myself that that would work yet. Mind you, I haven't ruled it out either. There is a flood attack, but it can be defeated by people paying a dollar to the server when they input a hash. -- Peter Fairbrother ___ 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
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Tue, 10 Sep 2013 17:04:51 -0400 Joe Abley jab...@hopcount.ca wrote: On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote: then maybe it's not such a silly accusation to think that root CAs are routinely distributed to multinational secret services to perform MITM session decryption on any form of communication that derives its security from the CA PKI. How would this work, in practice? Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Note that the apparent attacks against Petrobras, SWIFT and others disclosed a few days ago appear to have used precisely this attack. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 10 September 2013 22:04, Joe Abley jab...@hopcount.ca wrote: Suppose Mallory has access to the private keys of CAs which are in the browser list or otherwise widely-trusted. An on-path attack between Alice and Bob would allow Mallory to terminate Alice's TLS connection, presenting an opportunistically-generated server-side certificate with signatures that allow it to be trusted by Alice without pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing the plaintext through with interception is then straightforward. CT makes this impossible to do undetected, of course. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Seed values for NIST curves
On Tue, Sep 10, 2013 at 3:36 AM, Joachim Strömbergson joac...@strombergson.com wrote: 1. We as a community create a list of curves that we agree on are good. The list is placed in a document, for example an RFC that clearly states what criteria has been used, what the sources for the curves are and how they has been generated. This allows any user to check the validity and the provenance. This is more or less what djb did, sans the politics of an Internet standards process (others have written IETF-style guidelines for actually deploying his ciphers) djb's rationale for Curve25519's parameters are provided in the paper. The 2^255-19 constant was selected by a theorem (see Theorem 2.1): http://cr.yp.to/ecdh/curve25519-20060209.pdf -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] soft chewy center
much of the discussion these past few weeks seems to be centered on channel and container protection, secure paths, encrypted file systems, etc. much effort has gone into ensureing opaque environments for data to flow. and while interesting and perhaps useful, not a whole lot of effort seems to targeting the integrity of the data itself. wrapping the soft chewy middle with a hard candy shell can and does hide the fact that your core/data may be rotten. some years back, i was part of a debate on the relative value of crypto - and it was pointed out that for some sectors, crypto ensured _failure_ simply because processing the bits introduced latency. for these sectors, speed was paramount. think HFT or any sort of Flash Mob event where you want in/out as quickly as possible. crypto in and of itself is not a generator of value. Sprinkeling Security/Crypto pixie dust on -everything- can not be a good idea. Just my 0.02 lira. Jari and Stephen, please don't take the IETF there - its a wasteland. /bill ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On 09/10/2013 12:04 PM, Rob Kendrick wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) I haven't actually looked at the code. Conceptually, anything with an ADC can produce thermal and or 1/f noise in the lowest-order bits. Even if it's somewhat biased (like having 60Hz hum embedded in it), with a suitable whitening function, it should produce high-quality entropy at rates of at least several hundred bits/second. The idea is to have *diversity* of physical random sources, to make it difficult for bad actors to subvert said hardware. It's fairly easy to audit these sources of random bits, since said bits won't have had any processing done to them in support of their random properties (unlike the Intel HW RNG). But this is just one aspect of a much-larger problem of trusting trust (in the Thompson sense). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts on hardware randomness sources
On Tue, Sep 10, 2013 at 10:59:37AM -0400, Marcus D. Leech wrote: I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Daniel Silverstone, the author, specifically advises people to not use it. :) B. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Thoughts on hardware randomness sources
I wonder what people's opinions are on things like the randomsound daemon that is available for Linux. Similarly, any hardware with an ADC input can be used as a hardware random noise source, simply by cranking up the gain to suitable levels where the low-order bit is sampling thermal noise. I currently play in the Software Defined Radio space, and there are these very-cheap SDR dongles that could easily be used as a hardware random noise source. I think it would be hard for NSA to hack *all* hardware that includes an ADC and some gain in front of it, since there's a dizzying array of it available, cheaply, for PC hardware. A related issue is getting sites to *use* enhanced random sources, even when easy and cheap. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Fw: how could ECC params be subverted other evidence
On Tue, 10 Sep 2013 16:45:23 -0400 John Kelsey crypto@gmail.com wrote: [DBRG] seemed like a really weird place to put a backdoor, because it was insanely slow, and it seemed unlikely to get any significant use. As an aside, this is just the instance we know about, partially because they screwed up, partially because the New York Times saw fit to let us have confirmation of what was suspected in public. I presume they've been more careful in other places, and that this is not their only work. I presume that they knew this would not be used much and it was only a target of opportunity -- and that they've gotten much more interesting fixes in elsewhere, perhaps even in other parts of the NIST RNG standards (though it would *seem* much harder to gimmick those). And I, at least, had internalized the idea that we weren't going to get intentional bad advice or sabotage from another part of the federal government. You're not the only person feeling betrayed. For many years, the NSA people appeared on our doorsteps offering help in many, many contexts -- IETF for example. The awful part is, many of them may have been completely sincere. The IA side of the house *does*, in fact, depend on COTS hardware to secure most of the Federal Government. They *do* have an interest in keeping US commercial targets safe from attack. However, even if many of the NSA people who participated in standards work were sincere, their good will has been ruined by other NSA people who used the sincere ones as cover for their machinations. We now have to be suspicious of all of them, probably permanently, and that's bad for everyone. I imagine that there are some people inside the NSA now yelling at others about how they've made it ever so much harder to fix the security of most of the Federal Government, which ineed depends on COTS hardware. Now even if they come to us with really good advice, we have no idea if we should take it because we can't know they're not lying to us. None the less, it is done, and those of us on the outside can't depend on NSA participants in standards work any longer. A set of short sighted, foolish decisions have created tragedy for all. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 09/10/13 19:08, Peter Fairbrother wrote: The only assurance given by the scheme is that if a person gave you a hash which he generated himself, and you match it with a string and that string matches what you know about the person (eg their name or photo), then no-one else can have MTM'd it. So what you have is a scheme that allows people who meet *in real life* to exchange keys. Why can't they just exchange an email address and shared password? Or the fingerprint of a GPG-key, it's shorter and must match the email address. Or hand out business cards with your public key in a qr-code. If you meet in person, you've already eliminated all MitM attacks. My scheme does the opposite. It allows *total strangers* to exchange keys securely over the internet. The scheme uses a common interest website where people write signed messages. The site is the *introducer* of the strangers. The technical design with DNSSEC and a Certificate Transparency service detect MitM attacks by a hostile site. (it can't prevent it). *One* secure message is enough to create new channels. Once you have exchanged the key with a stranger, you can create other secure channels. Either direct messaging, chat, voice and video. You name it. So far, the channels are only between two people. But once introduced via a web site, people will exchange other peoples identities between friends, relatives, coworkers. Creating a web of connections, all encrypted with the TLS version du jour. The beauty: the names are readable, human friendly, easy to give out and verify. The protocol does all the certificate validation. Each web site that adopts this scheme works as an introducer. There is no central point to attack. So if the feds would block one site, you don't lose your already validated keys. You won't even lose the connections to other people if you have already established an independent message channel with most of them. Regards, Guido Witmond. 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 Tue, 10 Sep 2013 17:04:04 -0400 Jerry Leichter leich...@lrw.com
wrote:
Phil Rogoway has a paper somewhere discussing the right way to
implement cryptographic modes and API's.
It would be useful to get a URL for it.
In particular, he recommends changing the definition of CBC from:
E_0 = IV # Not transmitted
E_{i+1} = E(E_i XOR P_{i+1})
to
E_0 = E(IV) # Not transmitted
E_{i+1} = E(E_i XOR P_{i+1})
You make no mention there of whether the key used to encrypt the IV
is the same as that used for the plaintext. I presume if you need a
lot of IVs (see protocols like IPsec), and have enough key material, a
second key might be of value for that -- but I don't know what all
the ins and outs are, and would prefer to read the literature...
Perry
--
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Time for djb's Edwards curves in TLS?
Is there a TLS WG draft adding djb's Curve1174 to the list of named curves supported by TLS? If there's credible doubt about the safety of the NIST curves, it seems that Curve1174 (in Edwards form) would make a good choice for EECDH, perhaps coupled with a similar curve with ~512 bits. Slides with rationale: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Detailed paper motivating Curve1174: http://cr.yp.to/elligator/elligator-20130527.pdf The current situation with EECDH over the NIST prime curves not shown compromised, but no longer trusted is rather sub-optimal. -- Viktor. ___ 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: On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter leich...@lrw.com wrote: Even for one-to-one discussions, these days, people want transparent movement across their hardware. If I'm in a chat session on my laptop and leave the house, I'd like to be able to continue on my phone. How do I hand off the conversation - and the keys? I wrote about this a couple of weeks ago, see: http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html Which is pretty spot-on and one of my biggest gripes about OTR. It just doesn't mesh at all with user's expectations. In summary, it would appear that the most viable solution is to make the end-to-end encryption endpoint a piece of hardware the user owns (say the oft mentioned $50 Raspberry Pi class machine on their home net) and let the user interact with it over an encrypted connection (say running a normal protocol like Jabber client to server protocol over TLS, or IMAP over TLS, or https: and a web client.) Sounds like another Freedom Box... Anyway, if we consider each device an end-point to a group-chat that has to be verified at least once by another end-point (and that is a somewhat doable thing, e.g. the socialist millionaire's problem), what about having end-points being able to vouch for other end-points? For example if I introduce my smartphone to an already existing instant messaging chat, I can vouch for it through my PC and if other end-points already trust my PC, there is no reason not to trust my smartphone either. If this is a dumb idea, feel free to point it out. Regards, Walter ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 10/09/13 10:00, Guido Witmond wrote: Hi Peter, We really have different designs. I'll comment inline. On 09/09/13 19:12, Peter Fairbrother wrote: On 09/09/13 13:08, Guido Witmond wrote: I like to look at it the other way round, retrieving the correct name for a key. You don't give someone your name, sorry, that should read You don't give someone your address or telephone number. mea culpa. You can give them your name. you give them an 80-bit key fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is common to all, it just says this is one of that sort of hash. There is only one to remember, your own. If I read it correctly, each participant has one *single identity*? Yes - except of course you can have as many identities as you want. You create them yourself after all. The only assurance given by the scheme is that if a person gave you a hash which he generated himself, and you match it with a string and that string matches what you know about the person (eg their name or photo), then no-one else can have MTM'd it. (maybe the server returns two or three matches, as after a while there will be random birthday collisions. That's why you should check the string matches what you know about the person. But an attacker can't find a hash which matches a particular pre-chosen person by trying, it would take 2^100 work) You can have one for business, one for pretty girls, one for ugly girls - you just have to remember them all (except maybe the one for ugly girls). Or you can write them down. Or put them on your business card. The point is that for practical purposes the hash *is* your telephone number, and/or your email, and/or your facebook page - we just need to get everyone else to install the software to do the lookup, checking, translation etc automagically and behind the scenes in their telephones, browsers, email clients etc. (this was originally designed only for use in a single semi-secure comms program suite - but I don't see why it couldn't be more widely used) [...] As you and I have never met, I can't validate your photo, neither half your claimed penis size. ;-) How do I know it's not a Man in the Middle using your picture? See above. It would take on average 2^79 operations each of which would require 2^20 work to find a matching hash, starting with a picture. Or even just starting with a name, or whatever. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [TLS] New Version Notification for draft-sheffer-tls-bcp-00.txt
On Sep 9, 2013, at 7:30 PM, Michael Ströder michael at stroeder.com wrote: Peter Gutmann wrote: Do you have numbers about the relative and absolute performance impact? Personally I don't see performance problems but I can't prove my position with numbers. MBA-2:tmp synp$ openssl speed dsa1024 dsa2048 […] signverifysign/s verify/s dsa 1024 bits 0.000445s 0.000515s 2247.6 1941.8 dsa 2048 bits 0.001416s 0.001733s706.4577.2 We are arguing about a key exchange that goes from ~1ms to ~3ms (where the cracking goes from yes to no). Yes, this is more but this is absolutely not a problem for PCs or even phones or tablets especially in the light of session keep alive and other techniques that allow a key exchange to last a while. Is the complaint that the server load is too high? Lastly, going a partial step seems strange also. Why do we what to put ourselves through this again so soon? The French government suggests 2048 now (for both RSA and DHE), and will only last 6 years. From http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf La taille minimale du module est de 2048 bits, pour une utilisation ne devant pas depasser lannee 2020. The minimum size of the modulus is 2048 bits for use not to exceed 2020. Pour une utilisation au-dela de 2020, la taille minimale du module est de 4096 bits For use beyond a 2020, the minimum module size is 4096 bits Pardon the bad cut/paste and google translate, but I believe you get the point. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote: On 6 September 2013 18:13, Perry E. Metzger pe...@piermont.com wrote: It would be good to see them abandon RC4 of course, and soon. In favour of what, exactly? We're out of good ciphersuites. Please ask your friendly neighborhood TLS implementor to move fast on http://tools.ietf.org/id/draft-josefsson-salsa20-tls-02.txt . Regards, Zooko ___ 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 11/09/13 01:36 AM, Jerry Leichter wrote: (Generating a different one for this purpose is pointless - it would have to be random, in which case you might as well generate the IV randomly.) In a protocol I wrote with Zooko's help, we generate a random IV0 which is shared in the key exchange. http://www.webfunds.org/guide/sdp/sdp1.html Then, we also move the padding from the end to the beginning, fill it with a non-repeating length-determined value, and expand it to a size of 16-31 bytes. This creates what is in effect an IV1 or second transmitted IV. http://www.webfunds.org/guide/sdp/pad.html iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
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.) Heck, since the average IP packet length is 43, the average TLS record is likely shorter than that! At least half the connection directions, it's going to be rare that the counter itself exceeds 1! 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. This gives more diffusion, at least 2 bits change for every packet, ensure a bit changes in the first 32-bits (highly predictable and vulnerable), and varies the bits affected among 64 positions. Note that I use a secret IV, a cipher key, and an ICV key for CBCS. However, to adapt your current formulation for making your ICV key, 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. 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 message. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
