Cryptography-Digest Digest #18, Volume #11 Sun, 30 Jan 00 19:13:00 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Jerry Coffin)
Re: Is there a practical guide to using crypto? (Jerry Coffin)
Re: Wireless PKI now or later ("Lyal Collins")
Re: *** ECC Strong and Weak combined (Greg)
Re: NIST, AES at RSA conference (Bryan Olson)
Re: XML vs Javabean for B2B (Drew Cutter)
Re: Wireless PKI now or later (Drew Cutter)
Re: Strip Security (Highdesertman)
Re: XML vs Javabean for B2B (Drew Cutter)
----------------------------------------------------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: Sun, 30 Jan 2000 15:55:00 -0700
In article <871459$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> That pegs you with great accuracy. The Miller Audio Research unit
> is a really nice system that is optimized for one thing that it does
> very well - tests for quality differences between CD players. Let
> me guess. You are an audiophile, subscribe to THE ABSOLUTE SOUND or
> STEREOPHILE, think that STEREO REVIEW is a bit off base at times,
> and spend a lot of time training your ears to hear subtle differences
> in audio gear. (or maybe you are a tech who services that market).
> If I am right about you, I would like to add that, in my opinion,
> the state of the art in audio would be stuck in 1950 without folks
> like you. That being said, the Miller unit is of very little use
> outside of the specific job it was designed to do. We are
> measuring jitter at a level where you can actually count the atoms
> that make the edge of the pit. Orders of magnitude more accurate.
Right -- when you're working with the internals, you certainly use
different instruments. I don't subscribe to the magazines you've
named, nor am I employed a tech in the audio industry at all. From
glancing through them now and then, I've little or no doubt that all
the stereo magazines around are at least a little off nearly all the
time. It's certainly difficult to give much credit to some of the
witchcraft a few of them seem to advocate.
The testing I work with has to do with patents. If you're looking for
effects from the design on the chips in a CD-player, you've pretty
much got to look at the signal AFTER those chips have processed it.
With the level of integration in a modern CD-player, you usually get
about three choices: 1) unprocessed signals straight from the pickup,
2) processed digital, or 3) analog audio.
If you've got somebody willing to spend enough money, you can read
back the circuits in a chip and then use a FIB to put in contacts
where you want to make measurements. Unfortunately, this instantly
increases the cost by two or three orders of magnitude. Fortunately
for us, in this case it wasn't necessary. In case anybody cares, the
part we were looking at in this case was a Crystal receiver. Those
who've worked with CD-players at all will undoubtedly realize that in
this case "Crystal" has nothing to do with pieces of quartz... <G>
> >or that you have a clue about what difference popularity of a piece
> >of test equipment makes
>
> It makes a difference when talking to Michael Kagalenko, who
> (unlike you) has never measured any parameter of any crystal
> oscillator.
Here's where I truly screwed up: I didn't read the attributions
carefully enough, and thought it was Michael Kagalenko to whom I was
replying.
When I originally replied, I was thinking more or less in terms of
general-purpose test equipment. Just for example, when I'm poking a
things with an oscilloscope, I have an old Tektronix model. Offhand,
I don't know whether it was more popular than its HP counterpart, but
I'm hard put to believe that anybody would really care either.
OTOH, when I think about it, jitter measurement equipment is quite a
bit more specialized -- I suppose even knowing which companies are in
the business at all might tend to indicate that somebody knows a
little bit about the subject.
> >to the fact that nearly every statement you've made in
> >this thread is provably and utterly false.
>
> You know, your previous posts always struck me as quite reasonable
> and friendly. Why the Jeckel and Hyde bit?
As above -- I basically got sick to death of Mr. Kagalenko spouting
nonsense and _thought_ I was replying to him. Most of the time when I
write a message like this one, I just use it to blow of a bit of
steam, and delete it before it goes anywhere. In this case it
accidentally got sent out; even though I think it accurately
characterizes nearly everything he (NOT you) has said in the thread, I
really didn't intend make a public statement about it quite so
strongly. In any case, it wasn't intended to be directed toward you
at all.
> May I assume from this that you are
> in agreement with Michael Kagalenko's opinions about how crystal
> oscillators work?
God NO! That was what I'd intended to object to. It seems to me that
he's spouting complete nonsense about something of which he hasn't the
least grasp at all. At least as far as I can tell, if crystal
oscillators acted like he claims, we could plan on the average
oscillator drifting by tens of percent over a matter of a few days of
use, but then by being turned off and back on, they'd magically start
back up at rated frequency again. I'll grant anybody that turning one
off for a while will usually result in a small change in frequency
simply because most oscillators generate at least a little heat, so
the crystal will normally cool off a little when it's not in use, but
the effect here is usually quite minor, and at any rate jitter and
thermal drift are fundamentally unrelated in any case.
> May I assume from this that you are in agreement with Michael
> Kagalenko's opinions that comparing a crystal oscillator against
> an Internet time server is a good way of generating random numbers
> suitable for cryptography?
Again, not at all. The whole reason oscillators are built around
crystals is to make their output as dependable and predictable as
possible. If you're trying to build something that produces
_un_predictable output, it's downright silly to start with something
that's intended to eliminate exactly the unpredictability you're
looking for.
If you insist on starting with crystal oscillators, about the only way
you're going to get enough entropy to be useful is to take two and run
them 180 degrees out of phase with each other. With a bit of
filtration, what's left should be reasonably unpredictable.
However, the VAST majority of what's left isn't going to be related to
jitter, or anything else from the crystals at all: it's going to be
noise in the circuits, probably mostly in the resistors. Since you're
looking mostly at resistor noise anyway, you might as well eliminate
the oscillators, and just amplify resistor noise to start with. Best
of all, you don't even have to design your amplifier very carefully,
since you don't particularly mind if it adds still more noise to the
output.
In short, if you want a source of entropy, about all you need is a
couple of cheap resistors, a capacitor or two and a transistor. Given
costs anymore, you could probably use an op-amp instead for almost no
increase in cost -- in fact, it might eliminate enough other parts to
decrease cost. In any case, this sort of design will give you entropy
that really is unpredictable, and it'll do produce a fair amount of it
fairly quickly for an extremely minimal investment.
Schemes involving connections to atomic clocks and such seem to do
pretty much the opposite: you have to either have your own atomic
clock (rather an expensive proposition by itself) or else connect to
somebody else's somehow or other. If we're talking about connections
via the Internet, the whole exercise becomes pointless and roles are
probably reversed: even if the atomic clock signal starts out
extremely precise, by the time it makes it through a few routers and
to your machine, you're left with FAR less precision than even a cheap
local oscillator.
Now, if the delays involved were really unpredictable, that wouldn't
necessarily hurt anything. Unfortunately, that's not the case: quite
a few of the delays in routers ARE fairly predictable, and given an
opponent in the correct position, may even be quite controllable (e.g.
by sending out a huge number of packets about when you're going to get
the time next, he may be to force longer delays).
IOW, rather than getting random numbers, you may be getting fed
numbers directly by your attacker. In most cases, a "chosen key"
attack makes life pretty simple for the attacker... <G>
-
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Is there a practical guide to using crypto?
Date: Sun, 30 Jan 2000 15:55:05 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> One thing I really want to know is if VISA card number consists of
> 16 digits with two digits for month and four digits for year, whats
> to stop someone from attempting every possible 22 digits combination
> until they find one which works?
The fact that there are 10**22 possible combinations.
Some quick figuring indicates that if 1,000,000,000 Visa cards have
been issued, and you had enough credit card verification machines to
try 1000 different numbers a second, you need to keep trying for
around 160 years before you stand a reasonable chance of finding one
that's in use. Of course, when you do, chances are that it's within
$20 of its limit and it won't do you any good anyway.
In reality of course, the bank would probably notice something wrong
well before you got this far. The expect a few mistakes in entering
card numbers, but if you're trying to verify 1000 a second for years
at a time and NONE of them is right, they'll probably figure out that
this is a little more than the usual mistakes in entering card
numbers.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Wireless PKI now or later
Date: Mon, 31 Jan 2000 09:57:56 +1100
I'm not sure about bandwidth being a non-issue.
A typical Versign-style certificate chain is 5k+
In the case of SET, certificates as large as 13kbytes have been reported.
A signing certificate, and a seperate encryption certificate doubles this
data burden in some situations.
Receiving , then sending certificates chews bandwidth in both directions.
We are starting to talk in terms of seconds per transmitted certificate
(each way), all adding to the chargeable air-time, especially under standard
GSM and CDMA.
Good for the network operator, if noone else.
Less of an issue in some specific wireless versions.
lyal
Drew Cutter wrote in message <[EMAIL PROTECTED]>...
>Supposedly bandwidth isn't going to be an issue , according to their web
>pages . However , how many companies can afford PKI for wireless - palm
>pilot ,window ce or smart phones. They seem to be all Java based.
>Question : how good are the XML digital certificates ? If the cost is
>reasonable and XML is good for non-pki encryption it looks like I will
>be using it.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Sun, 30 Jan 2000 22:58:17 GMT
> > I thought that n was related to the field size, not the number of
> > bits in the private exponent that can vary.
>
> No. To be a little more precise, n would be the minimum of the number
> of bits that can vary in the private exponent, and the bit-length of
> the largest prime factor of the curve order.
I have never heard this before. Where can I find a paper on the
Pollard Lambda attack that explains this in some detail? After
reading this post of yours, I have been searching the web and found
nothing yet.
> To get the best possible security/speed trade-off, IMHO you
> should use a random curve with a known prime or "nearly prime"
> order ("nearly prime" means a large prime multiplied by a small
> integer cofactor, say 2 or 4), and a full-length exponent.
The problem here (for me) is that it is random and you are never
sure how strong the curve might be- or more precisely, how weak
a particular instance of encryption might yield.
> If you have performance problems, it's better to decrease the size of
> the field but keep using full-length exponents, than it is to decrease
> the exponent length [*]. This is because a curve multiplication takes
> time proportional to the cube of the field size (for full length
> exponents), while shortening the exponent only gets you a linear
> speed-up.
I found this interesting and it turns out that when I looked at
my data you were right. I found that my data follows your claim
quite precisely.
> Technically, it could be argued that a too-short field size allows
> breaking a long-term key, whereas a too-short exponent requires a
> separate attack for each session. However, I don't think this really
> makes much difference; security parameters should normally be chosen
> sufficient to prevent *any* sessions from being broken.
I understand this...
> There was a thread about exponents with some always-zero bits in
> sci.crypt last November, for the case of Diffie-Hellman over GF(p) -
> look on DejaNews for the title "bits of diffiehellman private key".
> The attacks described in that thread also apply to elliptic curve
> Diffie-Hellman.
>
> > Also, my example of 80% was extreme. Let's say a field of 163 bits
> > and a key space of 64 bits or 80 bits. Even if n were related
> > to the size of the key, would you say 80 bits was secure for at
> > least a couple of years?
>
> No. The cost of an attack is then on the order of 2^40 curve
> operations. At a rough guess, that's probably a few days
> with a small network of PCs (*much* less if the attacker
> has custom hardware). To get a conjectured security level
> of about 2^80 operations, you would need a 160-bit exponent,
> in which case you might as well use the full 163 bits.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 30 Jan 2000 23:03:57 GMT
John Savard wrote:
> bryan.olson wrote, in part:
>
> >But where is the proof that the adversary will have to
> >attack it that way? If in fact he has a general solution,
> >then the argument is irrelevant. Does adding additional
> >cipher layers seem stronger? Absolutely. Does it help us
> >prove strength? No, at least it hasn't yet.
>
> If the only response to a situation where "we lack proof" is to find
> some way to get proof, your objection would be fatal.
>
> However, if "we can't get proof" is also considered as a reason to,
> failing some way to obtain proof, try to at least do everything we can
> to make our ciphers stronger - without proof that we have done enough,
> without the knowledge whether or not we may have done more than is
> necessary - then things like Mr. Ritter's multi-ciphering are entirely
> sensible responses to the situation.
I'll explain my point in terms of the two responses you
present. I see Ritter's argument as insisting that "we lack
proof" is fatal to any cipher that an effort such as AES
might produce, regardless of how the designer of that cipher
may have applied the "do everything we can" principle in
your second paragraph. He rejects such ciphers
categorically, saying we have no results about them. He does
not consider any analysis of their properties or any
internal structure they may have; they are simply rejected
because we cannot disprove that an adversary may break them.
Then for the systems Ritter advocates, I do not see the same
criteria applied. If we do apply it, then these
multi-ciphers fail just as surely as single ciphers.
Do we accept a cipher with unproven and unquantifiable
security? If the answer is "yes with great caution" then
the idea that we cannot categorically reject single ciphers;
we have to carefully apply that great caution in the design
and analysis of that cipher. That is the process the AES
effort is pursuing.
If the answer is that we cannot accept a system with
unquantifiable security, and I see the position as
reasonable though it is not my own, then no system based on
computational security can pass, no matter how layered or
dynamic. If all unprovable ciphers must be tripled, then we
must triple our triples of triples with no end.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 31 Jan 2000 18:20:50 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: XML vs Javabean for B2B
Thanks for the education. I'm trying to decide on which CA / encryption
company to go with for my business. The one company offer Javabeans and
the other offer xml encryption of documents.
------------------------------
Date: Mon, 31 Jan 2000 18:22:08 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Wireless PKI now or later
What about PKI with WAP ?
------------------------------
From: [EMAIL PROTECTED] (Highdesertman)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Sun, 30 Jan 2000 23:38:38 GMT
Reply-To: [EMAIL PROTECTED]
Hi Gordon, nice to see you again
I am no mathmatician, and my understanding of cryptography is not by
any means anything beyond amateur. But may I make a couple of comments
here?
IDEA is a block cypher. My understanding of block cyphers is that by
their nature, the password is removed from the actual encrypting key,
the key being generated by the algorythm itself.
>The other issue is the password. From memory I think IDEA uses a
>128-bit key. That means there are on the order of 10^38 possible keys.
>However the key used for your database is presumably just a hash of
>the entered word or phrase. If you picked a five character password
>with no numbers there you have restricted yourself to about 10^7
>possible keys. In other words a brute force solution has just become
>about a billion billion billion times easier and could probably be
>done in a matter of seconds on a PC.
I usually find myself in agreement with your posts, but in this case,
I must disagree.
I don't believe your estimate of the resources required to crack IDEA
is accurate. You are correct in pointing out that the security of the
application is dependent on the proper implementation of the algorythm
and the design of the program. But assuming the above has been done
properly, I don't believe that cracking IDEA is quite so easily done.
I used to read through sci.crypt quite often, and found it to be quite
interesting although half the time I got lost in the math.
Periodically, there are internet contests in which mathmeticians,
cryptoanalysis experts and amateurs all compete to crack a particular
algorythym. This is why it is so important to use a security program
that implemets an algorythm with published code. publishing the code
allows for analysis of weaknesses. As I am sure you know, there are no
crackproof algorythims, but the longer they stand up to these
assaults, the more secure they are considered. This is why I like IDEA
and BLOWFISH so much. They have been through many such attacks, and
unless something has changed that I don't know about, they have never
been fully cracked (although blowfish has a known weakness that allows
partial resolution of the encryption process. Even so, it remains a
secure algorythm.) By the way, as a matter of interest, did you know
DES was cracked in this way, long ago? If i'm not mistaken, this was
the catalyst that initiated the development of Triple DES.
Anyway, I am getting off topic. My point is this: Strip should be
secure enough for any common application, IMHO. If you have
information in your palm that you fear will fall into the hands of the
NSA (and you have reason to believe they would want that information
to begin with) then I'm not sure using a palm to store it would be
such a good idea in the first place. But for keeping credit card
numbers, accounts, and logons, it should be just dandy. I am a bit of
a security freak, so I loaded hackmaster and padlockhack (padlockhack
comes in a freeware, and a "pro" version) and now, to get any
information from my palmtop, an invader would have to get past
padlockhack before they could even begin working on strip and the IDEA
encrypted files it keeps. I feel good about my assumption that there
is nobody that will work that hard to find out how I log onto yahoo
mail. :-)
By the by, I have sent a copy of this to sci.crypt, and I welcome any
comments that those learned folks may have about this subject.
cheers,
Mathew
On Mon, 24 Jan 2000 09:55:14 GMT, [EMAIL PROTECTED] (Gordon Walker)
wrote:
>On Thu, 20 Jan 2000 17:24:37 GMT, Scratchie <[EMAIL PROTECTED]>
>wrote:
>
>>Does anyone know how secure the "Strip" password utility is? You have to
>>enter a password to enter the app, but are the passwords encrypted in RAM?
>
>There is no need to store the passwords in any form. They will exist
>only so long as the application is running and using them to decrypt
>data.
>
>>Would it be possible to bypass the app retrieve the records some other
>>way?
>
>The database is encrypted using the IDEA algorithm which means that in
>theory it'll stop anyone but a large government from cracking it. I
>say in theory because there may be errors in this particular
>implementation of the algorithm. I'm not qualified to subject the code
>to that kind of analysis but I'd still be happy that decryption would
>be extremely hard.
>
>The other issue is the password. From memory I think IDEA uses a
>128-bit key. That means there are on the order of 10^38 possible keys.
>However the key used for your database is presumably just a hash of
>the entered word or phrase. If you picked a five character password
>with no numbers there you have restricted yourself to about 10^7
>possible keys. In other words a brute force solution has just become
>about a billion billion billion times easier and could probably be
>done in a matter of seconds on a PC.
>
>To use the full keyspace of the algorithm you'll need a password at
>least 24 characters long including spaces and numbers. That's probably
>a bit excessive. Personally for the kind of data I keep in it a simple
>phrase of more than 10 or 15 characters provides enough security to
>keep me happy.
>--
>Gordon Walker
------------------------------
Date: Mon, 31 Jan 2000 18:41:17 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: XML vs Javabean for B2B
John I'm looking a wireless encryption (wap) on palmpilot , window CE
either using javabean or XML and PKI . Suggestion would be appreciate ?
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
