Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10 October 2013 17:06, John Kelsey wrote: > Just thinking out loud > > The administrative complexity of a cryptosystem is overwhelmingly in key > management and identity management and all the rest of that stuff. So > imagine that we have a widely-used inner-level protocol that can use strong > crypto, but also requires no external key management. The purpose of the > inner protocol is to provide a fallback layer of security, so that even an > attack on the outer protocol (which is allowed to use more complicated key > management) is unlikely to be able to cause an actual security problem. On > the other hand, in case of a problem with the inner protocol, the outer > protocol should also provide protection against everything. > > Without doing any key management or requiring some kind of reliable identity > or memory of previous sessions, the best we can do in the inner protocol is > an ephemeral Diffie-Hellman, so suppose we do this: > > a. Generate random a and send aG on curve P256 > > b. Generate random b and send bG on curve P256 > > c. Both sides derive the shared key abG, and then use SHAKE512(abG) to > generate an AES key for messages in each direction. > > d. Each side keeps a sequence number to use as a nonce. Both sides use > AES-CCM with their sequence number and their sending key, and keep track of > the sequence number of the most recent message received from the other side. > > The point is, this is a protocol that happens *inside* the main security > protocol. This happens inside TLS or whatever. An attack on TLS then leads > to an attack on the whole application only if the TLS attack also lets you do > man-in-the-middle attacks on the inner protocol, or if it exploits something > about certificate/identity management done in the higher-level protocol. > (Ideally, within the inner protcol, you do some checking of the identity > using a password or shared secret or something, but that's application-level > stuff the inner and outer protocols don't know about. > > Thoughts? AIUI, you're trying to make it so that only active attacks work on the combined protocol, whereas passive attacks might work on the outer protocol. In order to achieve this, you assume that your proposed inner protocol is not vulnerable to passive attacks (I assume the outer protocol also thinks this is true). Why should we believe the inner protocol is any better than the outer one in this respect? Particularly since you're using tainted algorithms ;-). ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
On 5 October 2013 20:18, james hughes wrote: > On Oct 5, 2013, at 12:00 PM, John Kelsey wrote: > >> http://keccak.noekeon.org/yes_this_is_keccak.html > > From the authors: "NIST's current proposal for SHA-3 is a subset of the > Keccak family", "one can generate the test vectors for that proposal using > the Kecca kreference code." and this "shows that the [SHA-3] cannot contain > internal changes to the algorithm." > > The process of setting the parameters is an important step in > standardization. NIST has done this and the authors state that this has not > crippled the algorithm. > > I bet this revelation does not make it to Slashdot… > > Can we put this to bed now? I have to take issue with this: "The security is not reduced by adding these suffixes, as this is only restricting the input space compared to the original Keccak. If there is no security problem on Keccak(M), there is no security problem on Keccak(M|suffix), as the latter is included in the former." I could equally argue, to take an extreme example: "The security is not reduced by adding these suffixes, as this is only restricting the input space compared to the original Keccak. If there is no security problem on Keccak(M), there is no security problem on Keccak(preimages of Keccak(42)), as the latter is included in the former." In other words, I have to also make an argument about the nature of the suffix and how it can't have been chosen s.t. it influences the output in a useful way. I suspect I should agree with the conclusion, but I can't agree with the reasoning. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 1 October 2013 09:46, James A. Donald wrote: > On 2013-10-01 18:06, Ben Laurie wrote: > > > > > On 1 October 2013 01:10, James A. Donald wrote: > > Further, google is unhappy that too-clever-code gives too-clever >> programmers too much power, and has prohibited its employees from ever >> doing something like protobufs again. > > > Wat? Sez who? > >Protobufs is code generating code. Not allowed by google style guide. > News to me - where does it say that? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 30 September 2013 23:24, John Kelsey wrote: > Maybe you should check your code first? A couple nist people verified > that the curves were generated by the described process when the questions > about the curves first came out. If you don't quote the message you're replying to, its hard to guess who should check what code - perhaps you could elaborate? > Don't trust us, obviously--that's the whole point of the procedure. But > check your code, because the process worked right when we checked it. > > --John > ___ > 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] encoding formats should not be committee'ized
On 1 October 2013 01:10, James A. Donald wrote: > On 2013-10-01 04:22, Salz, Rich wrote: > >> designate some big player to do it, and follow suit? >> Okay that data encoding scheme from Google protobufs or Facebook thrift. >> Done. >> > > We have a complie to generate C code from ASN.1 code > > Google has a compiler to generate C code from protobufs source > > The ASN.1 compiler is open source. Google's compiler is not. > Ahem: https://code.google.com/p/protobuf/downloads/list. > Further, google is unhappy that too-clever-code gives too-clever > programmers too much power, and has prohibited its employees from ever > doing something like protobufs again. Wat? Sez who? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] TLS2
On 30 September 2013 10:47, Adam Back wrote: > I think lack of soft-hosting support in TLS was a mistake - its another > reason not to turn on SSL (IPv4 addresses are scarce and can only host one > SSL domain per IP#, that means it costs more, or a small hosting company > can > only host a limited number of domains, and so has to charge more for SSL): > and I dont see why its a cost worth avoiding to include the domain in the > client hello. There's an RFC for how to retrofit softhost support via > client-hello into TLS but its not deployed AFAIK. > Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 18 September 2013 22:23, Lucky Green wrote: > According to published reports that I saw, NSA/DoD pays $250M (per > year?) to backdoor cryptographic implementations. I have knowledge of > only one such effort. That effort involved DoD/NSA paying $10M to a > leading cryptographic library provider to both implement and set as > the default the obviously backdoored Dual_EC_DRBG as the default RNG. > Surprise! The "leading blah blah" was RSA: http://stream.wsj.com/story/latest-headlines/SS-2-63399/SS-2-332655/. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 18 September 2013 21:47, Viktor Dukhovni wrote: > On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote: > > > > This is only realistic with DANE TLSA (certificate usage 2 or 3), > > > and thus will start to be realistic for SMTP next year (provided > > > DNSSEC gets off the ground) with the release of Postfix 2.11, and > > > with luck also a DANE-capable Exim release. > > > > What's wrong with name-constrained intermediates? > > X.509 name constraints (critical extensions in general) typically > don't work. > No. They typically work. As usual, Apple are the fly in the ointment. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 18 September 2013 15:30, Viktor Dukhovni wrote: > On Tue, Sep 17, 2013 at 11:48:40PM -0700, Christian Huitema wrote: > > > > Given that many real organizations have hundreds of front end > > > machines sharing RSA private keys, theft of RSA keys may very well be > > > much easier in many cases than broader forms of sabotage. > > > > Or we could make it easy to have one separate RSA key per front end, > signed > > using the main RSA key of the organization. > > This is only realistic with DANE TLSA (certificate usage 2 or 3), > and thus will start to be realistic for SMTP next year (provided > DNSSEC gets off the ground) with the release of Postfix 2.11, and > with luck also a DANE-capable Exim release. > What's wrong with name-constrained intermediates? > > For HTTPS, there is little indication yet that any of the major > browsers are likely to implement DANE support in the near future. > > -- > Viktor. > ___ > 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] End to end
On 16 September 2013 18:49, Phillip Hallam-Baker wrote: > To me the important thing about transparency is that it is possible for > anyone to audit the key signing process from publicly available > information. Doing the audit at the relying party end prior to every > reliance seems a lower priority. > This is a fair point, and we could certainly add on to CT a capability to post-check the presence of a pre-CT certificate in a log. > In particular, there are some type of audit that I don't think it is > feasible to do in the endpoint. The validity of a CT audit is only as good > as your newest notary timestamp value. It is really hard to guarantee that > the endpoint is not being spoofed by a PRISM capable adversary without > going to techniques like quorate checking which I think are completely > practical in a specialized tracker but impractical to do in an iPhone or > any other device likely to spend much time turned off or otherwise > disconnected from the network. > I think the important point is that even infrequently connected devices can _eventually_ reveal the subterfuge. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 10 September 2013 18:00, zooko wrote: > On Fri, Sep 06, 2013 at 06:18:05PM +0100, Ben Laurie wrote: > > On 6 September 2013 18:13, Perry E. Metzger 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 . > We prefer https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/. ___ 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 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] What TLS ciphersuites are still OK?
On 10 September 2013 03:59, james hughes wrote: > > On Sep 9, 2013, at 2:49 PM, Stephen Farrell > 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] What TLS ciphersuites are still OK?
On 9 September 2013 22:49, Stephen Farrell wrote: > > 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] Suite B after today's news
On 10 September 2013 11:29, Peter Gutmann wrote: > Ben Laurie 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
[Cryptography] What TLS ciphersuites are still OK?
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 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Suite B after today's news
On 8 September 2013 11:45, Peter Gutmann wrote: > Ralph Holz writes: > > >BTW, I do not really agree with your argument it should be done via TLS > >extension. > > It's done that way based on discussions on (and mostly off) the TLS list by > various implementers, that was the one that caused the least dissent. > BTW, Steve Henson just pushed an implementation to the master branch of OpenSSL. We need to get an extension number allocated, since the one it uses clashes with ALPN. > > Peter. > ___ > 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] Suite B after today's news
On 7 September 2013 18:47, Ralph Holz wrote: > Hi, > > On 09/07/2013 12:50 AM, Peter Gutmann wrote: > > >> But for right now, what options do we have that are actually implemented > >> somewhere? Take SSL. CBC mode has come under pressure for SSL (CRIME, > BEAST, > >> etc.), and I don't see any move towards TLS > 1.0. > > > > http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-02 fixes > all of > > these, I just can't get any traction on it from the TLS WG chairs. Maybe > > Exactly, precious little movement on that front. Sadly. > > BTW, I do not really agree with your argument it should be done via TLS > extension. I think faster progress could be made by simply introducing > new allowed cipher suites and letting the servers advertise them and > client accept them - this possibly means bypassing IETF entirely. Or, to > keep them in, do it in TLS 1.3. But do it fast, before people start > using TLS 1.2. > I agree. But I think the ciphersuites should be backported to all previous versions. > > I don't really see the explosion of cipher suite sets you give as a > motivation - e.g. in SSH, where really no-one seems to use the > standards, we have a total of 144 or so cipher suites found in our > scans. Yet the thing works, because clients will just ignore the weird > ones. It should be possible in SSL, too, unless openssl/gnutls/nss barfs > at an unexpected suite name - but I don't think so. > Exactly. > > Ralph > > ___ > 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] Using Raspberry Pis
On 26 August 2013 22:43, Perry E. Metzger wrote: > (I would prefer to see hybrid capability systems in such > applications, like Capsicum, though I don't think any such have been > ported to Linux and that's a popular platform for such work.) > FWIW, we're working on a Linux port of Capsicum. Help is always welcome :-) ___ 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 6 September 2013 17:20, Peter Saint-Andre wrote: > Is there a handy list of PFS-friendly > ciphersuites that I can communicate to XMPP developers and admins so > they can start upgrading their software and deployments? > Anything with EDH, DHE or ECDHE in the name... ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6 September 2013 18:13, Perry E. Metzger wrote: > Google is also now (I believe) using PFS on their connections, and > they handle more traffic than anyone. A connection I just made to > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > ECDHE_RSA. > > It would be good to see them abandon RC4 of course, and soon. > In favour of what, exactly? We're out of good ciphersuites. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS
On 6 September 2013 18:24, Perry E. Metzger wrote: > On Fri, 6 Sep 2013 18:18:05 +0100 Ben Laurie wrote: > > On 6 September 2013 18:13, Perry E. Metzger > > wrote: > > > > > Google is also now (I believe) using PFS on their connections, and > > > they handle more traffic than anyone. A connection I just made to > > > https://www.google.com/ came out as, TLS 1.2, RC4_128, SHA1, > > > ECDHE_RSA. > > > > > > It would be good to see them abandon RC4 of course, and soon. > > > > > > > In favour of what, exactly? We're out of good ciphersuites. > > I thought AES was okay for TLS 1.2? Isn't the issue simply that > Firefox etc. still use TLS 1.0? Note that this was a TLS 1.2 > connection. > Apart from its fragility, AES-GCM is still OK, yes. The problem is that there's nothing good left for TLS < 1.2. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
On 4 September 2013 15:49, Perry E. Metzger wrote: > On Wed, 4 Sep 2013 10:37:12 -0400 "Perry E. Metzger" > wrote: > > Phil Karn described a construction for turning any hash function > > into the core of a Feistel cipher in 1991. So far as I can tell, > > such ciphers are actually quite secure, though impractically slow. > > > > Pointers to his original sci.crypt posting would be appreciated, I > > wasn't able to find it with a quick search. > > Answering my own question > > > https://groups.google.com/forum/#!original/sci.crypt/tTWR2qIII0s/iDvT3ptY5CEJ > > Note that Karn's construction need not use any particular hash > function -- he's more or less simply describing how to use a hash > function of any sort as the heart of a Feistel cipher. > His claim is that it is actually faster than DES, not impractically slow. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Thoughts about keys
On 25 August 2013 21:29, Perry E. Metzger wrote:
> [Disclaimer: very little in this seems deeply new, I'm just
> mixing it up in a slightly different way. The fairly simple idea I'm
> about to discuss has germs in things like SPKI, Certificate
> Transparency, the Perspectives project, SSH, and indeed dozens of
> other things. I think I even suggested a version of this exact idea
> several times in the past, and others may have as well. I'm not going
> to pretend to make claims of real originality here, I'm more
> interested in thinking about how to get such things quite widely
> deployed, though it would be cool to hear about prior art just in case
> I decide to publish a tech report.]
>
> One element required to get essentially all messaging on the
> Internet end to end encrypted is a good way to find out what people's
> keys are.
>
> If I meet someone at a reception at a security conference, they might
> scrawl their email address ("al...@example.org") for me on a cocktail
> napkin.
>
> I'd like to be able to then write to them, say to discuss their
> exciting new work on evading censorship of mass releases of stolen
> government documents using genetically engineered fungal spores to
> disseminate the information in the atmosphere worldwide.
>
> However, in our new "everything is always encrypted" world, I'll be
> needing their encryption key, and no one can remember something as
> long as that.
>
> So, how do I translate "al...@example.org" into a key?
>
> Now, the PGP web-of-trust model, which I think is broken, would have
> said "check a key server, see if there's a reasonable trust path
> between you and Alice."
>
> I have an alternative suggestion.
>
> Say that we have a bunch of (only vaguely) trustworthy organizations
> out in the world. (They can use crypto based log protocols of various
> kinds to make sure you don't _really_ need to trust them, but for the
> moment that part doesn't matter.)
>
> Say that Alice, at some point in the past, sent an email message,
> signed in her own key, to such an organization's key server, saying in
> effect "this is al...@example.org's key".
>
> At intervals, the trustworthy organization (and others like it) can
> send out email messages to Alice, encrypted in said key, saying "Hi
> there! Please reply with a message containing this magic cookie,
> encrypted in our key, signed in yours."
>
> If a third party needing the key for al...@example.org queries the
> vaguely trusted server, it will then give them information like "For
> the past six years, we've been sending al...@example.org emails every
> couple of weeks asking her to reply to demonstrate she controls a
> particular public key, and she always has -- new keys have always been
> signed in the old one, too. Here's a log, including various sorts of
> widely witnessed events and hash chains so that if we were lying about
> this we had to be planning to lie about it for a very long time."
>
> Now of course, in the real world, who wants to go through the effort
> of hand replying to query messages to establish a key over time?
> Instead, Alice has some actually trusted software running on her
> computer at home.
>
> She can either leave it to automatically do IMAP queries against her
> mailbox (which could even be GMail or what have you) and reply on her
> behalf, or it could ask her to unlock her key while she's at home in
> the morning having her coffee. However, I think the former is actually
> preferable. We'd rather have an imperfect system that is effortless to
> use but can be bypassed by physically breaking in to someone's home.
> (After all if you did that you probably can bug Alice's hardware
> anyway.)
>
> Alice probably also needs to make sure someone isn't spoofing her
> replies by accessing her IMAP box and replying for her (using a key
> known to the attacker but presumably not to Alice) and then deleting
> the query, but the mere absence of periodic pings from the trusted
> party may be enough to create suspicion, as might doing one's own
> queries against the trusted parties and noticing that the key isn't
> your own.
>
> Presumably, of course, there should be a bunch of such servers out
> there -- not so many that the traffic becomes overwhelming, but not so
> few that it is particularly feasible to take the system off the
> air. (One can speculate about distributed versions of such systems as
> well -- that's not today's topic.)
>
> So, this system has a bunch of advantages:
>
> 1) It doesn't require that someone associated with administrators of
> the domain name you're using for email has to cooperate with deploying
> your key distribution solution. Alice doesn't need her managers to agree
> to let her use the system -- her organization doesn't even need to
> know she's turned it on. Yet, it also doesn't allow just anyone to
> claim to be al...@example.org -- to put in a key, you have to show you
> can receive and reply to emails sent to the mailbox.
>
> 2) You know that, if anyone i
Re: [Cryptography] PRISM PROOF Email
On 22 August 2013 10:36, Phillip Hallam-Baker wrote: > Preventing key substitution will require a combination of the CT ideas > proposed by Ben Laurie (so catenate proof notaries etc) and some form of > 'no key exists' demonstration. We have already outline how to make verifiable maps as well as verifiable logs, which I think is all you need. http://www.links.org/files/RevocationTransparency.pdf. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: English 19-year-old jailed for refusal to disclose decryption key
On 6 October 2010 11:57, Ray Dillinger wrote: > a 19-year-old just got a 16-month jail sentence for his refusal to > disclose the password that would have allowed investigators to see > what was on his hard drive. 16 weeks, says the article. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Hashing algorithm needed
On 14/09/2010 21:16, Marsh Ray wrote: > On 09/14/2010 09:13 AM, Ben Laurie wrote: >> Demo here: https://webid.digitalbazaar.com/manage/ > > "This Connection is Untrusted" So? It's a demo. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Hashing algorithm needed
On 15/09/2010 00:26, Nicolas Williams wrote: > On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote: >> How do you deliver Javascript to the browser securely in the first >> place? HTTP? > > I'll note that Ben's proposal is in the same category as mine (which > was, to remind you, implement SCRAM in JavaScript and use that, with > channel binding using tls-server-end-point CB type). > > It's in the same category because it has the same flaw, which I'd > pointed out earlier: if the JS is delivered by "normal" means (i.e., by > the server), then the script can't be used to authenticate the server. That's one of the reasons I said it was only good for experimenation. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Debian encouraging use of 4096 bit RSA keys
On 14/09/2010 13:15, Perry E. Metzger wrote: > The decision that 1024 bit keys are inadequate for code signing is > likely reasonable. The idea that 2048 bits and not something between > 1024 bits and 2048 bits is a reasonable minimum is perhaps arguable. > One wonders what security model indicated 4096 bits is the ideal > length Given their constraints, what they say (i.e. "to be on the safe side") seems entirely reasonable. Code signing and verification do not occur with great frequency, so a big key is not a big problem. In general, we should resist the temptation to pare security protocols down to the bare minimum - it is this tendency that gave us, for example, the TLS renegotiation attack. A little bit of belt and braces and that would have been a non-issue. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Hashing algorithm needed
On 14/09/2010 12:29, Ian G wrote: > On 14/09/10 2:26 PM, Marsh Ray wrote: >> On 09/13/2010 07:24 PM, Ian G wrote: > >>> 1. In your initial account creation / login, trigger a creation of a >>> client certificate in the browser. >> >> There may be a way to get a browser to generate a cert or CSR, but I >> don't know it. But you can simply generate it at the server side. > > Just to be frank here, I'm also not sure what the implementation details > are here. I somewhat avoided implementation until it becomes useful. FWIW, you can get browsers to generate CSRs and eat the resulting certs. The actual UIs vary from appalling to terrible. Of some interest to me is the approach I saw recently (confusingly named WebID) of a pure Javascript implementation (yes, TLS in JS, apparently), allowing UI to be completely controlled by the issuer. Ultimately this approach seems too risky for real use, but it could be used to prototype UI, perhaps finally leading to something usable in browsers. Slide deck here: http://payswarm.com/slides/webid/#(1) (note, videos use flash, I think, so probably won't work for anyone with their eye on the ball). Demo here: https://webid.digitalbazaar.com/manage/ Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Intel plans crypto-walled-garden for x86
On 14/09/2010 04:58, John Gilmore wrote: > http://arstechnica.com/business/news/2010/09/intels-walled-garden-plan-to-put-av-vendors-out-of-business.ars > > "In describing the motivation behind Intel's recent purchase of McAfee > for a packed-out audience at the Intel Developer Forum, Intel's Paul > Otellini framed it as an effort to move the way the company approaches > security "from a known-bad model to a known-good model." Otellini went > on to briefly describe the shift in a way that sounded innocuous > enough--current A/V efforts focus on building up a library of known > threats against which they protect a user, but Intel would live to > move to a world where only code from known and trusted parties runs on > x86 systems." > > Let me guess -- to run anything but Windows, you'll soon have to > jailbreak even laptops and desktop PC's? They said "known and trusted", right? So that would rule out anything from MSFT... -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Hashing algorithm needed
On 9 September 2010 10:08, James A. Donald wrote: > On 2010-09-09 6:35 AM, Ben Laurie wrote: >> >> What I do in Nigori for this is use DSA. Your private key, x, is the >> hash of the login info. The server has g^x, from which it cannot >> recover x, > > Except, of course, by dictionary attack, hence g^x, being low > entropy, is treated as a shared secret. Indeed, if it is low entropy (I don't think you can assume it is, though I'll readily agree it is likely to be), then it is subject to a dictionary attack. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Hashing algorithm needed
On 8 September 2010 16:45, wrote: > > Hi. > > Just subscribed to this list for posting a specific question. I hope the > question I'll ask is in place here. > > We do a web app with an Ajax-based client. Anybody can download the client > and open the app, only, the first thing the app does is ask for login. > > The login doesn't happen using form submission, nor does it happen via a > known, standard http mechanism. > > What we do is ask the user for some login information, build a hash out of > it, then send it to the server and have it verified. If it checks out, a > session ID is generated and returned to the client. Afterwards, only requests > accompanied by this session ID are answered by the server. > > Right now, the hash sent by the browser to the server is actually not a hash, > but the unhashed login info. This has to be changed, of course. > > What we need is a hashing algorithm that: > - should not generate the same hash every time - i.e. should includen > something random elements > - should require little code to generate > - should allow verification of whether two hashes stem from the same login > data, without having access to the actual login data > > We need to implement the hashing algorithm in Javascript and the verification > algorithm in Java, and it needs to execute reasonably fast, that's why it has > to require little code. None of us is really into cryptography, so the best > thing we could think of was asking for advice from people who grok the domain. Well, you can't always get what you want. What I do in Nigori for this is use DSA. Your private key, x, is the hash of the login info. The server has g^x, from which it cannot recover x, and the client does DSA using x. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: questions about RNGs and FIPS 140
On 27/08/2010 19:38, Joshua Hill wrote: > The fact is that all of the approved deterministic RNGs have places that > you are expected to use to seed the generator. The text of the standard > explicitly states that you can use non-approved non-deterministic RNGs > to seed your approved deterministic RNG. This is nice. > It's an even better situation if you look at the modern deterministic RNGs > described in NIST SP800-90. (You'll want to use these, anyway. They are > better designs and last I heard, NIST was planning on retiring the other > approved deterministic RNGs.) Every design in SP800-90 requires that your > initial seed is appropriately large and unpredictable, and the designs all > allow (indeed, require!) periodic reseeding in similarly reasonable ways. Given that we seem to have agreed that "unpredictable" is kinda hard, I'm amused that SP800-90 requires it. If it is a requirement then I wonder why NIST didn't specify how to generate and validate such a seed? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Merkle Signature Scheme is the most secure signature scheme possible for general-purpose use
On 03/09/2010 17:01, Marsh Ray wrote: > I played with some simulations with randomly-generated mappings, the > observed value would at times wander over 1.0 BoE/log2 N. I think when I did this, I fully enumerated the behaviour of a truncated hash (e.g. the first 20 bits of MD5). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Merkle Signature Scheme is the most secure signature scheme possible for general-purpose use
On 01/09/2010 22:45, Zooko O'Whielacronx wrote: > On Wed, Sep 1, 2010 at 2:55 PM, Ben Laurie wrote: >> Or, to put it another way, in order to show that a Merkle signature is >> at least as good as any other, then you'll first have to show that an >> iterated hash is at least as secure as a non-iterated hash (which seems >> like a hard problem, since it isn't). > > I'm not sure that I agree with you that security of a hash function > used once on an arbitrarily large message is likely to be better than > security of a hash function used a few times iteratively on its own > outputs. That's the whole point - a hash function used on an arbitrary message produces one of its possible outputs. Feed that hash back in and it produces one of a subset of its possible outputs. Each time you do this, you lose a little entropy (I can't remember how much, but I do remember David Wagner explaining it to me when I discovered this for myself quite a few years ago). So, on that basis alone, I reject the "most secure possible" argument. > But regardless of that, I think the fair comparison here is: > > ... show that an iterated hash is more likely to have preimage > resistance than a non-iterated hash is to have collision-resistance. > > And I think it is quite clear that for any real hash function such as > MD5, SHA-1, Tiger, Ripemd, SHA-2, and the SHA-3 candidates that this > does hold! > > What do you think of that argument? I think I've failed to understand why you thing collisions are not a problem for Merkle trees. Also, regardless, you are now talking probabilities and so a claim of "most secure possible" still doesn't apply. Merkle trees, probably the best signature in the world? :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Merkle Signature Scheme is the most secure signature scheme possible for general-purpose use
On 13/06/2010 05:21, Zooko O'Whielacronx wrote: > Folks: > > Regarding earlier discussion on these lists about "the difficulty of > factoring" and "post-quantum cryptography" and so on, you might be > interested in this note that I just posted to the tahoe-dev list: > > "100-year digital signatures" > > http://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004439.html > > Here is an excerpt: > > """ > As David-Sarah [Hopwood] has pointed out, a Merkle Signature Scheme is at > least > as secure as *any* other digital signature scheme, even in the > long-term—even if attackers have quantum computers and the knowledge > of how to solve math problems that we don't know how to solve today. > > If you had some other digital signature scheme (even, for the sake of > argument, a post-quantum digital signature scheme with some sort of > beautiful reduction from some classic math problem), then you would > probably start wanting to digitally sign messages larger than the few > hundreds of bits that the digital signature algorithm natively > handles. Therefore, you would end up hashing your messages with a > secure hash function to generate "message representatives" short > enough to sign. Therefore, your system will actually depend on both > the security of the digital signature scheme *and* the security of a > hash function. With a Merkle Signature Scheme you rely on just the > security of a hash function, so there is one less thing that can go > wrong. That's why a Merkle Signature Scheme is at least as secure as > the best digital signature scheme that you can imagine. :-) > """ Way behind the curve here, but this argument seems incorrect. Merkle signatures rely on the properties of chained hash functions, whereas RSA, for example, only needs a single iteration of the hash function to be good. Or, to put it another way, in order to show that a Merkle signature is at least as good as any other, then you'll first have to show that an iterated hash is at least as secure as a non-iterated hash (which seems like a hard problem, since it isn't). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: About that "Mighty Fortress"... What's it look like?
On 17/08/2010 16:53, Perry E. Metzger wrote: > On Tue, 17 Aug 2010 15:04:00 +0300 Alexander Klimov > wrote: >> On Sat, 31 Jul 2010, Perry E. Metzger wrote: >>> There is no rational reason at all that someone should "endorse" a >>> key when it is possible to simply do a real time check for >>> authorization. There is no reason to sign a key when you can just >>> check if the key is in a database. >> >> Each real-time check reveals your interest in the check. What about >> privacy implications? > > Well, OCSP and such already do online checks in real time, so there is > no difference there between my view of the world and what people claim > should be done for certificates. > > The more interesting question is whether the crypto protocols people > can come up with ways of doing online checks for information about > keys that don't reveal information about what is being asked for. That > would help in both the certificate and non-certificate versions of > such checks. Selective disclosure allows this kind of thing (e.g. "check that x is not on a blacklist without revealing x"). Not sure it's particularly efficient, though... -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 16:01, Perry E. Metzger wrote: > On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie wrote: >> SSH does appear to have got away without revocation, though the >> nature of the system is s.t. if I really wanted to revoke I could >> almost always contact the users and tell them in person. > > No, that's not what SSH does, or rather, it confuses the particular > communications channel (i.e. some out of band mechanism) with the > method that actually de-authorizes the key. > > The point is that in SSH, if a key is stolen, you remove it from the > list of keys allowed to log in to a host. The key now need never be > thought about again. We require no list of "revoked keys" be kept, > just as we required no signed list of keys that were authorized. We > just had some keys in a database to indicate that they were > authorized, and we removed a key to de-authorize it. I am referring to the SSH host key. Fully agree for user keys. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 15:18, Peter Gutmann wrote: > Ben Laurie writes: > >> However, using private keys to prove that you are (probably) dealing with >> the >> same entity as yesterday seems like a useful thing to do. And still needs >> revocation. > > It depends on what you mean by revocation, traditional revocation in the PKI > sense isn't needed because (well apart from the fact that it doesn't work, > you > can't un-say something after you've already said it) if you look at what a PK > or a cert is, it's just a capability, and the way to revoke (in the > capability > sense) a capability is to do something like rename the object that the > capability refers to or use a level of indirection and break the link when > you > want to revoke (in the capability sense) the access. This means that no > matter how many copies of the capability are floating around out there and > whether the relying party checks CRLs or not, they're not going to be able to > get in. Now you are talking my language! Have I mentioned that my new project at Google is all about finding good UI for exposing capabilities to users? >> Is there a good replacement for pk for this purpose? > > Which purpose? If you mean securing the distribution channel for binaries, > here's a very simple one that doesn't need PK at all, it's called a > self-authenticating URL. To use it you go to your software site, and here's > a > real-world example that uses it, the Python Package Index, and click on a > download link, something like > http://pypi.python.org/packages/package.gz#md5= (yeah, I know, it uses > MD5...). This link can point anywhere, because the trusted source of the > link > includes a hash of the binary (and in this case it's a non-HTTPS source, you > can salt and pepper it as required, for exammple make it an HTTPS link and > use > key continuity to manage the cert). In this form the concept is called link > fingerprints, it was actually implemented for Firefox as a Google Summer of > Code project, but then removed again over concerns that if it was present > people might actually use it (!!). It's still available in DL managers like > DownThemAll. The problem here is that it doesn't directly give me an upgrade path. Of course, I agree that this is sufficient to give me a link to the "right" binary, but what about its successors? > Another option is to cryptographically bind the key to the URL, so you again > have a trusted link source for your download and the link is to > https://.downloadsite.com, where is a fingerprint of the > cert > you get when you connect to the site. This does away with the need for a CA, > because the link itself authenticates the cert that's used. Yes, this is of course the YURL scheme. > Then there are other variations, cryptographically generated addresses, ... > all sorts of things have been proposed. > > The killer, again, is the refusal of any browser vendor to adopt any of it. > In the case of FF someone actually wrote the code for them, and it was > rejected. Without support from browser vendors, it doesn't matter what cool > ideas people come up with, it's never going to get any better. > > Peter. > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28 July 2010 15:05, Perry E. Metzger wrote: > On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie wrote: >> On 28/07/2010 14:05, Perry E. Metzger wrote: >> > It is not always the case that a dead technology has failed >> > because of infeasibility or inapplicability. I'd say that a >> > number of fine technologies have failed for other reasons. >> > However, at some point, it becomes incumbent upon the proponents >> > of a failed technology to either demonstrate that it can be made >> > to work in a clear and convincing way, or to abandon it even if, >> > on some level, they are certain that it could be made to work if >> > only someone would do it. >> >> To be clear, I am not a proponent of PKI as we know it, and >> certainly the current use of PKI to sign software has never >> delivered any actual value, and still wouldn't if revocation worked >> perfectly. >> >> However, using private keys to prove that you are (probably) dealing >> with the same entity as yesterday seems like a useful thing to do. > > I agree with that fully. > >> And still needs revocation. > > Does it? > > I will point out that many security systems, like Kerberos, DNSSEC and > SSH, appear to get along with no conventional notion of revocation at > all- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 14:05, Perry E. Metzger wrote: > It is not always the case that a dead technology has failed because of > infeasibility or inapplicability. I'd say that a number of fine > technologies have failed for other reasons. However, at some point, it > becomes incumbent upon the proponents of a failed technology to > either demonstrate that it can be made to work in a clear and > convincing way, or to abandon it even if, on some level, they are > certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. Is there a good replacement for pk for this purpose? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 13:18, Peter Gutmann wrote: > Ben Laurie writes: > >> I find your response strange. You ask how we might fix the problems, then >> you >> respond that since the world doesn't work that way right now, the fixes >> won't >> work. Is this just an exercise in one-upmanship? You know more ways the >> world >> is broken than I do? > > It's not just that the world doesn't work that way now, it's quite likely > that > it'll never work that way (for the case of PKI/revocations mentioned in the > message, not the original SNI). We've been waiting for between 20 and 30 > years (depending on what you define as the start date) for PKI to start > working, and your reponse seems to indicate that we should wait even harder. > If I look at the mechanisms we've got now, I can identify that commercial PKI > isn't helping, and revocations aren't helping, and work around that. I'm > after effective practical solutions, not just "a solution exists, QED" > solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 09:57, Peter Gutmann wrote: > Ben Laurie writes: >> On 24/07/2010 18:55, Peter Gutmann wrote: >>> - PKI dogma doesn't even consider availability issues but expects the >>> straightforward execution of the condition "problem -> revoke cert". For >>> a >>> situation like this, particularly if the cert was used to sign 64-bit >>> drivers, I wouldn't have revoked because the global damage caused by that >>> is >>> potentially much larger than the relatively small-scale damage caused by >>> the >>> malware. So alongside "too big to fail" we now have "too widely-used to >>> revoke". Is anyone running x64 Windows with revocation checking enabled >>> and >>> drivers signed by the Realtek or JMicron certs? >> >> One way to mitigate this would be to revoke a cert on a date, and only >> reject >> signatures on files you received after that date. > > This wouldn't make any difference, except for the special case of x64, > signatures are only verified on install, so existing installed code isn't > affected and anything new that's being installed is, with either form of > sig-checking. Obviously if you are going to change revocation you can also change when signatures are checked. This hardly seems like a show-stopper. > In any case though the whole thing is really a moot point given the sucking > void that is revocation-handling, the Realtek certificate was revoked on the > 16th but one of my spies has informed me that as of yesterday it was still > regarded as valid by Windows. Previous experience with revoked certs has > been > that they remain valid more or less indefinitely (which would be really great > if CAs offered something like domain-tasting for certs, you could get as many > free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. > The way to revoke a cert for signed malware is to wait 0-12 hours for the > malware signature to be added to AV databases, not to actually expect PKI to > work. At which time they release another version? Doesn't sound like the optimal answer to me. I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 00:14, Paul Tiemann wrote: > On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote: > >> On 24/07/2010 18:55, Peter Gutmann wrote: >>> - PKI dogma doesn't even consider availability issues but expects the >>> straightforward execution of the condition "problem -> revoke cert". For a >>> situation like this, particularly if the cert was used to sign 64-bit >>> drivers, I wouldn't have revoked because the global damage caused by that >>> is >>> potentially much larger than the relatively small-scale damage caused by >>> the >>> malware. So alongside "too big to fail" we now have "too widely-used to >>> revoke". Is anyone running x64 Windows with revocation checking enabled >>> and >>> drivers signed by the Realtek or JMicron certs? >> >> One way to mitigate this would be to revoke a cert on a date, and only >> reject signatures on files you received after that date. > > I like that idea, as long as a verifiable timestamp is included. > > Without a trusted timestamp, would the bad guy be able to backdate the > signature? Note that I avoided this issue by using the date of receipt. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 28/07/2010 01:07, Paul Tiemann wrote: > "There is a long list of flyblown metaphors which could similarly be > got rid of if enough people would interest themselves in the job; and > it should also be possible to laugh the not un- formation out of > existence*... > > *One can cure oneself of the not un- formation by memorizing this > sentence: A not unblack dog was chasing a not unsmall rabbit across a > not ungreen field. Had he succeeded in this mission, then we could never have had John Major on Spitting Image being "not inconsiderably incandescent". -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 24/07/2010 18:55, Peter Gutmann wrote: > - PKI dogma doesn't even consider availability issues but expects the > straightforward execution of the condition "problem -> revoke cert". For a > situation like this, particularly if the cert was used to sign 64-bit > drivers, I wouldn't have revoked because the global damage caused by that is > potentially much larger than the relatively small-scale damage caused by the > malware. So alongside "too big to fail" we now have "too widely-used to > revoke". Is anyone running x64 Windows with revocation checking enabled and > drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 27/07/2010 15:11, Peter Gutmann wrote: > The intent with posting it to the list was to get input from a collection of > crypto-savvy people on what could be done. The issue had previously been > discussed on a (very small) private list, and one of the members suggested I > post it to the cryptography list to get more input from people. The follow-up > message (the "Part II" one) is in a similar vein, a summary of a problem and > then some starters for a discussion on what the issues might be. Haven't we already decided what to do: SNI? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Intel to also add RNG
On 12 July 2010 18:13, Jack Lloyd wrote: > On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote: > >> BTW, let me note that if Intel wanted to gimmick their chips to make >> them untrustworthy, there is very little you could do about it. The >> literature makes it clear at this point that short of carefully >> tearing apart and analyzing the entire chip, you're not going to catch >> subtle behavioral changes designed to allow attackers backdoor >> access. Given that, I see little reason not to trust them on an RNG, >> and I wish they would make it a standard part of the architecture >> already. > > I think it's important to make the distinction between trusting Intel > not to have made it actively malicious, and trusting them to have > gotten it perfectly correct in such a way that it cannot fail. > Fortunately, the second problem, that it is a well-intentioned but > perhaps slightly flawed RNG [*], could be easily alleviated by feeding > the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take > your pick I guess). And the first could be solved by also feeding your > CSPRNG with anything that you would have fed it with in the absense of > the hardware RNG - in that case, you're at least no worse off than you > were before. (Unless your PRNG's security can be negatively affected > by non-random or maliciously chosen inputs, in which case you've got > larger problems). Several years ago I reviewed a new design for FreeBSD's PRNG. It was vulnerable to sources that had high data rates but low entropy (they effectively "drowned out" lower data rate sources). This was fixed, but I wonder how common an error it is? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Intel to also add RNG
On 2 July 2010 13:19, Eugen Leitl wrote: > > http://www.technologyreview.com/printer_friendly_article.aspx?id=25670&channel=Briefings§ion=Microprocessors > > Tuesday, June 29, 2010 > > Nanoscale Random Number Circuit to Secure Future Chips > > Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Spy/Counterspy
On 10 July 2010 11:57, Jerry Leichter wrote: > Beyond simple hacking - someone is quoted saying "You can consider GPS a > little like computers before the first virus - if I had stood here before > then and cried about the risks, you would've asked 'why would anyone > bother?'." - among the possible vulnerabilities are to high-value cargo, > armored cars, and rental cars tracked by GPS. As we build more and more > "location-aware" services, we are inherently building more > "false-location-vulnerable" services at the same time. Most location-aware services should not care whether the location is real or false, for privacy reasons. Agree about the issue of high-value cargo (but I guess they'll just have to use more reliable mechanisms, like maps and their eyes), don't care about rental cars. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: "Against Rekeying"
On 24/03/2010 08:28, Simon Josefsson wrote: > "Perry E. Metzger" writes: > >> Ekr has an interesting blog post up on the question of whether protocol >> support for periodic rekeying is a good or a bad thing: >> >> http://www.educatedguesswork.org/2010/03/against_rekeying.html >> >> I'd be interested in hearing what people think on the topic. I'm a bit >> skeptical of his position, partially because I think we have too little >> experience with real world attacks on cryptographic protocols, but I'm >> fairly open-minded at this point. > > One situation where rekeying appears to me not only useful but actually > essential is when you re-authenticate in the secure channel. > > TLS renegotiation is used for re-authentication, for example, when you > go from no user authentication to user authenticated, or go from user X > authenticated to user Y authenticated. This is easy to do with TLS > renegotiation: just renegotiate with a different client certificate. > > I would feel uncomfortable using the same encryption keys that were > negotiated by an anonymous user (or another user X) before me when I'm > authentication as user Y, and user Y is planning to send a considerably > amount of traffic that user Y wants to be protected. Trusting the > encryption keys negotiated by user X doesn't seem prudent to me. > Essentially, I want encryption keys to always be bound to > authentication. Note, however, that one of the reasons the TLS renegotiation attack was so bad in combination with HTTP was that reauthentication did not result in use of the new channel to re-send the command that had resulted in a need for reauthentication. This command could have come from the attacker, but the reauthentication would still be used to "authenticate" it. In other words, designing composable secure protocols is hard. And TLS isn't one. Or maybe it is, now that the channels before and after rekeying are bound together (which would seem to invalidate your argument above). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: 1024 bit RSA cracked?
On 17/03/2010 05:03, James Muir wrote: > ** I just had the following realization: I had assumed that the authors > were attacking an openssl *server* running on the fpga board, but > perhaps that is not so. They don't seem to make that specific claim. > They claim only to be attacking an "unmodi ed version of the OpenSSL > library". It is possible that they only created a toy RSA application > that generates signatures using the openssl library (i.e. by making > calls to specific openssl functions). This would explain why they don't > discuss message blinding -- because they didn't enable it in their toy > application! I suspect that's what they did. In that case, their > experimental results say very little about the susceptibility of an > openssl server to fault attacks. Wow... if I'm correct, then the > authors really need to be more clear about exactly what they did. What everyone said... Plus ... even with their fix, all they have to do is induce two errors in quick succession and OpenSSL will spit out the key whole. In any case, this all seems entirely pointless: in order to mount the attack, you have to have intimate access to the hardware. In other words, what they have demonstrated is that DRM doesn't work. Groundbreaking. Of course, the annoying fall-out is that there will be (already is) a knee-jerk clamour for us to "fix" OpenSSL. Well, I've got news: securing anything in the face of an unpredictable CPU seems well beyond the scope of the OpenSSL project - or any other crypto library I am aware of. I'm not even sure it's possible. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: TLS break
On Mon, Nov 16, 2009 at 11:30 AM, Bernie Cosell wrote: > As I understand it, this is only really a vulnerability in situations > where a command to do something *precedes* the authentication to enable > the command. Â The obvious place where this happens, of course, is with > HTTPS where the command [GET or POST] comes first and the authentication > [be it a cookie or form vbls] comes later. This last part is not really accurate - piggybacking the evil command onto authentication that is later presented is certainly one possible attack, but there are others, such as the Twitter POST attack and the SMTP attack outlined by Wietse Venema (which doesn't work because of implementation details, but _could_ work with a different implementation). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Sun, Nov 8, 2009 at 7:07 AM, John Levine wrote: > So before I send it off, if people have a moment could you look at it > and tell me if I'm missing something egregiously obvious? Â Tnx. > > I've made it an entry in my blog at > > http://weblog.johnlevine.com/Money/securetrans.html Haven't read this thoroughly yet, though I think I disagree with the idea that the display should be minimal - imagine checking out of amazon on a 2-line display. Tedious. Anyway, I should mention my own paper on this subject (with Abe Singer) from NSPW 2008, "Take The Red Pill _and_ The Blue Pill": http://www.links.org/files/nspw36.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
On Sat, Oct 17, 2009 at 10:23 AM, John Gilmore wrote: >> Even plain DSA would be much more space efficient on the signature >> side - a DSA key with p=2048 bits, q=256 bits is much stronger than a >> 1024 bit RSA key, and the signatures would be half the size. And NIST >> allows (2048,224) DSA parameters as well, if saving an extra 8 bytes >> is really that important. > > DSA was (designed to be) full of covert channels. > >> Given that they are attempted to optimize for minimal packet size, the >> choice of RSA for signatures actually seems quite bizarre. > > It's more bizarre than you think. Â But packet size just isn't that big > a deal. Â The root only has to sign a small number of records -- just > two or three for each top level domain -- and the average client is > going to use .com, .org, their own country, and a few others). Â Each > of these records is cached on the client side, with a very long > timeout (e.g. at least a day). Â So the total extra data transfer for > RSA (versus other) keys won't be either huge or frequent. Â DNS traffic > is still a tiny fraction of overall Internet traffic. Â We now have > many dozens of root servers, scattered all over the world, and if the > traffic rises, we can easily make more by linear replication. Â DNS > *scales*, which is why we're still using it, relatively unchanged, > after more than 30 years. > > The bizarre part is that the DNS Security standards had gotten pretty > well defined a decade ago, when one or more high-up people in the IETF > decided that "no standard that requires the use of Jim Bidzos's > monopoly crypto algorithm is ever going to be approved on my watch". > Jim had just pissed off one too many people, in his role as CEO of RSA > Data Security and the second most hated guy in crypto. Â (NSA export > controls was the first reason you couldn't put decent crypto into your > product; Bidzos's patent, and the way he licensed it, was the second.) > This IESG prejudice against RSA went so deep that it didn't matter > that we had a free license from RSA to use the algorithm for DNS, that > the whole patent would expire in just three years, that we'd gotten > export permission for it, and had working code that implemented it. > So the standard got sent back to the beginning and redone to deal with > the complications of deployed servers and records with varying algorithm > availability (and to make DSA the "officially mandatory" algorithm). > Which took another 5 or 10 years. ts a fun story, but... RFC 4034 says RSA/SHA1 is mandatory and DSA is optional. I wasn't involved in DNSSEC back then, and I don't know why it got redone, but not, it seems, to make DSA mandatory. Also, the new version is different from the old in many more ways that just the introduction of DSA. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
On Thu, Oct 15, 2009 at 12:39 AM, Jack Lloyd wrote: > On Wed, Oct 14, 2009 at 10:43:48PM -0400, Jerry Leichter wrote: >> If the constraints elsewhere in the system limit the number of bits of >> signature you can transfer, you're stuck. Â Presumably over time you'd >> want to go to a more bit-efficient signature scheme, perhaps using >> ECC. > > Even plain DSA would be much more space efficient on the signature > side - a DSA key with p=2048 bits, q=256 bits is much stronger than a > 1024 bit RSA key, and the signatures would be half the size. And NIST > allows (2048,224) DSA parameters as well, if saving an extra 8 bytes > is really that important. > > Given that they are attempted to optimize for minimal packet size, the > choice of RSA for signatures actually seems quite bizarre. DSA can be used in DNSSEC - unfortunately it is optional, though. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann wrote: > More generally, I can't see that implementing client-side certs gives you much > of anything in return for the massive amount of effort required because the > problem is a lack of server auth, not of client auth. Â If I'm a phisher then I > set up my bogus web site, get the user's certificate-based client auth > message, throw it away, and report successful auth to the client. Â The browser > then displays some sort of indicator that the high-security certificate auth > was successful, and the user can feel more confident than usual in entering > their credit card details. Â All you're doing is building even more substrate > for phishing attacks. > > Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, > you're not getting any improvement, and potentially just making things worse > by giving users a false sense of security. I certainly agree that if the problem you are trying to solve is server authentication, then client certs don't get you very far. I find it hard to feel very surprised by this conclusion. If the problem you are trying to solve is client authentication then client certs have some obvious value. That said, I do tend to agree that mutual auth is also a good avenue to pursue, and the UI you describe fits right in with Chrome's UI in other areas. Perhaps I'll give it a try. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Perry E. Metzger wrote: > Yet another reason why you always should make the crypto algorithms you > use pluggable in any system -- you *will* have to replace them some day. In order to roll out a new crypto algorithm, you have to roll out new software. So, why is anything needed for "pluggability" beyond versioning? It seems to me protocol designers get all excited about this because they want to design the protocol once and be done with it. But software authors are generally content to worry about the new algorithm when they need to switch to it - and since they're going to have to update their software anyway and get everyone to install the new version, why should they worry any sooner? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: cleversafe says: 3 Reasons Why Encryption is Overrated
Zooko Wilcox-O'Hearn wrote:
> I don't think there is any basis to the claims that Cleversafe makes
> that their erasure-coding ("Information Dispersal")-based system is
> fundamentally safer, e.g. these claims from [3]: "a malicious party
> cannot recreate data from a slice, or two, or three, no matter what the
> advances in processing power." ... "Maybe encryption alone is 'good
> enough' in some cases now - but Dispersal is 'good always' and
> represents the future."
Surely this is fundamental to threshold secret sharing - until you reach
the threshold, you have not reduced the cost of an attack?
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Client Certificate UI for Chrome?
So, I've heard many complaints over the years about how the UI for client certificates sucks. Now's your chance to fix that problem - we're in the process of thinking about new client cert UI for Chrome, and welcome any input you might have. Obviously fully-baked proposals are more likely to get attention than vague suggestions. I imagine I may well hear "what about the UI around server certificates?" - fair enough, feel free, and I'll see what I can do. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The clouds are not random enough
On Sat, Aug 1, 2009 at 10:06 PM, Jerry Leichter wrote: >> Why Cloud Computing Needs More Chaos: >> >> http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html >> >> [Moderator's note: ... the article is about a growing problem -- the >> lack of good quality random numbers in VMs provided by services like EC2 >> and the effect this has on security. --Perry] > > The problem is broader than this. Â A while back, I evaluated a technology > that did it best to solve a basically insoluble problem: Â How does a server, > built on stock technology, keep secrets that it can use to authenticate with > other servers after an unattended reboot? Â Without tamper-resistant hardware > that controls access to keys, anything the software can get at at boot, an > attacker who steals a copy of a backup, say - can also get at. Â So, the > trick is to use a variety of measurements of the hardware - amount of > memory, disk sizes, disk serial numbers, whatever you can think of that > varies from machine to machine and is not stored in a backup - and combines > them to produce a key that encrypts the important secrets. Â Since hardware > does need to be fixed or upgraded at times, a good implementation will use > some kind of "m unchanged out of n measurements" algorithm. Â Basically, this > is the kind of thing Microsoft uses to lock license keys to particular > instances of hardware. Â Yes, it can be broken - but you can make breaking it > a great deal of work. > > Virtualization changes all of this. Â Every copy of a virtual machine is will > be identical as far as most of these measurements are concerned. I'd imagine (I'm not particularly interested in licence enforcement, so I really am imagining), that the opposite was the problem: i.e. that the host could run you on any VM which might have wildly varying characteristics, depending on what the real machine underneath was, and what else you were sharing with. So, every time you see the measurements, they'll be different. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Factoring attack against RSA based on Pollard's Rho
Paul Hoffman wrote: > At 8:07 PM -0700 6/5/09, Greg Perry wrote: >> Greetings list members, >> >> I have published a unique factoring method related to Pollard's Rho >> that is published here: >> >> http://blog.liveammo.com/2009/06/factoring-fun/ >> >> Any feedback would be appreciated. > > Is there any practical value to this work? That's a serious question. > The main statement about the value is "This is a factoring attack > against RSA with an up to 80% reduction in the search candidates > required for a conventional brute force key attack." Does that mean > that it reduces the search space for a 1024-bit RSA key to, at best > 205 bits (0.2 * 1024) of brute force? No, no. You don't multiply by .2, you add log_2(.2), which is around -3. So, 1021 bits. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
Steven M. Bellovin wrote: > We've become prisoners of dogma here. In 1979, Bob Morris and Ken > Thompson showed that passwords were guessable. In 1979, that was > really novel. There was a lot of good work done in the next 15 years > on that problem -- Spaf's empirical observations, Klein's '90 paper on > improving password security, Lamport's algorithm that gave rise to > S/Key, my and Mike Merritt's EKE, many others. Guess what -- we're not > living in that world now. We have shadow password files on Unix > systems; we have Kerberos; we have SecurID; we have SSL which rules out > the network attacks and eavesdropping that EKE was intended to counter; > etc. We also have web-based systems whose failure modes are not nearly > the same. Why do we think that the solutions are the same? There was > a marvelous paper at Hotsec '07 that I resent simply because the > authors got there before me; I had (somewhat after them) come to the > same conclusions: the defenses we've built up against password failure > since '79 don't the problems of today's world. We have to recognize > the new problems before we can solve them. (I *think* that the paper > is at > http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf > but I'm on an airplane now and can't check... That's a pretty annoying paper. Firstly, I don't care about the average rate of account compromise for sites that host my stuff, I only care about _my_ account. This means that I cannot, despite their claim, write down my long, "secret" user ID because if anyone ever sees it, I'm sunk because of the short password they are advocating. Secondly, they claim that user IDs are in practice secret, on the basis that if they weren't, then sites would be experiencing massive DoS attacks. To prove this claim, they cite a case where SSNs are used as user IDs. Now, if there's one thing we know, it's that SSNs aren't even a little bit secret. Therefore the reason there is no widepsread DoS is because no-one wants to mount the attack. Thirdly, they really need to learn when to use apostrophes! Incidentally, the reason we don't use EKE (and many other useful schemes) is not because they don't solve our problems, its because the rights holders won't let us use them. > But usability is *the* problem, with server and client penetration a > close second. On this we agree. We do have any number of decent cryptographic schemes that would complete solve phishing. All we have to do is figure out: a) How to show the user that he is actually using the scheme and is not being phished. b) Get it rolled out everywhere. I am not holding my breath, though perhaps '09 is the year for action? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Cat Okita wrote: > On Sat, 21 Feb 2009, Peter Gutmann wrote: >> This points out an awkward problem though, that if you're a commercial >> vendor >> and you have a customer who wants to do something stupid, you can't >> afford not >> to allow this. While my usual response to requests to do things >> insecurely is >> "If you want to shoot yourself in the foot then use CryptoAPI", I can >> only do >> this because I care more about security than money. For any >> commercial vendor >> who has to put the money first, this isn't an option. > > That's not entirely true -- even commercial vendors have things like > ongoing support to consider, and some customers just cost more money > than they're worth. Furthermore, its entirely simplistic to suggest that "money first" == "do any fool thing a customer demands". Some businesses do actually care about their reputation, even if only because they believe that will make them more money in the long run. Plus, even the most accommodating company will draw the line somewhere - not every foolish thing is profitable, even if a customer wants it. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Stephan Neuhaus wrote: > Many mistakes in crypto coding come from the fact that API developers > have so far very successfully shifted the burden of secure usage to the > application developer, the API user. But I believe this hasn't worked > and needs to be changed. I totally agree, and this is the thinking behind the Keyczar project (http://www.keyczar.org/): "Cryptography is easy to get wrong. Developers can choose improper cipher modes, use obsolete algorithms, compose primitives in an unsafe manner, or fail to anticipate the need for key rotation. Keyczar abstracts some of these details by choosing safe defaults, automatically tagging outputs with key version information, and providing a simple programming interface. Keyczar is designed to be open, extensible, and cross-platform compatible. It is not intended to replace existing cryptographic libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is built on these libraries." Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Crypto Craft Knowledge
http://www.links.org/?p=535
[Never been 100% sure about the etiquette of sending my own blog posts
to this list, but in this case I am doing so at Perry's request. For
future reference if anyone else ever feels it's appropriate, do feel free]
>From time to time I bemoan the fact that much of good practice in
cryptography is craft knowledge that is not written down anywhere, so it
was with interest that I read a post by Michael Roe about hidden
assumptions in crypto[1]. Of particular interest is this
"When we specify abstract protocols, it's generally understood that the
concrete encoding that gets signed or MAC'd contains enough information
to unambigously identify the field boundaries: it contains length
fields, a closing XML tag, or whatever. A signed message {Payee, Amount}
K_A should not allow a payment of $3 to Bob12 to be mutated by the
attacker into a payment of $23 to Bob1. But ISO 9798 (and a bunch of
others) don't say that. There's nothing that says a conforming
implementation can't send the length field without authentication.
Now of course, an implementor probably wouldn't do that. But they _might_."
Actually, in my extensive experience of reviewing security-critical
code, this particular error is extremely common. Why does Michael assume
that they probably wouldn't? Because he is steeped in the craft
knowledge around crypto. But most developers aren't. Most developers
don't even have the right mindset for secure coding, let alone correct
cryptographic coding. So, why on Earth do we expect them to follow our
unwritten rules, many of which are far from obvious even if you
understand the crypto?
[1]
http://www.lightbluetouchpaper.org/2009/02/02/hidden-assumptions-in-cryptographic-protocols/
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: full-disk subversion standards released
Alexander Klimov wrote: > On Wed, 11 Feb 2009, Ben Laurie wrote: >> If I have data on my server that I would like to stay on my server >> and not get leaked to some third party, then this is exactly the >> same situation as DRMed content on an end user's machine, is it not? > > The treat model is completely different: for DRM the attacker is the > user who supposedly has complete access to computer, while for server > the attacker is someone who has only (limited) network connection to > your server. You wish. The threat is an attacker who has root on your machine. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: full-disk subversion standards released
Peter Gutmann wrote: > Ben Laurie writes: > >> Apart from the obvious fact that if the TPM is good for DRM then it is also >> good for protecting servers and the data on them, > > In which way, and for what sorts of "protection"? And I mean that as a > serious inquiry, not just a "Did you spill my pint?" question. If I have data on my server that I would like to stay on my server and not get leaked to some third party, then this is exactly the same situation as DRMed content on an end user's machine, is it not? > At the moment > the sole significant use of TPMs is Bitlocker, which uses it as little more > than a PIN-protected USB memory key and even then functions just as well > without it. To take a really simple usage case, how would you: > > - Generate a public/private key pair and use it to sign email (PGP, S/MIME, > take your pick)? > - As above, but send the public portion of the key to someone and use the > private portion to decrypt incoming email? > > (for extra points, prove that it's workable by implementing it using an actual > TPM to send and receive email with it, which given the hit-and-miss > functionality and implementation quality of TPMs is more or less a required > second step). I've implemented PGP email using a Fortezza card (which is > surely the very last thing it was ever intended for), but not using a TPM... Note that I am not claiming expertise in the use of TPMs. I am making the claim that _if_ they are good for DRM, _then_ they are also good for protecting data on servers. >> Mark Ryan presented a plausible use case that is not DRM: >> http://www.cs.bham.ac.uk/~mdr/research/projects/08-tpmFunc/. > > This use is like the joke about the dancing bear, the amazing thing isn't the > quality of the "dancing" but the fact that the bear can "dance" at all :-). > It's an impressive piece of lateral thinking, but I can't see people rushing > out to buy TPM-enabled PCs for this. I agree that it is more cute than practical. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: full-disk subversion standards released
Peter Gutmann wrote: John Gilmore writes: The theory that we should build "good and useful" tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. There's another problem with this theory and that's the practical implementation issue. I've read through... well, at least skimmed through the elephantine bulk of the TCG specs, and also read related papers and publications and talked to people who've worked with the technology, to see how I could use it as a crypto plugin for my software (which already supports some pretty diverse stuff, smart cards, HSMs, the VIA Padlock engine, ARM security cores, Fortezza cards (I even have my own USG-allocated Fortezza ID :-), and in general pretty much anything out there that does crypto in any way, shape, or form). However after detailed study of the TCG specs and discussions with users I found that the only thing you can really do with this, or at least the bits likely to be implemented and supported and not full of bugs and incompatibilities, is DRM. Apart from the obvious fact that if the TPM is good for DRM then it is also good for protecting servers and the data on them, Mark Ryan presented a plausible use case that is not DRM: http://www.cs.bham.ac.uk/~mdr/research/projects/08-tpmFunc/. I wrote it up briefly here: http://www.links.org/?p=530. As for John's original point, isn't the world full of such tools (guns, TV cameras, telephone networks, jet engines, blah blah)? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Proof of Work -> atmospheric carbon
On Mon, Jan 26, 2009 at 9:40 AM, John Gilmore wrote: >> > If POW tokens do become useful, and especially if they become money, >> > machines will no longer sit idle. Users will expect their computers to >> > be earning them money (assuming the reward is greater than the cost to >> > operate). > > Computers are already designed to consume much less electricity when > idle than when running full tilt. This trend will continue and > extend; some modern chips throttle down to zero MHz and virtually zero > watts at idle, waking automatically at the next interrupt. > > The last thing we need is to deploy a system designed to burn all > available cycles, consuming electricity and generating carbon dioxide, > all over the Internet, in order to produce small amounts of bitbux to > get emails or spams through. Richard Clayton and I claim that PoW doesn't work: http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: What EV certs are good for
On Wed, Jan 28, 2009 at 5:14 AM, William Soley wrote: > On Jan 27, 2009, at 6:04 AM, Jerry Leichter wrote: >> >> It might be useful to put together a special-purpose HTTPS client which >> would initiate a connection and tell you about the cert returned, then exit. > > I use ... > >openssl s_client -connect www.whatever.com:443 -showcerts > > Ships with Mac OS, Solaris, Linux, etc. And to use TOR, put "torify" on the front. Having run the tor server, of course. Except on MacOS, where torify doesn't (can't? Does anyone know better) work. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: What EV certs are good for
On Sun, Jan 25, 2009 at 11:04 PM, Jerry Leichter wrote: > I just received a phishing email, allegedly from HSBC: > >Dear HSBC Member, > >Due to the high number of fraud attempts and phishing scams, it has been > decided to >implement EV SSL Certification on this Internet Banking website. > >The use of EV SSL certification works with high security Web browsers to > clearly >identify whether the site belongs to the company or is another site > imitating that >company's site > > (I hope I haven't quoted enough to trigger someone's spam detectors!) > Needless to say, the message goes on to suggest clicking on a link to > update your account. So did the link have a EV cert? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Sat, Jan 24, 2009 at 2:36 AM, Victor Duchovni wrote: > You seem to be out of touch I am afraid. Just look at what many O/S > distributions do. They adopt a new OpenSSL 0.9.Xy release from time to > time (for some initial "y") and back-port security fixes never changing > the letter. One can't actually tell from "openssl version" what version > one is running and which fixes have been applied. > > Why am I back-porting patch-sets to 0.9.8i? Is that because there is no > demand for bugfix releases? There is indeed demand for real bugfix > releases, just that people have gotten used to doing it themselves, > but this is not very effective and is difficult to audit. It is not that I am unaware of this, I was pointing out what we actually do. But you do have a fair point and I will take it up with the team. However, I wonder how this is going to pan out? Since historically pretty much every release has been prompted by a security issue, but also includes new features and non-security bugfixes, in order to release 0.9.8j the way you want us to, we would also have to test and release security updates for 0.9.8 - 0.9.8i, for a total of 10 branched versions. I think this is asking rather a lot of volunteers! Don't suggest that we should release feature/bugfix versions less often, I think we already do that less often than we should. Perhaps the answer is that we security patch every version that is less than n months old, and end-of-life anything before that? Suggestions for reasonable values of n? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: MD5 considered harmful today, SHA-1 considered harmful tomorrow
On Tue, Jan 20, 2009 at 5:14 AM, Victor Duchovni wrote: > On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote: > >> The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 >> mandatory), so you can send a SHA-256 certificate to clients that >> indicate they support TLS 1.2 or later. You'd still need some other >> certificate for interoperability with clients that don't support >> SHA-256, of course, and you'd be sending that one to clients that do >> support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which >> is not really a problem when CAs make sure to use the hash algorithm >> in a way that doesn't rely on hash collisions being hard to find, >> which probably is a good idea for *any* hash algorithm.) > > It would be helpful if as a first step, SSL_library_init() (a.k.a. > OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests, > I would make this change in the 0.9.9 development snapshots. > > [ Off topic: I find OpenSSL release-engineering a rather puzzling > process. The "patch" releases are in fact feature releases, Who said they were "patch" releases? > and there > are no real patch releases even for critical security issues. I chose > to backport the 0.9.8j security fixes to 0.9.8i and sit out all the > new FIPS code, ... This should not be necessary. I really hope to see > real OpenSSL patch releases some day with development of new features > *strictly* in the development snapshots. Ideally this will start with > 0.9.9a, with no new features, just bugfixes, in [b-z]. ] I think that is not likely to happen, because that's not the way it works. The promise we try to keep is ABI compatibility between releases that have the same numbers. Letters signify new versions within that series. We do not have a bugfix-only branch. There doesn't seem to be much demand for one. > > -- >Viktor. > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
OpenPGP:SDK v0.9 released
I thought people might be interested in this now somewhat-complete, BSD-licensed OpenPGP library... http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9 -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Tue, Dec 30, 2008 at 4:25 AM, Peter Gutmann wrote: > Ben Laurie writes: > >>what happens when the cert rolls? If the key also changes (which would seem >>to me to be good practice), then the site looks suspect for a while. > > I'm not aware of any absolute figures for this but there's a lot of anecdotal > evidence that many cert renewals just re-certify the same key year in, year > out (there was even a lawsuit over the definition of the term "renewal" in > certificates a few years ago). So you could in theory handle this by making a > statement about the key rather than the whole cert it's in. OTOH this then > requires the crawler to dig down into the data structure (SSH, X.509, > whatever) to pick out the bits corresponding to the key. Not really a serious difficulty. > Other alternatives > are to use a key-rollover mechanism that signs the new key with old one > (something that I've proposed for SSH, since their key-continuity model kinda > breaks at that point), and all the other crypto rube-goldbergisms you can > dream up. Yeah, that's pretty much the answer I came up with - another option would be to use both the old and new certs for a while. But signing the new with the old seems easiest to implement - the signature can go in an X509v3 extension, which means CAs can sign it without understanding it, and only Google has to be able to verify it, so all that needs to change is CSR generating s/w... - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Mon, Dec 29, 2008 at 10:10 AM, Peter Gutmann wrote: > David Molnar writes: > >>Service from a group at CMU that uses semi-trusted "notary" servers to >>periodically probe a web site to see which public key it uses. The notaries >>provide the list of keys used to you, so you can attempt to detect things >>like a site that has a different key for you than previously shown to all of >>the notaries. The idea is that to fool the system, the adversary has to >>compromise all links between the target site and the notaries all the time. > > I think this is missing the real contribution of Perspectives, which (like > almost any security paper) has to include a certain quota of crypto rube- > golbergism in order to satisfy conference reviewers. The real value isn't the > multi-path verification and crypto signing facilities and whatnot but simply > the fact that you now have something to deal with leap-of-faith > authentication, whether it's for self-generated SSH or SSL keys or for rent-a- > CA certificates. Currently none of these provide any real assurance since a > phisher can create one on the fly as and when required. What Perspectives > does is guarantee (or at least provide some level of confidence) that a given > key has been in use for a set amount of time rather than being a here-this- > morning, gone-in-the-afternoon affair like most phishing sites are. In other > words a phisher would have to maintain their site for a week, a month, a year, > of continuous operation, not just set it up an hour after the phishing email > goes out and take it down again a few hours later. > > For this function just a single source is sufficient, thus my suggestion of > Google incorporating it into their existing web crawling. You can add the > crypto rube goldberg extras as required, but a basic "this site has been in > operation at the same location with the same key for the past eight months" is > a powerful bar to standard phishing approaches, it's exactly what you get in > the bricks-and-mortar world, "Serving the industry since 1962" goes a lot > further than "Serving the industry since just before lunchtime". Two issues occur to me. Firstly, you have to trust Google (and your path to Google). Secondly, and this seems to me to be a generic issue with Perspectives and SSL - what happens when the cert rolls? If the key also changes (which would seem to me to be good practice), then the site looks suspect for a while. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Fri, Dec 26, 2008 at 7:39 AM, Peter Gutmann wrote: Adding support for a > service like Perspectives (discussed here a month or two back) would be a good > start since it provides some of the assurance that a commercial PKI can't (and > as an additional benefit it also works for SSH servers, since it's not built > around certificates). > > So, when will Google add Perspectives support to their search database? :-). I can't find discussion of Perspectives - hint? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: This is a test. This is only a test...
[EMAIL PROTECTED] (Peter Gutmann) writes: >From the DailyWTF: > > In my previous alert, I included the text of a phishing email as an example > [of phishing emails that people shouldn't reply to]. Some students > misunderstood that I was asking for user name and password, and replied with > that information. Please be aware that you shouldn.t provide this > information to anyone. > > Rest at http://thedailywtf.com/Articles/SlowMotion-Automation.aspx. I believe that the correct URL is: http://thedailywtf.com/Articles/Go-Phish.aspx -- Ben Pfaff http://benpfaff.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: combining entropy
On Tue, Oct 28, 2008 at 7:55 PM, Leichter, Jerry <[EMAIL PROTECTED]> wrote: >2. The Byzantine model. Failed modules can do anything >including cooperating by exchanging arbitrary >information and doing infinite computation. So in the Byzantine model I can crack RSA? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Peter Gutmann wrote: > In fact none of the people/organisations I queried about this fitted into any > of the proposed categories, it was all embedded devices, typically SCADA > systems, home automation, consumer electronics, that sort of thing, so it was > really a single category which was "Embedded systems". Given the string of > attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some > not-yet-published ones on HDCP devices :-), etc) this is by far the most > at-risk category because there's a huge incentive to attack them, the result > affects tens/hundreds of millions of devices, and the attacks are immediately > and widely actively exploited (modchips/device unlocking/etc, an important > difference between this and academic proof-of-concept attacks), so this is > the > one where I'd expect the vendors to care most. But they've all been unlocked using easier attacks, surely? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: combining entropy
On Sat, Oct 25, 2008 at 12:40 PM, IanG <[EMAIL PROTECTED]> wrote: > Jonathan Katz wrote: >> I think it depends on what you mean by "N pools of entropy". > > > I can see that my description was a bit weak, yes. Here's a better > view, incorporating the feedback: > > If I have N people, each with a single pool of entropy, > and I pool each of their contributions together with XOR, > is that as good as it gets? I think you need to define what you mean by "as good as it gets". Clearly XOR loses entropy that might be there, so on the measure of "good == most entropy", it is not. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: combining entropy
On Mon, Sep 29, 2008 at 1:13 PM, IanG <[EMAIL PROTECTED]> wrote: > If I have N pools of entropy (all same size X) and I pool them > together with XOR, is that as good as it gets? Surely not. Consider N pools each of size 1 bit. Clearly you can do better than the 1 bit your suggestion would yield. More concretely, concatenation would seem better than XOR. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: >> If this had been done in the beginning, before users -- and web site >> designers, and browser vendors -- were mistrained, it might have worked. >> Now, though? I'm skeptical. > > For existing apps with habituated users, so am I. So how about the following > strawman: Take an existing browser (say Firefox), brand it as some special- > case secure online banking browser, and use the "new developments" solution > above, i.e. it only talks mutual-auth challenge-response crypto and nothing > else. At that point you've reduced "Reformat user and reinstall browsing > habits" to "Train users to only use safe-browser when they do their banking, > i.e. 'Never enter banking details using anything other than safe-browser'". > Even if you only get a subset of users doing this, it's still a massive attack > surface reduction because you've raised the bar from any idiot who buys a > phishing kit to having to perform a man-in-the-browser attack. We've been debating this a lot at Google lately. One argument that I have increasing sympathy with is that SSO (or if you want to be modern, federated login) provides an opportunity to change the playing field sufficiently that we can reprogram users to be less vulnerable to phishing - or just switch them to protocols that make phishing irrelevant. To that end, we've released some usability research... http://google-code-updates.blogspot.com/2008/09/usability-research-on-federated-login.html Obviously the end game here is that the user only has to protect his login to a small number of sites - i.e. those that provide the IdP. Once we get there, perhaps users can be persuaded to authenticate to those sites using something stronger than username/password. A sidenote that provides me with some amusement: although the modern trend is towards using OpenID, no-one wants to use it in the mode it is designed for, i.e. where the user can pick any old IdP and the RP will just trust it. In practice where we seem to be headed is that RPs will trust some smallish number of trusted IdPs. This is, of course, exactly what the Liberty guys have been working on all along. I predict that over time, most of the elements of Liberty will be incorporated into OpenID. Which makes me think that if Liberty had done what it claimed to be doing when it started, i.e. be a community-based, open-source-friendly protocol suite, it would have worked much better. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quiet in the list...
IanG wrote: > 2. GPG + Engimail + Thunderbird. Will never be totally robust because > there is too much dependency. What does this mean? GPG + Enigmail, whilst not the best architecture I ever heard of, is a tiny increment to the complexity of Thunderbird. Are you saying anything other than "big software has bugs"? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Quiet in the list...
Allen wrote: > So I'll ask a question. I saw the following on another list: > >>> > I stopped using WinPT after is crashed too many times. >>> > I am now using Thunderbird with the Enigmail plugin >>> > for GPG interface. It works rather flawlessly and I've >>> > never looked back. >>> > > http://pgp.mit.edu:11371/pks/lookup?search=0xBB678C30&op=index >> >> >> Yes, I regard the combination of Thunderbird + Enigmail + GPG as the >> best existing solution for secure email. > > What does anyone think of of the combo? I agree. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [OpenID] rfc2817: https vs http
On Tue, Sep 2, 2008 at 1:32 AM, Eric Rescorla <[EMAIL PROTECTED]> wrote: > At Mon, 1 Sep 2008 21:56:52 +0100, > Ben Laurie wrote: >> > Session caches are often dialed this low, but it's not really necessary >> > in most applications. First, a session cache entry isn't really that >> > big. It easily fits into 100 bytes on the server, so you can serve >> > a million concurrent user for a measly 100M. >> >> But if the clients drop them after five minutes, this gets you >> nowhere. > > Agreed. I thought we were contemplating protocol changes in > any case, so I figured having clients just use a longer session > cache (5 minutes is silly for a client anyway, since the amount > of memory consumed on the client is miniscule) wasn't much > of an obstacle. Fair point. >> BTW, sessions are only that small if there are no client >> certs. > > True enough, though that's the common case right now. > > >> > Second, you can use >> > CSSC/Tickets [RFC5077] to offload all the information onto the client. >> >> Likewise. > > Except that CSSC actually looks better when client certs are used, since > you can offload the entire cert storage to the client, so you get > more memory savings. I meant "five minutes". - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [OpenID] rfc2817: https vs http
On Mon, Sep 1, 2008 at 9:49 PM, Eric Rescorla <[EMAIL PROTECTED]> wrote: > At Mon, 1 Sep 2008 21:00:55 +0100, > Ben Laurie wrote: >> The core issue is that HTTPS is used to establish end-to-end security, >> meaning, in particular, authentication and secrecy. If the MitM can >> disable the upgrade to HTTPS then he defeats this aim. The fact that >> the server declines to serve an HTTP page is irrelevant: it is the >> phisher that will be serving the HTTP page, and he will have no such >> compunction. >> >> The traditional fix is to have the client require HTTPS, which the >> MitM is powerless to interfere with. Upgrades would work fine if the >> HTTPS protocol said "connect on port 80, ask for an upgrade, and if >> you don't get it, fail", however as it is upgrades work at the behest >> of the server. And therefore don't work. > > Even without an active attacker, this is a problem if there is > sensitive information in the request, since that will generally > be transmitted prior to discovering the server can upgrade. Obviously we can fix this at the protocol level. >> Why don't we? Cost. It takes far more tin to serve HTTPS than HTTP. >> Even really serious modern processors can only handle a few thousand >> new SSL sessions per second. New plaintext sessions can be dealt with >> in their tens of thousands. >> >> Perhaps we should focus on this problem: we need cheap end-to-end >> encryption. HTTPS solves this problem partially through session >> caching, but it can't easily be shared across protocols, and sessions >> typically last on the order of five minutes, an insanely conservative >> figure. > > Session caches are often dialed this low, but it's not really necessary > in most applications. First, a session cache entry isn't really that > big. It easily fits into 100 bytes on the server, so you can serve > a million concurrent user for a measly 100M. But if the clients drop them after five minutes, this gets you nowhere. BTW, sessions are only that small if there are no client certs. > Second, you can use > CSSC/Tickets [RFC5077] to offload all the information onto the client. Likewise. > > -Ekr > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [OpenID] rfc2817: https vs http
[Adding the cryptography list, since this seems of interest] On Wed, Aug 27, 2008 at 8:58 PM, Story Henry <[EMAIL PROTECTED]> wrote: > Apparently rfc2817 allows an http url tp be used for https security. > > Given that Apache seems to have that implemented [1] and that the > openid url is mostly used for server to server communication, would > this be a way out of the http/https problem? > > I know that none of the browsers support it, but I suppose that if the > client does not support this protocol, the server can redirect to the > https url? This seems like it could be easier to implement that XRI . > > Disclaimer: I don't know much about rfc2817 This inspired a blog post: http://www.links.org/?p=382. Recent events, and a post to the OpenID list got me thinking. Apparently rfc2817 allows an http url tp be used for https security. Given that Apache seems to have that implemented [1] and that the openid url is mostly used for server to server communication, would this be a way out of the http/https problem? I know that none of the browsers support it, but I suppose that if the client does not support this protocol, the server can redirect to the https url? This seems like it could be easier to implement that XRI . Disclaimer: I don't know much about rfc2817 Henry [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00251.html The core issue is that HTTPS is used to establish end-to-end security, meaning, in particular, authentication and secrecy. If the MitM can disable the upgrade to HTTPS then he defeats this aim. The fact that the server declines to serve an HTTP page is irrelevant: it is the phisher that will be serving the HTTP page, and he will have no such compunction. The traditional fix is to have the client require HTTPS, which the MitM is powerless to interfere with. Upgrades would work fine if the HTTPS protocol said "connect on port 80, ask for an upgrade, and if you don't get it, fail", however as it is upgrades work at the behest of the server. And therefore don't work. Of course, the client "requires" HTTPS because there was a link that had a scheme of "https". But why did was that link followed? Because there was an earlier page with a trusted link (we hope) that was followed. (Note that this argument applies to both users clicking links and OpenID servers following metadata). If that page was served over HTTP, then we are screwed, obviously (bearing in mind DNS cache attacks and weak PRNGs). This leads to the inescapable conclusion that we should serve everything over HTTPS (or other secure channels). Why don't we? Cost. It takes far more tin to serve HTTPS than HTTP. Even really serious modern processors can only handle a few thousand new SSL sessions per second. New plaintext sessions can be dealt with in their tens of thousands. Perhaps we should focus on this problem: we need cheap end-to-end encryption. HTTPS solves this problem partially through session caching, but it can't easily be shared across protocols, and sessions typically last on the order of five minutes, an insanely conservative figure. What we need is something like HTTPS, shareable across protocols, with caches that last at least hours, maybe days. And, for sites we have a particular affinity with, an SSH-like pairing protocol (with less public key crypto - i.e. more session sharing). Having rehearsed this discussion many times, I know the next objection will be DoS on the servers: a bad guy can require the server to spend its life doing PK operations by pretending he has never connected before. Fine, relegate PK operations to the slow queue. Regular users will not be inconvenienced: they already have a session key. Legitimate new users will have to wait a little longer for initial load. Oh well. > > Henry > > > [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00251.html > > > http://www.ietf.org/rfc/rfc2817.txt > Home page: http://bblfish.net/ > > ___ > general mailing list > [EMAIL PROTECTED] > http://openid.net/mailman/listinfo/general > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Keyczar
http://www.links.org/?p=374 When I joined Google over two years ago I was asked to find a small project to get used to the way development is done there. The project I chose was one that some colleagues had been thinking about, a key management library. I soon realised that unless the library also handled the crypto it was punting on the hard problem, so I extended it to do crypto and to handle key rotation and algorithm changes transparently to the user of the library. About nine months later I handed over my "starter project" to Steve Weis, who has worked on it ever since. For a long time we've talked about releasing an open source version, and I'm pleased to say that Steve and intern Arkajit Dey did just that, earlier this week: Keyczar[1]. "Keyczar is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys. Some features of Keyczar include: * A simple API * Key rotation and versioning * Safe default algorithms, modes, and key lengths * Automated generation of initialization vectors and ciphertext signatures" When we say simple, by the way, the code for loading a keyset and encrypting some plaintext is just two lines. Likewise for decryption. And the user doesn't need to know anything about algorithms or modes. Great work, guys! I look forward to the "real" version (C++, of course!). [1] http://www.keyczar.org/ Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
On Tue, Aug 12, 2008 at 9:55 AM, Clausen, Martin (DK - Copenhagen) <[EMAIL PROTECTED]> wrote: > You could use the SSL Blacklist plugin > (http://codefromthe70s.org/sslblacklist.asp) for Firefox or heise SSL > Guardian > (http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/11 > 1039/) for IE to do this. If presented with a Debian key the show a > warning. > > The blacklists are implemented using either a traditional blacklist > (text file) or distributed using DNS. There are two parties that are vulnerable: the user logging into the OpenID Provider (OP), and the Relying Party (RP). If the RP communicates with the OP, then it needs to use TLS and CRLs or OCSP. Browser plugins do not bail it out. Cheers, Ben. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
Hal Finney wrote: I thought of one possible mitigation that can protect OpenID end users against remote web sites which have not patched their DNS. OpenID providers who used weak OpenSSL certs would have to change their URLs so that their old X.509 CA certs on their old URLs no longer work on the new ones. This will require all of their clients (users who log in with their OpenID credentials) to change their identifiers. DNS based MITMs will not be able to forge messages related to the new identifiers. Yeah, I considered this scheme. The problem is that it doesn't really help the relying parties, who can still be fooled into believing an existing user is returning (or a new one is arriving) from the original site. This is particularly a problem for Sun's OpenID Provider, which makes the additional assertion (out of band) that the user is a Sun employee. So, anyone can become a Sun employee, as of a few days ago. This is why the lack of CRL checking in OpenID libraries is an issue. Again, I see fixing the DNS as the path of least resistance here, especially so since the end user is the one bearing most of the risk, typically DNS is provided by an ISP or some other agency with a formal legal relationship, and there is the possibility of liability on the part of the lax DNS provider. Hopefully we will continue to see rapid uptake of the DNS fix over the next few weeks. In general, DNS is not fixable without deploying DNSSEC. a) The current "fix" just reduces the probability of an attack. If attacker and victim have sufficient bandwidth, it can still be done in under a day. b) There are many scenarios, mostly revolving around the use of wireless hotspots, where users are easily fooled into using a malicious DNS provider. So, DNS patching is not, IMO, the real answer to this problem. Of course, the second scenario has been around forever, but is conveniently ignored when explaining why CRLs are not necessary (and all other things that rely on perfect DNS). All that's happened recently is we've made people who are sitting still just as vulnerable as travellers. But increasingly we are all travellers some of the time, from a "how we get our 'net" POV. We really can't ignore this use case. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
On Fri, Aug 8, 2008 at 7:54 PM, Tim Dierks <[EMAIL PROTECTED]> wrote: > Using this Bloom filter calculator: > http://www.cc.gatech.edu/~manolios/bloom-filters/calculator.html , plus the > fact that there are 32,768 weak keys for every key type & size, I get > various sizes of necessary Bloom filter, based on how many key type / sizes > you want to check and various false positive rates: > * 3 key types/sizes with 1e-6 false positive rate: 2826759 bits = 353 KB > * 3 key types/sizes with 1e-9 false positive rate: 4240139 bits = 530 KB > * 7 key types/sizes with 1e-6 false positive rate: 6595771 bits = 824 KB > * 7 key types/sizes with 1e-9 false positive rate: 9893657 bits = 1237 KB > > I presume that the first 3 & first 7 key type/sizes in this list > http://metasploit.com/users/hdm/tools/debian-openssl/ are the best to > incorporate into the filter. > > Is there any chance it would be feasible to get a list of all the weak keys > that were actually certified by browser-installed CAs, or those weak > certificates? Presumably, this list would be much smaller and would be more > effectively distributed in Bloom filter form. Or as a CRL :-) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [OpenID] OpenID/Debian PRNG/DNS Cache poisoning advisory
On Fri, Aug 8, 2008 at 8:27 PM, Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]> wrote: > Ben Laurie: > > On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.) > <[EMAIL PROTECTED]> wrote: > > > This affects any web site and service provider of various natures. It's not > exclusive for OpenID nor for any other protocol / standard / service! It may > affect an OpenID provider if it uses a compromised key in combination with > unpatched DNS servers. I don't understand why OpenID is singled out, since > it can potentially affect any web site including Google's various services > (if Google would have used Debian systems to create their private keys). > > > OpenID is "singled out" because I am not talking about a potential > problem but an actual problem. > > > Sorry Ben, but any web site or service (HTTP, SMPT, IMAP, SSH, VPN, etc) > which makes use of a compromised key has an actual problem and not a > potential problem. Open ID as a standard isn't more affected than, lets say > XMPP...If there are servers and providers relying on such keys the have a > real actual problem. I do not dispute this. > I don't see your point about Open ID nor didn't I see > anything new The point is I found OpenID servers with weak keys. > The problem of weak keys should be dealt at the CA level, many which have > failed to do anything serious about it. Indeed. > We have spotted other actual problems in other services. Details will > be forthcoming at appropriate times. > > > I think it's superfluous to single out different services since any service > making use of the weak keys is affected, with recent discovery of DNS > poisoning making the matter worse. I suggest you try a forum which can > potentially reach many CAs, they in fact have everything at their disposal > to remove this threat! If you have a better forum, bring it on. However, CAs do not have everything at their disposal to remove the threat. Browsers,OpenID libraries and RPs must also participate. Just as saying "buffer overflows are bad" has not magically caused all buffer overflows to be fixed, I am confident that the only way to get this problem fixed is to chase down all the culprits individually. I am sure that OpenID is not the only thing with problems, as you say. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
On Fri, Aug 8, 2008 at 5:57 PM, Eric Rescorla <[EMAIL PROTECTED]> wrote: > At Fri, 8 Aug 2008 17:31:15 +0100, > Dave Korn wrote: >> >> Eric Rescorla wrote on 08 August 2008 16:06: >> >> > At Fri, 8 Aug 2008 11:50:59 +0100, >> > Ben Laurie wrote: >> >> However, since the CRLs will almost certainly not be checked, this >> >> means the site will still be vulnerable to attack for the lifetime of >> >> the certificate (and perhaps beyond, depending on user >> >> behaviour). Note that shutting down the site DOES NOT prevent the attack. >> >> >> >> Therefore mitigation falls to other parties. >> >> >> >> 1. Browsers must check CRLs by default. >> > >> > Isn't this a good argument for blacklisting the keys on the client >> > side? >> >> Isn't that exactly what "Browsers must check CRLs" means in this context >> anyway? What alternative client-side blacklisting mechanism do you suggest? > > It's easy to compute all the public keys that will be generated > by the broken PRNG. The clients could embed that list and refuse > to accept any certificate containing one of them. So, this > is distinct from CRLs in that it doesn't require knowing > which servers have which cert... It also only fixes this single type of key compromise. Surely it is time to stop ignoring CRLs before something more serious goes wrong? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [OpenID] OpenID/Debian PRNG/DNS Cache poisoning advisory
On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]> wrote: > This affects any web site and service provider of various natures. It's not > exclusive for OpenID nor for any other protocol / standard / service! It may > affect an OpenID provider if it uses a compromised key in combination with > unpatched DNS servers. I don't understand why OpenID is singled out, since > it can potentially affect any web site including Google's various services > (if Google would have used Debian systems to create their private keys). OpenID is "singled out" because I am not talking about a potential problem but an actual problem. We have spotted other actual problems in other services. Details will be forthcoming at appropriate times. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
OpenID/Debian PRNG/DNS Cache poisoning advisory
Security Advisory (08-AUG-2008) (CVE-2008-3280) === Ben Laurie of Google's Applied Security team, while working with an external researcher, Dr. Richard Clayton of the Computer Laboratory, Cambridge University, found that various OpenID Providers (OPs) had TLS Server Certificates that used weak keys, as a result of the Debian Predictable Random Number Generator (CVE-2008-0166). In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and the fact that almost all SSL/TLS implementations do not consult CRLs (currently an untracked issue), this means that it is impossible to rely on these OPs. Attack Description -- In order to mount an attack against a vulnerable OP, the attacker first finds the private key corresponding to the weak TLS certificate. He then sets up a website masquerading as the original OP, both for the OpenID protocol and also for HTTP/HTTPS. Then he poisons the DNS cache of the victim to make it appear that his server is the true OpenID Provider. There are two cases, one is where the victim is a user trying to identify themselves, in which case, even if they use HTTPS to "ensure" that the site they are visiting is indeed their provider, they will be unable to detect the substitution and will give their login credentials to the attacker. The second case is where the victim is the Relying Party (RP). In this case, even if the RP uses TLS to connect to the OP, as is recommended for higher assurance, he will not be defended, as the vast majority of OpenID implementations do not check CRLs, and will, therefore, accept the malicious site as the true OP. Mitigation -- Mitigation is surprisingly hard. In theory the vulnerable site should revoke their weak certificate and issue a new one. However, since the CRLs will almost certainly not be checked, this means the site will still be vulnerable to attack for the lifetime of the certificate (and perhaps beyond, depending on user behaviour). Note that shutting down the site DOES NOT prevent the attack. Therefore mitigation falls to other parties. 1. Browsers must check CRLs by default. 2. OpenID libraries must check CRLs. 3. DNS caching resolvers must be patched against the poisoning attack. 4. Until either 1 and 2 or 3 have been done, OpenID cannot be trusted for any OP that cannot demonstrate it has never had a weak certificate. Discussion -- Normally, when security problems are encountered with a single piece of software, the responsible thing to do is to is to wait until fixes are available before making any announcement. However, as a number of examples in the past have demonstrated, this approach does not work particularly well when many different pieces of software are involved because it is necessary to coordinate a simultaneous release of the fixes, whilst hoping that the very large number of people involved will cooperate in keeping the vulnerability secret. In the present situation, the fixes will involve considerable development work in adding CRL handling to a great many pieces of openID code. This is a far from trivial amount of work. The fixes will also involve changes to browser preferences to ensure that CRLs are checked by default -- which many vendors have resisted for years. We are extremely pessimistic that a security vulnerability in OpenID will be seen as sufficiently important to change the browser vendors minds. Hence, we see no value in delaying this announcement; and by making the details public as soon as possible, we believe that individuals who rely on OpenID will be better able to take their own individual steps to avoid relying upon the flawed certificates we have identified. OpenID is at heart quite a weak protocol, when used in its most general form[1], and consequently there is very limited reliance upon its security. This means that the consequences of the combination of attacks that are now possible is nothing like as serious as might otherwise have been the case. However, it does give an insight into the type of security disaster that may occur in the future if we do not start to take CRLs seriously, but merely stick them onto "to-do" lists or disable them in the name of tiny performance improvements. Affected Sites -- There is no central registry of OpenID systems, and so we cannot be sure that we have identified all of the weak certificates that are currently being served. The list of those we have found so far is: openid.sun.com www.xopenid.net openid.net.nz Notes - [1] There are ways of using OpenID that are significantly more secure than the commonly deployed scheme, I shall describe those in a separate article. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Strength in Complexity?
So, an executive summary of your responses appears to be "EKMI leaves all the hard/impossible problems to be solved by components that are out of scope". As such, I'm not seeing much value. Anyway... Arshad Noor wrote: Ben Laurie wrote: OK, so you still have a PKI problem, in that you have to issue and manage client certificates. How is this done? One man's meat :-). (I don't necessarily view this as a problem Ben. I've built up a career and a small business in the last 9 years doing just that.) Nevertheless, to answer the question, the PKI deployment is not part of the SKSML prtocol (other than the WSS header that carries the XML Signature and/or XML Encryption of the SOAP Body), but it is part of an EKMI. (EKMI = PKI + SKMS). A company deploying an EKMI must have, or must build a PKI and deploy the client/server certificates separately from the SKMS. While this might be viewed as a problem for some/many companies in the short-term, I fully anticipate that vendor implementations of SKMS will integrate with PKI software to manage this process seamlessly in the future. PKI out of scope... I do not believe this is the case. DRM fails because the attacker has physical possession of the system he is attacking. Which is why we are recommending that SKMS clients use hardware based modules (be it TPMs, smartcards, HSMs, etc.) to generate and store the Private Key used by SKMS client to decrypt the symmetric keys. While even these can be attacked, the problem is now in a different domain than the SKSML protocol. ...impossibility of solving DRM problem out of scope... EKMI's goals are not to provide bullet-proof security. It has more modest ambitions - to provide a management framework for incremental security, targeted at the right resource: the data, rather than the network. Are there any even vaguely modern systems that target the network for security, or is this a straw man? What I meant to say is that EKMI's goal is to protect the data and not the network. ...goals the same as pretty much all cryptographic protocols... If it is up to them, then why bother with this verification process? This sounds like yet more security theatre to me. I'm not sure which verification process you're referring to. No, this is not security theater. EKMI does not guarantee anything, nor does it promise unbreakable anything. Everything in EKMI is a choice. You get to choose the strength of your keys, your PKI, your policies, your procedures and your implementation. All we're offering is a tool that does something specific to the extent that the specifications and the technology allows. Nothing more, nothing less. If you - as a cryptographer - say that AES-156 will do X under these conditions, then EKMI will support X under those conditions. EKMI only adds the ability to manage a large number of keys centrally, and to ease many of the administrative burdens we see that large-scale key-management can cause. Everything it does is constrained by the limitations of the underlying technology components, polices and practices. But you still have to make the choice. ...security out of scope and scope out of scope. Is there anything other than key escrow that's actually in scope? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: On the unpredictability of DNS
William Allen Simpson wrote: I've changed the subject. Some of my own rants are about mathematical cryptographers that are looking for the "perfect" solution, instead of practical security solution. Always think about the threat first! In this threat environment, the attacker is unlikely to have perfect knowledge of the sequence. Shared resolvers are the most critical vulnerability, but the attacker isn't necessarily in the packet path, and cannot discern more than a few scattered numbers in the sequence. The more sharing (and greater impact), the more sparse the information. In any case, the only "perfect" solution is DNS-security. Over many years, I've given *many* lectures to local university, network, and commercial institutions about the need to upgrade and secure our zones. But the standards kept changing, and the roots and TLDs were not secured. Now, the lack of collective attention to known security problems has bitten us collectively. Never-the-less, with rephrasing, Ben has some good points I don't see any actual rephrasing below, unless you are suggesting I should have said "unpredictable" instead of "random". I think that's a perfectly fine substitution to make. Ben Laurie wrote: But just how GREAT is that, really? Well, we don't know. Why? Because there isn't actually a way test for randomness. ... While randomness is sufficient for "perfect" unpredictability, it isn't necessary in this threat environment. I agree, but my point is unaltered if you switch "randomness" to "unpredictability". Keep in mind that the likely unpredictability is about 2**24. In many or most cases, that will be implementation limited to 2**18 or less. Why? Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. In this threat environment, a better test would be for determination of a possible seed for any of several common PRNG. Or lack of PRNG. I don't see why. A perfectly reasonable threat is that the attacker reverse engineers the PRNG (or just checks out the source). It doesn't need to be common to be predictable. Oh, and I should say that number of ports and standard deviation are not a GREAT way to test for "randomness". For example, the sequence 1000, 2000, ..., 27000 has 27 ports and a standard deviation of over 7500, which looks pretty GREAT to me. But not very "random". Again, the question is not randomness, but unpredictability. Again, changing the words does not alter my point in any way, though I do agree that unpredictable is a better word. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
