RE: OT: SSL certificate chain problems

2007-02-03 Thread Geoffrey Hird

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]


RE: More info in my AES128-CBC question

2007-04-24 Thread Geoffrey Hird
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: question re practical use of secret sharing

2007-06-27 Thread Geoffrey Hird
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]