From: "Greg Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: MD5 and X509
Date sent: Sat, 21 Apr 2001 11:35:14 -0400
Send reply to: [EMAIL PROTECTED]
Greg
What I need is something that I can count on being unique, but at a
reasonable size also. Four bytes fits quite nicely in an int (long) ,
and is based upon something that the Smart Card already contains,
the modulus of the public keys. Normally I use the internal object
handle of the public key, but one Smart Card we are working with
defines new/different handles at each session login, whereas most
other Smart Cards and tokens maintain the same handle from
session to session as long as the object is still valid. We use this
value as a key within other programs to perform operations using
the Smart Card.
Since we are trying to utilize the Smart Card/token for other things
besides our programs use, such as Netscape/Internet Explorer
email/SSL Access, etc. we don't want to mess with the common
fields such as the subject. We also find that the vast majority of
these cards do not support the "application specific" attribute so
thats out. Right now we use the ID field which is used by everything
I know of to store the modulus and to tie together the public/private
keys and the cert/private key.
Ken
For your puposes, you'd expect it to look like any other random function
that outputs four bytes. What exactly do you need for your 'unique enough'
property?
_____________________________________
Greg Stark
Ethentica, Inc.
[EMAIL PROTECTED]
_____________________________________
----- Original Message -----
From: "Rich Salz" <[EMAIL PROTECTED]>
To: "Kenneth R. Robinette" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, April 21, 2001 8:39 AM
Subject: Re: MD5 and X509
> > Apparently Eric Young
> > concluded that the first four bytes of the resulting signature of a cert
> > subject was unique enough to create lookup indexes. I was just
> > wondering what kind of trouble you could get into with this
> > conclusion.
>
> The worst case, of course, is needless hash-chain collisions.
>
> I don't think anyone has profiling data that shows this to be anywhere
> near worrying about, in terms of effciency.
> /r$
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__________________________________________________
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-560-9170
[EMAIL PROTECTED]
http://www.securenetterm.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
