RE: question re practical use of secret sharing
Peter Gutmann writes: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? It's available as part of other products (e.g. nCipher do it for keying their HSMs) Do you mean the k of n operator cards? For those, I don't think nCipher is using real secret sharing. I would guess that the HSM knows the secret(s), and counts the operator cards that are submitted. There is a financial standard for distributing ZCMK's (Zone Control Master Keys) that splits the ZCMK up into three pieces the same length as the original. This is 3 of 3. nCipher and other HSM vendors support this, and it's used wtih a little hand-held PIN pad. I guess this would count as an example of products that use secret sharing. Perhaps this is what you were referring to. gh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann Sent: Thursday, June 21, 2007 6:57 AM To: [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: question re practical use of secret sharing Charles Jackson [EMAIL PROTECTED] writes: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? It's available as part of other products (e.g. nCipher do it for keying their HSMs), but I don't know of any product that just does... secret sharing. What would be the user interface for such an application? What would be the target audience? (I mean a real target audience, not some hypothesised scenario). (This is actually a serious question. I talked with some crypto guys a few years ago about doing a standard for secret sharing, but to do that we had to come up with some general usage model for it rather than just one particular application-specific solution, and couldn't). Besides that, user demand for it was practically nonexistent... no, it was completely nonexistent, apart from a few highly specialised custom uses we couldn't even find someone to use as a guinea pig for testing, and the existing specialised users already had specialised solutions of their own for handling it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: More info in my AES128-CBC question
Leichter, Jerry wrote: Suppose we use AES128-CBC with a fixed IV. It's clear that the only vulnerability of concern occurs when a key is reused. OK, where do No, remember that if the IV is in the clear, an attacker can make some controlled bit changes in the first plaintext block. (There has been no assumption of integrity enforcement.) I wonder how Adam Perez is communicating the IV. gh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry Sent: Monday, April 23, 2007 11:41 AM To: cryptography@metzdowd.com Subject: Re: More info in my AES128-CBC question Some of the messages in this stream have demonstrated why it can be difficult to get non-crypto people to listen to advice from crypto experts: Cryptography research is, by its nature, a pretty absolute thing. We find attacks, we try to eliminate them. There's a strong tendency to view *any* attack as significant, so *any* use of a technique known to be weak is frowned on. However, the issue isn't cryptography, it's security; and security is a cost/benefit tradeoff. Some of the other messages in this thread have already made that point, by looking at some of the specific tradeoffs that have to be made (usability, efficiency, time to market, etc.) However, in this particular case, one can even analyze the threat quite directly. Suppose we use AES128-CBC with a fixed IV. It's clear that the only vulnerability of concern occurs when a key is reused. OK, where do the keys come from? We're told that they are session keys. Assuming that these are generated *correctly* - they are effectively random independent variables - then you'd need to see 2^64 sessions to get a 50% chance of a repeated key. Note: Note 2^64 *blocks* - something you might actually get in a reasonable amount of time on the fastest links - but 2^64 *sessions*. Is that within the realm of interest for this protocol? Maybe, maybe not. (Most likely not.) A decent protocol will have authentication and some kind of anti-replay mechanism. Even if someone gets hold of two sessions that used the same key, the authentication mechanism will block attempts to merge data from the two sessions. Alternatively, any anti-replay mechanism will require carrying a nonce of some sort in the stream. Realistically, this will be sent very early in the session, pretty much ensuring that even with common keys and a common IV, there will be little common data. In fact, a practical recommendation might be to put the nonce in the first block, in which case it ends up playing the role of an IV and the whole discussion disappears. In summary: Yes, ideally one uses a random IV. In practice, what this adds - in many common protocol styles - is robustness of a sort, not real additional security. (However, actual robustness of cryptosystems - robustness against all the common kinds of errors that people make in design, implementation, fielding, and use - doesn't appear to be within reach of current techniques.) If possible, it's certainly better to use the best practices known - and random or nonce IV's are among those - but getting defensive about how no one is listening to the crypto experts is not appropriate here. Save that for the really egregious mistakes - of which there are plenty. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: OT: SSL certificate chain problems
Victor Duchovni wrote: On Sun, Jan 28, 2007 at 12:47:18PM -0500, Thor Lancelot Simon wrote: That doesn't make sense to me -- the end-of-chain (server or client) certificate won't be signed by _both_ the old and new root, I wouldn't think (does x.509 even make this possible)? Or do I misunderstand? The key extra information is that old and new roots share the same issuer and subject DNs and public key, only the start/expiration dates differ, so in the overlap when both are valid, they are interchangeable, both verify the same (singly-signed) certs. To expand on what Duchovni said, you might want to look into the concept of cross-certificates (which are heavily used with bridges). The surprising thing, at first, is that you can issue any certificate after it was originally issued. I can issue the leaf cert you got from Verisign last year. Tomorrow, I could create my own SS Root CA, and issue a cert for the Verisign Intermediate CA, by putting myself as the Issuer, the Verisign Intermediate CA as the Subject, and putting the Verisign ICA public key in it. Your leaf cert will now chain happily up to either the Verisign SS Root, or my new SS Root. So this is not just a thing that works for renewing self-signed roots. What I don't understand is how the old (finally expired) root helps to validate the new unexpired root, when a verifier has the old root and the server presents the new root in its trust chain. I shouldn't speak for Gutmann, but I assumed that he meant that the server should send the new root *before* the old root expires, so that the client can prepare in advance for the expiry. As an aside, there are some funny issues around having a signature done before the signer cert expired, but deciding *after* the cert has expired, whether to trust it. It was ok yesterday, but maybe it's not ok today -- what has changed...? Geoffrey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
