At 05:12 PM 02/08/2002 +0100, Jaap-Henk Hoepman wrote:
>I think there _are_ good business reasons for them not wanting the users to
>generate the keys all by themselves. Weak keys, and subsequent
>compromises, may
>give the CA really bad press and resulting loss of reputation (and this
>business
At 5:12 PM +0100 2/8/02, Jaap-Henk Hoepman wrote:
>I think there _are_ good business reasons for them not wanting the users to
>generate the keys all by themselves. Weak keys, and subsequent
>compromises, may
>give the CA really bad press and resulting loss of reputation (and this
>business is bu
fidence in the operation of hardware tokens. ...
misc. aads chip strawman discussions
http://www.garlic.com/~lynn/index.html#aads
impresonation refs:
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm7.htm#auth Wh
I think there _are_ good business reasons for them not wanting the users to
generate the keys all by themselves. Weak keys, and subsequent compromises, may
give the CA really bad press and resulting loss of reputation (and this
business is built on reputation anyway). So: there are good reasons
>And if the runs test in FIPS were slightly extended, your sequence of
>consecutive 8-bit numbers would have been easily caught too. Here's the
>full spectrum of runs for your sequence:
>
> Run-length # of gaps # of blocks
> == = ===
On Wed, 6 Feb 2002, Greg Rose wrote:
> At 03:48 PM 2/5/2002 -0600, Kim-Ee Yeoh wrote:
>
> >Could you clarify what you mean by "counter output"? Are we talking about
> >a sequence of consecutive 8-, 16-, or 32-bit numbers? If so, FIPS will
> >detect and flunk such sequences.
>
> While priming t
At 12:20 PM 2/4/2002, Bill Stewart wrote:
>A smartcard-only system probably _is_ too limited to generate keys,
>but that's the only realistic case I see.
Here are some manufacturer claims for the DataKey 330 smart card: average
of 23 seconds to generate a 1,024-bit RSA key, average of 3 minutes
At 05:55 AM 2/7/2002 +1300, Peter Gutmann wrote:
>Greg Rose <[EMAIL PROTECTED]> writes:
>
> >While priming the RC4 table, I accidentally filled the data buffer instead
> >(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
> >
> >This very much passes the FIPS 140 tests for random
At 6:18 PM -0500 2/5/02, Ryan McBride wrote:
>On Tue, Feb 05, 2002 at 11:16:40AM -0800, Bill Frantz wrote:
>> I expect you could initialize the random data in that memory during
>> manufacture with little loss of real security. (If you are concerned about
>> the card's manufacturer, then you have
Greg Rose <[EMAIL PROTECTED]> writes:
>While priming the RC4 table, I accidentally filled the data buffer instead
>(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
>
>This very much passes the FIPS 140 tests for randomness, despite being nothing
>like it:
A generic order-0 en
> [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]]
>
>
> "Trei, Peter" <[EMAIL PROTECTED]> writes:
>
> >One other scheme I've seen, and which, while it doesn't give me warm
> fuzzies,
> >seems reasonable, is to issue the the enduser a smartcard with a keypair
> on
> >it. The SC generates the pair onbo
"Trei, Peter" <[EMAIL PROTECTED]> writes:
>One other scheme I've seen, and which, while it doesn't give me warm fuzzies,
>seems reasonable, is to issue the the enduser a smartcard with a keypair on
>it. The SC generates the pair onboard, and exports only the public half. The
>private half never l
Greg Rose <[EMAIL PROTECTED]> writes:
>The scariest thing, though... at first I put in an unkeyed RC4 generator for
>the self-test data, but accidentally ran the FIPS test on a straight counter
>output... and it passed (even version 1)! I'd always assumed that something in
>the regularity of a co
Jaap-Henk Hoepman <[EMAIL PROTECTED]> writes:
>It's worse: it's even accepted practice among certain security specialists.
>One of them involved in the development of a CA service once told me that they
>intended the CA to generate the key pair. After regaining consciousness I
>asked him why he t
On Tue, Feb 05, 2002 at 06:18:35PM -0500, Ryan McBride wrote:
> Having the manufacturer provide the random data changes the burden of
> proof drastically - there is no way for to _prove_ that they did not
> retain a copy of the random data, while it can be proved that they did
> not try to cheat s
At 02:45 PM 2/4/2002 +0100, Jaap-Henk Hoepman wrote:
>
>It's worse: it's even accepted practice among certain security
>specialists. One of them involved in the development of a CA service
>once told me that they intended the CA to generate the key pair.
>After regaining consciousness I asked him
On Wed, Feb 06, 2002 at 10:06:46AM +1100, Greg Rose wrote:
> At this point I am detecting a pattern... So, I'm afraid it isn't true that
> it will pick up even these simple linear sequences. (An LFSR of length 12
> only generates 4095 bits, repeated about 5 times!) I find this less
> surprising
On Tue, Feb 05, 2002 at 11:16:40AM -0800, Bill Frantz wrote:
> I expect you could initialize the random data in that memory during
> manufacture with little loss of real security. (If you are concerned about
> the card's manufacturer, then you have bigger problems. If anyone does,
> the manufact
At 03:48 PM 2/5/2002 -0600, Kim-Ee Yeoh wrote:
>I took a brief look at your code, and one optimization you could do is to
>make a single pass for both the monobit and poker tests. If c_0, c_1,
>..., c_15 are the frequency counts of nibbles, then the monobit count is
>just the sum over all i's of
On Tue, 5 Feb 2002, Greg Rose wrote:
> This forced me to instrument my FIPS-140 code to measure it. It takes 1.42
> ms to run a test on a Sun Ultra at 250MHz (I know, this is an ancient
> machine). It's all integer arithmetic, on short integers at that, except
> for the chi-square poker test,
At 6:37 AM -0800 2/5/02, Arnold G. Reinhold wrote:
>I'd argue that the RSA and DSA situations can be made equivalent if
>the card has some persistent memory.
I expect you could initialize the random data in that memory during
manufacture with little loss of real security. (If you are concerned a
>At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>>At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote:
>> >1) A typical message would have a 20-byte nonce random number, which
>> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
>> >signature (basic message plus 40-byt
I'd argue that the RSA and DSA situations can be made equivalent if
the card has some persistent memory. Some high quality randomness is
needed at RSA key generation. For the DSA case, use 256 bits of
randomness at initialization to seed a PRNG using AES, say. Output
from the PRNG could be th
>At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>>At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote:
>> >1) A typical message would have a 20-byte nonce random number, which
>> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
>> >signature (basic message plus 40-byte inf
At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote:
> >1) A typical message would have a 20-byte nonce random number, which
> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
> >signature (basic message plus 40-byte infrastr
At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote:
>One could claim that one of the reasons for using RSA digital signatures
>with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
>for quality random number generation as part of the signature process.
>
>A lot of the RSA digita
One could claim that one of the reasons for using RSA digital signatures
with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
for quality random number generation as part of the signature process.
A lot of the RSA digital signatures have the infrastructure that creates
the
o: Bill Stewart; [EMAIL PROTECTED]
> Subject: RE: Welome to the Internet, here's your private key
>
> At 10:20 AM -0800 2/4/02, Bill Stewart wrote:
> >There are special cases where the user's machine doesn't have
> >the CPU horsepower to generate a key -
a key pair
probably has other more compelling shortcomings as a
security token.
Cheers, Scott
-Original Message-
From: Bill Frantz [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 3:42 PM
To: Bill Stewart; [EMAIL PROTECTED]
Subject: RE: Welome to the Internet, here's your p
At 10:20 AM -0800 2/4/02, Bill Stewart wrote:
>There are special cases where the user's machine doesn't have
>the CPU horsepower to generate a key - PCs are fine,
>but perhaps Palm Pilots and similar handhelds are too slow
>(though a typical slow 33MHz 68000 or Dragonball is faster
>than the 8086/
> From:Jaap-Henk Hoepman[SMTP:[EMAIL PROTECTED]]
>
> It's worse: it's even accepted practice among certain security
> specialists. One of them involved in the development of a CA service
> once told me that they intended the CA to generate the key pair.
> After regaining consciousnes
ignoring for the moment the question of why certificates would be needed at
all
then public/private key technology is currently being used for (at least)
two distinct & different business processes
1) authentication
2) encryption
The business process of human person authentication has som
You sound surprised? I recently asked my bank[1] for a solvency
statement on a personal account and they responded that they were not
allowed to provide such statements. When pressed for an explanation I
was told that handing out those statements caused them too much
litigation. Apparently wh
, 2002 8:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Welome to the Internet, here's your private key
>
>
> It's worse: it's even accepted practice among certain security
> specialists. One
> of them involved in the development of a CA service once told
It's worse: it's even accepted practice among certain security specialists. One
of them involved in the development of a CA service once told me that they
intended the CA to generate the key pair. After regaining consciousness I asked
him why he thought violating one of the main principles of pub
--
On 4 Feb 2002, at 3:09, Peter Gutmann wrote:
> It is accepted practice among security people that you
> generate your own private key. It is also, unfortunately,
> accepted practice among non-security people that your CA
> generates your private key for you and then mails it to you
> a
It is accepted practice among security people that you generate your own
private key. It is also, unfortunately, accepted practice among non-security
people that your CA generates your private key for you and then mails it to you
as a PKCS #12 file (for bonus points the password is often included
37 matches
Mail list logo
