Cryptography-Digest Digest #659, Volume #13 Thu, 8 Feb 01 16:13:00 EST
Contents:
Re: ECDSA certs (=?ISO-8859-1?Q?Tom=E1s?= Perlines Hormann)
Re: relative key strength private vs public key (DJohn37050)
Re: DSA PRG Flaw (DJohn37050)
Re: crack my enkryption (Daniel)
Re: Distributed entropy distribution ([EMAIL PROTECTED])
Re: File encryption with Rijndael (John Myre)
Re: crack my enkryption (Thomas Holenstein)
Re: DSA PRG Flaw (Bryan Olson)
Re: relative key strength private vs public key (DJohn37050)
Re: ECDSA certs (DJohn37050)
Re: Distributed entropy distribution (Tom St Denis)
Re: ECDSA certs (Roger Schlafly)
Re: relative key strength private vs public key (Roger Schlafly)
Re: ECDSA certs (Roger Schlafly)
Re: File encryption with Rijndael (Jirka Klaue)
Re: ECDSA certs (Peter Gutmann)
Re: File encryption with Rijndael (Benjamin Goldberg)
Re: ith bit of an LFSR sequence? ("Paul Pires")
Re: Encrypting Predictable Files [now on AONTs] (wtshaw)
Re: relative key strength private vs public key (DJohn37050)
----------------------------------------------------------------------------
From: =?ISO-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Subject: Re: ECDSA certs
Date: Thu, 08 Feb 2001 19:13:48 +0100
I don't think they are going to be used in near future. I have recently
tried to gather some info about the standard (X9.68) and merely found a
draft dated september 99. Until now nobody has been able to show me a
more recent draft, or even the final standard.
If I am mistaken, I please ask you to correct me and tell me where I can
find X9.68 standard document. I need it for my research studies.
FYI: X9.68 is supposed to serve as the spec for certificates including
ECDSA public keys (X9.62).
Maybe X.509, SPKI or other certificate formats may be used for it, but I
doubt it, as public-key-algo and signature-algo need to be included in
the respective specs and standards. Is this already done? I only know it
for sure on WTLS certs (WAP).
Nigel Smart wrote:
> Roger Schlafly wrote:
>
>> Is there anyone who is actually using ECDSA certificates?
>> People talk about using ECDSA, but I couldn't find any
>> actual certificates on the net. Can anyone point me to
>> some X9.62 ECDSA certificates?
>
>
> Agreed, if anyone knows a place one can obtain such certs
> plus a plug in for netscrape to use the certs to sign email
> I would also be interested.
>
> Assuming the certs/plugin can be cheaply and easily installed
> I will start signing my emails using ECDSA from tommorrow.
>
> Yours
>
> Nigel
--
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tomás Perlines (o:
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 18:23:39 GMT
Subject: Re: relative key strength private vs public key
I do not use AES 256 bit keys. I meet ANSI X9 requirements, Triple-DES (soon to
be replaced with AES) 1024-bit RSA/DSA keys and 161-bit ECDSA keys. I do not
have lots of risk or lots of assets associated with my transactions. But that
is not the point, someone else or a biz MIGHT.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 18:24:53 GMT
Subject: Re: DSA PRG Flaw
DSA RNG is biased as spec'ed with about a 2:1 bias favoring lower numbers.
This can be exploited when used to generate the k per-message secret (key).
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: crack my enkryption
Date: Thu, 08 Feb 2001 18:27:30 GMT
On Wed, 07 Feb 2001 23:32:33 -0800, "John A. Malley"
<[EMAIL PROTECTED]> wrote:
>Such enthusiasm for cryptography! That's good.
>
<snip>
>
>Mr. Ritter's site at http://www.io.com/~ritter/
>
>Mr. Savard's site at http://home.ecn.ab.ca/~jsavard/crypto.htm
>
>Mr. Peschel's site at http://members.aol.com/jpeschel/index.htm
>
>and to on-line crypto courses like (this for Classical Cryptography)
>
>http://www.fortunecity.com/skyscraper/coding/379/lesson1.htm
>
>They can point you to beginner, intermediate and advanced books and
>journal articles on the subjects of cryptography and cryptanalysis
>(which together make cryptology). They can answer questions on some of
>the most arcane corners of mathematics relating to cryptography and
>cryptanalysis.
>
>They will expect you to put in the time reading and studying the subject
>on your own. They are always willing to help answer questions as you
>make your way through the subject - but it's a journey you make with
>their assisting guidance - no one carries any bags for you, so to speak.
>
>And don't forget the group FAQ - Well worth the reading! The most
>common questions on crypto are answered therein. Including the question
>you posed on cracking an unknown cipher system's output. :-)
>
>Hope this helps,
>
>John A. Malley
>[EMAIL PROTECTED]
John,
I'd like to thank you as well as this is the first "nice" reply I've
ever read in this group on a question like this.
best regards,
Daniel
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Distributed entropy distribution
Date: Thu, 08 Feb 2001 18:25:42 GMT
In article <95um72$2sr$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <95ulo3$2jq$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > In article <95uiar$uvi$[EMAIL PROTECTED]>,
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > ...
> > >
> > > 1. Share a key0 (128-bit string or whatever), this is when they
> meet
> > > face to face.
> > >
> > > For each message:
> > >
> > > 1. Hash the msg i.e H = HASH(msg).
> > > 2. Encrypt the msg using msg_key = HASH(H || key0)
> > > 3. Transmit the ciphertext and H to the other person.
> > >
> > > That way they have to reverse a hash function not a cipher to find
> > your
> > > key. I.e you can keep using your homegrown algorithm as long as
you
> > use
> > > a secure hash like SHA or MD5 (yes MD5 would work for this purpose
> > since
> > > collision resistance is a side benefit as longas it's not terrible
> > this
> > > will work).
> > >
> > > Tom
> > >
> > > Sent via Deja.com
> > > http://www.deja.com/
> > >
> >
> > I would do something similar at first meeting I would give 2 keys
> > one for the next message (K1 in this case first message) and one
> > for the previous message (K0 in this case for the message never
sent.
> >
> > take your message call it P1 encrypt with K1
> > send it to bob
> > he takes decrypts and you use the plain text do a secure harsh
> > XOR the hash and K0 this becomes the next Key for the next message
> > used
> >
> > Know you or bob ( but only 1 of you no two message in transisit)
> >
> > send the next message you both know that key and the current key
> > and you never save more than one key back.
> >
> > This way if 50 message down the track they recover to sequential
> > keys becaise of the XOR situation they can never recover older
> > messages.
> >
> > in short
> >
> > kused = kold XOR hash(previous message)
> > then
> > kold = kused
> > then loop for next message
>
> That's actually a very neat idea. However it does suffer if a message
> is out of order or missing.
>
Well if they get out of order or miss a message they have to
either have a fall back set of keys. Or maybe BOB can do See Alice
at her place and get a new set there.
> It's a better idea if you want to make sure that the messages are
never
> read twice (i.e you secure delete the plaintext after reading it the
> first time). Since you are trying to prevent people from reading it
> twice you will delete it (it's not like the other side where you want
to
> copy it).
>
The idea was to delete any thing old so that if the
NSA grabs your two computers and gets current data that
it want be of much help in deciphering all the old cipher
text they have stored up from previous sessions.
Dave
Sent via Deja.com
http://www.deja.com/
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: File encryption with Rijndael
Date: Thu, 08 Feb 2001 11:45:29 -0700
Jirka Klaue wrote:
<snip>
> And there
> will never be a JVM on a chip-card, for instance.
I bet you're wrong. See:
http://www.cyberflex.slb.com
http://www.advancel.com/products.htm
http://www.1.slb.com/smartcards/products/mobile/3g.html
<snip>
> Assembler, or even better ISO-C code, can easily be
> ported to *any* system.
Assembler has its uses, but implying that it is more
portable than Java is silly.
JM
------------------------------
From: Thomas Holenstein <[EMAIL PROTECTED]>
Subject: Re: crack my enkryption
Date: 08 Feb 2001 10:42:19 -0800
"John A. Malley" <[EMAIL PROTECTED]> writes:
> And don't forget the group FAQ - Well worth the reading! The most
> common questions on crypto are answered therein. Including the question
> you posed on cracking an unknown cipher system's output. :-)
Which is, btw. located here:
http://www.landfield.com/faqs/cryptography-faq/
But my real reason for posting this is: could you, John, do this
again? Furthermore, can I store your (really excellent) posting to
post it on other questions like that?
Thomas
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: DSA PRG Flaw
Date: Thu, 08 Feb 2001 18:57:18 GMT
Roger Schlafly wrote:
> [...] I assume it is the simple observation that
> if you generate a random number mod 2^160, and then reduce mod q
> (where q is a 160-bit number), then there is a bias in the top
> couple of bits.
>
> It is hard to imagine this being a problem for anyone, but it would
> be nice to get it fixed anyway.
I have not seen the published paper either, but was
informed that it's more than the simple observation.
Bleichenbacher describes an exploit, which requires
many signatures and much computation, but nevertheless
constitues a short-cut solution.
As noted, to avoid the problem always choose k uniformly
in (1..q).
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 19:13:57 GMT
Subject: Re: relative key strength private vs public key
For the record, in 2001, ANSI X9/NIST mandate a minimum keysize for RSA/DSA of
1024 bits and for ECC of 161 bits. For hash output size it is 160 bits with
SHA-1. For symmetric key it is Triple DES, which is considered to have 112 bit
symmetric key strength due to meet in middle attack. This will be replaced
with AES with 128 bit minimum. So if you want to follow these minimum
guidelines, at least you know what they are. These mins are what the Federal
Government uses to protect sensitive but unclassifled data.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 19:16:38 GMT
Subject: Re: ECDSA certs
X9.68 is in ballot, editor is Phil Griffin. To get it, you need to attend an
X9F1 meeting where it is on the agenda (which is open to public) or ask the
editor and see if you can get one for review purposes. Once it is an official
ANSI X9 standard, it can be purchased.
Don Johnson
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Distributed entropy distribution
Date: Thu, 08 Feb 2001 19:11:08 GMT
In article <95uoao$53s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <95um72$2sr$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <95ulo3$2jq$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > > In article <95uiar$uvi$[EMAIL PROTECTED]>,
> > > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > > ...
> > > >
> > > > 1. Share a key0 (128-bit string or whatever), this is when they
> > meet
> > > > face to face.
> > > >
> > > > For each message:
> > > >
> > > > 1. Hash the msg i.e H = HASH(msg).
> > > > 2. Encrypt the msg using msg_key = HASH(H || key0)
> > > > 3. Transmit the ciphertext and H to the other person.
> > > >
> > > > That way they have to reverse a hash function not a cipher to find
> > > your
> > > > key. I.e you can keep using your homegrown algorithm as long as
> you
> > > use
> > > > a secure hash like SHA or MD5 (yes MD5 would work for this purpose
> > > since
> > > > collision resistance is a side benefit as longas it's not terrible
> > > this
> > > > will work).
> > > >
> > > > Tom
> > > >
> > > > Sent via Deja.com
> > > > http://www.deja.com/
> > > >
> > >
> > > I would do something similar at first meeting I would give 2 keys
> > > one for the next message (K1 in this case first message) and one
> > > for the previous message (K0 in this case for the message never
> sent.
> > >
> > > take your message call it P1 encrypt with K1
> > > send it to bob
> > > he takes decrypts and you use the plain text do a secure harsh
> > > XOR the hash and K0 this becomes the next Key for the next message
> > > used
> > >
> > > Know you or bob ( but only 1 of you no two message in transisit)
> > >
> > > send the next message you both know that key and the current key
> > > and you never save more than one key back.
> > >
> > > This way if 50 message down the track they recover to sequential
> > > keys becaise of the XOR situation they can never recover older
> > > messages.
> > >
> > > in short
> > >
> > > kused = kold XOR hash(previous message)
> > > then
> > > kold = kused
> > > then loop for next message
> >
> > That's actually a very neat idea. However it does suffer if a message
> > is out of order or missing.
> >
>
> Well if they get out of order or miss a message they have to
> either have a fall back set of keys. Or maybe BOB can do See Alice
> at her place and get a new set there.
>
> > It's a better idea if you want to make sure that the messages are
> never
> > read twice (i.e you secure delete the plaintext after reading it the
> > first time). Since you are trying to prevent people from reading it
> > twice you will delete it (it's not like the other side where you want
> to
> > copy it).
> >
>
> The idea was to delete any thing old so that if the
> NSA grabs your two computers and gets current data that
> it want be of much help in deciphering all the old cipher
> text they have stored up from previous sessions.
It's actually a good idea :-)
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: ECDSA certs
Date: Thu, 08 Feb 2001 11:23:01 -0800
Tomás Perlines Hormann wrote:
> I don't think they are going to be used in near future. I have recently
> tried to gather some info about the standard (X9.68) and merely found a
> draft dated september 99. Until now nobody has been able to show me a
> more recent draft, or even the final standard.
> If I am mistaken, I please ask you to correct me and tell me where I can
> find X9.68 standard document. I need it for my research studies.
> FYI: X9.68 is supposed to serve as the spec for certificates including
> ECDSA public keys (X9.62).
> Maybe X.509, SPKI or other certificate formats may be used for it, but I
> doubt it, as public-key-algo and signature-algo need to be included in
> the respective specs and standards. Is this already done? I only know it
> for sure on WTLS certs (WAP).
Strange. I have the X9.62 spec, but the coding for the ECDSA parameters
uses a confusing 1997 dialect of ASN.1, and the characteristic 2
keys require a complicated representation in terms of 3 particular
types of bases. No examples are given.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Thu, 08 Feb 2001 11:25:23 -0800
DJohn37050 wrote:
> For the record, in 2001, ANSI X9/NIST mandate a minimum keysize for RSA/DSA of
> 1024 bits and for ECC of 161 bits. For hash output size it is 160 bits with
> SHA-1. For symmetric key it is Triple DES, which is considered to have 112 bit
> symmetric key strength due to meet in middle attack. This will be replaced
> with AES with 128 bit minimum. So if you want to follow these minimum
> guidelines, at least you know what they are. These mins are what the Federal
> Government uses to protect sensitive but unclassifled data.
I thought that NIST still accepts 512-bit DSA keys.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: ECDSA certs
Date: Thu, 08 Feb 2001 11:26:38 -0800
DJohn37050 wrote:
> X9.68 is in ballot, editor is Phil Griffin. To get it, you need to attend an
> X9F1 meeting where it is on the agenda (which is open to public) or ask the
> editor and see if you can get one for review purposes. Once it is an official
> ANSI X9 standard, it can be purchased.
Do you know anyone who would be willing to email me a copy? Do you
have Phil's email address?
------------------------------
From: Jirka Klaue <[EMAIL PROTECTED]>
Subject: Re: File encryption with Rijndael
Date: Thu, 08 Feb 2001 20:49:23 +0100
John Myre wrote:
>
> Jirka Klaue wrote:
> <snip>
> > And there
> > will never be a JVM on a chip-card, for instance.
>
> I bet you're wrong. See:
>
[1]> http://www.cyberflex.slb.com
> http://www.advancel.com/products.htm
> http://www.1.slb.com/smartcards/products/mobile/3g.html
>
> <snip>
> > Assembler, or even better ISO-C code, can easily be
> > ported to *any* system.
>
> Assembler has its uses, but implying that it is more
> portable than Java is silly.
It's off topic, so please ignore, if you're not interested.
<OT>
OK, to be clear:
There is no such thing like "THE" JVM. A JVM is an
implementation. It *can* implement all features of
the reference implementation from SUN. Or not.
It's not a standard, so it's silly, as you said,
to think your class file runs everywhere, where
a JVM is implemented. Have you take a close look
at the links you've posted ? They refer to stuff like:
- Sun Microsystems Java Card API version 2
- the Access JV-Lite virtual machine
...
So what ? Why do you think that's better than
- some random library API for what proprietary
system soever
I doubt, that the OP's class-file executes on,
for instance the chip-cards mentioned in [1],
even if it could be downloaded there (doubtable
too). It's an advertising slogan that .class-files
execute on *any* system with a JVM. You believe it ?
Think again. Or even better, test it. :)
You claim, that porting assembly language is a silly
undertaking ? That depends. It's not *that* easy, but
one can do it for *any* system, again in contrast to
Java. OK, I shouldn't have suggested, that it easily
can be ported. That was sort of silly. The point is,
that it can be done. And I have to say again, that
the best way to write *portable* code is to use some
standardized language, for instance ISO-C. It's
*guaranteed* to execute on *every* system, where a
compiler is available.
Again, in contrast to Java with some virtual machine.
</OT>
Jirka
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: ECDSA certs
Date: Thu, 08 Feb 2001 20:32:18 -0000
Nigel Smart <[EMAIL PROTECTED]> writes:
>Assuming the certs/plugin can be cheaply and easily installed
>I will start signing my emails using ECDSA from tommorrow.
Uhh... what's the point of signing messages with an algorithm noone uses?
Peter.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: File encryption with Rijndael
Date: Thu, 08 Feb 2001 20:46:18 GMT
Jirka Klaue wrote:
[snip]
> > > Assembler, or even better ISO-C code, can easily be
> > > ported to *any* system.
> >
> > Assembler has its uses, but implying that it is more
> > portable than Java is silly.
[snip]
> You claim, that porting assembly language is a silly
> undertaking ? That depends. It's not *that* easy, but
> one can do it for *any* system, again in contrast to
> Java. OK, I shouldn't have suggested, that it easily
> can be ported. That was sort of silly. The point is,
> that it can be done. And I have to say again, that
> the best way to write *portable* code is to use some
> standardized language, for instance ISO-C. It's
> *guaranteed* to execute on *every* system, where a
> compiler is available.
> Again, in contrast to Java with some virtual machine.
I think we all agree that ISO-C is the best [or one of the best] things
for portability -- you don't have to (or shouldn't have to) modify it on
a system-by-system basis.
Similarly, though slightly less so, if you have a JVM, and aren't doing
anything really fancy (like a gui), then most java that runs on one JVM
will run identically, without changes, on any other JVM. (I say 'most'
not 'all' because I'm not stupid).
The same CANNOT be said for assembler. Sure, it can be "ported" [with
difficulty] but this involves translating the text instructions from one
assembler to the text instructions for another assembler. Plus
occasional actual changes/adaptations because of the system being ported
to being fundamentally different, in some subtle (or not so subtle)
manner (bigendian/littleendian/nuxiendian, or stack pointer/frame
pointer stuff, handling of function arguments, etc).
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: ith bit of an LFSR sequence?
Date: Thu, 8 Feb 2001 12:47:44 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Douglas A. Gwyn wrote:
> >
> > Benjamin Goldberg wrote:
> > > If we know x (or know n bits starting at i), and know y, and want to
> > > know i, what do we do? This is the second thing Bob asked about.
> > > THIS problem is exactly equal in difficulty to the discrete log
> > > problem.
> >
> > This suggests the possibility of fast hardware DLP solvers...
>
> Maybe, maybe not. However, the discrete log problem needed to solve
> this is the one over the field of GF(2)[x]/p(x), not over the field of
> Z/Zp. What forms of encryption [if any] use GF(2)[x]/p(x) type discrete
> logs as their strength?
>
> --
> A solution in hand is worth two in the book.
> Who cares about birds and bushes?
But consider, a hand in the bush is worth
two on the bird.
Sorry, I just couldn't resist.
Paul
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting Predictable Files [now on AONTs]
Date: Thu, 08 Feb 2001 14:37:26 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Simplistic example:
> filep -> [scott19u] -> filec1
> filep -> [scott19u] -> [prefix with "SCOTT19U:"] -> filec2
> While filec2 is about 10 bytes longer than filec1, which
> is a different kind of drawback, I don't think you want to
> argue that it is *less secure* just because the enemy can
> readily identify the method of encryption by examining the
> ciphertext.
On fundamental of security is to keep a low profile, same for encryption
with stegnography often very low. Announcing that you are using a
particlar algorithm can 1) flag you as belonging to a particular user
pool; 2) change unkown algorithm to known algorithm attack; and, 3) mean
that you swallowed the propaganda that that is the preferred way to do
encryption, and the best and only way to better security.
--
Sugar coated arsenic is bad for your health.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Feb 2001 21:05:39 GMT
Subject: Re: relative key strength private vs public key
NIST has agreed that the minimum DSA key size is 1024 bits. This will be made
explicit in the update to DSA (aka DSA-2) that will allow use of longer hash
output sizes (SHA-2).
Don Johnson
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
