Cryptography-Digest Digest #941, Volume #10 Thu, 20 Jan 00 20:13:01 EST
Contents:
Re: elliptic curve (DJohn37050)
Re: Publication Reference for Vernam Cipher (Mok-Kong Shen)
Re: Beginners questions re-OTPs ("Douglas A. Gwyn")
Re: Combination of stream and block encryption techniques ("Douglas A. Gwyn")
Re: Beginners questions re-OTPs (Bill)
Re: SRP optimisation (Keith Burdis)
DATABASE NATION's Simson Garfinkel on tour! (Simone Paddock)
Re: Intel 810 chipset Random Number Generator (Terry Ritter)
Re: SRP optimisation (John Myre)
Re: Implementing access controll in embeded controller (Peter Pearson)
Re: Combination of stream and block encryption techniques (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: elliptic curve
Date: 20 Jan 2000 23:16:49 GMT
Check out white papers at www.certicom.com on ECC. Check out IEEE P1363 for
ways ECC can be done.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Publication Reference for Vernam Cipher
Date: Fri, 21 Jan 2000 00:32:11 +0100
Jim Haynes wrote:
>
> There is a funny story connected with the Vernam cipher in the book
> "Old Wires and New Waves" by Harlow. (from memory now, so may be
> distorted) After WW-I there was a show-and-tell for the press, and
> one of the things they showed was a Vernam cipher machine. (Which
> mixes Teletype characters with a one-time key tape to produce
> encrypted Teletype; and then reverses the process at the receiving
> end with a copy of the key tape to produce clear text.) They told
> the press they had invented a machine that would translate between
> French and English. They put a pre-punched tape with an English
> sentence into the machine and out came a French translation. Putting
> the French into the machine they got back the English. Of course what
> they really had were English and French versions with precisely the
> same number of letters, and a carefully hand-prepared key tape that
> would transform one into the other.
I don't know this story but one of similar nature. In the early
years of research on machine translation of natural languages
there was a demonstration by a team showing results of translating
Russian into English with (at that time surprising) superb quality.
It turned out that the texts output were translated by humans and
stored in the computer.
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Beginners questions re-OTPs
Date: Thu, 20 Jan 2000 23:27:08 GMT
Bill wrote:
> I'll rephrase the question, If you have message(s) that were
> encrypted with a "supposed" OTP what methodology/statistical
> analysis would be carried out to try and break it?
It's called "cryptanalysis" and cannot be boiled down to a simple
recipe. The sci.crypt FAQ contained pointers to tutorials on C/A
(last I looked). The classic textbooks are available from Aegean
Park Press.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Thu, 20 Jan 2000 23:30:01 GMT
In most cases there *is* a clear difference between a "stream" cipher
and a "block" cipher; it's essentially the same as the difference
between a continuous-flow chemical process and a batch process.
------------------------------
From: [EMAIL PROTECTED] (Bill)
Subject: Re: Beginners questions re-OTPs
Date: Fri, 21 Jan 2000 00:18:38 GMT
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III" <[EMAIL PROTECTED]>
wrote:
>The reason there are well-defined attacks upon other kinds of ciphers is that
> those ciphers have a
>particular structure that can be analyzed. An OTP key stream can come from
> just about anywhere, so there
>is no predefined structure to analyze. The most general form of attack is to
> figure out where the keys
>are coming from and try to predict/duplicate them. THis usually requires
> massive amounts of data,
>including plaintext. From the plain and cipher texts you can calculate the
> keys. Once you have the keys
>you can look for patterns. If there's a lot of qwerty & asdfgh someone is
> pounding a keyboard and you
>look for that kind of bias. If a key reads like Shakespeare or Omar Khayyam
> you start trying classical
>literature. If the key looks like a a WAV file you find out what kind of music
> it is. If the key looks
>like a pin up girl you try to find the photographer. If the key looks like a
> PRNG you try to find the
>structure and seed.
>
<snip>
Thanks for your reply Trevor, I can see now that it is an interesting one I've
picked to start with!
I'll have a look round for "Venona" on the net.
Cheers,
Bill
------------------------------
From: Keith Burdis <[EMAIL PROTECTED]>
Subject: Re: SRP optimisation
Date: 20 Jan 2000 23:39:48 GMT
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Keith Burdis <[EMAIL PROTECTED]> writes:
>>
>> >> Does having the server send its evidence first adversely affect the
>> >> security of SRP in any way?
>>
>> > Now the adversary can do an off-line password guessing attack.
>> You are quite correct. I've included a full description of the details of
>> the attack below.
> Thanks - this was enlightening! I'll add my own thoughts here:
Glad you found it useful :-)
> This isn't an incidental property of the way the verifiers are
> calculated, AFAICT, but an essential one. With SRP, an attacker can
> get two kinds of data: snooped sessions, where it doesn't know either
> ephemeral private key, and attacker-initiated sessions, where it knows
> one of them. Snooped sessions are essentially a mystery to it because
> all the unknowns are too high-entropy to attack. But with sessions it
> initiates itself, the only important unknown is the password itself.
> Now the thing that makes server verification work in SRP is that it
> proves it has the verifier corresponding to your password, so it will
> only work if given the correct password.
> Thus if the server provides information sufficient to verify itself
> before it's verified the client, a password attack can be mounted; but
> it's safe to provide it once the client is verified because that means
> the holder of the ephemeral private key "a" has the password.
> I'm sure you already knew this, but I didn't, so I'm glad to have been
> given occasion to think about it!
Well, I didn't know that, which is why I came up with an "optimisation" that
didn't work ;-)
> Unfortunately, it seems you *can* mount a password-guessing attack if
> you can fool a client into thinking you're the server. That's quite a
> bit harder, though.
I thought that this was so too, but after re-reading section 3.2.3 of Tom's
ISOC paper, I think he is one step ahead of us again. If I read it correctly,
the server must compute B as:
B = v + g^b
otherwise the client's K, computed as:
S = (B - g^x)^(a+ux)
K = H(S)
will not equal the server's K, computed as:
S = (Av^u)^b
K = H(S)
which means that the server can't use the received M1 and the other stuff it
knows:
b, C, s, A, B, u, M1=H(A,B,K)
to verify a guess at P, because K will not be the same.
I received a message from David P Jablon in which he said:
"In general, with any of these zero-knowledge password protocols in the
EKE/SRP family, each party that sends a proof of the password must
first receive a message from the other containing a commitment to the
password.
In the protocol you've shown, Carol receives M2 without having
revealed anything that was constructed with the password.
This permits her offline brute-force attack."
In the case of the server, its component of the password is the verifier v,
so it must commit to it in step 4 by constructing something with it, in this
case B.
Anyone more knowledgeable than myself care to comment on my reasoning with
regards to the computation of K by both parties?
Thanks.
> /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
- Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras JAPH QEFH
---
------------------------------
From: [EMAIL PROTECTED] (Simone Paddock)
Subject: DATABASE NATION's Simson Garfinkel on tour!
Reply-To: [EMAIL PROTECTED]
Date: Fri, 21 Jan 2000 00:05:53 GMT
Ralph Nader called it "a graphic and blistering indictment..." and
Mark Rotenberg, Director of EPIC, said it "marks the turning point in
the national debate over the future of privacy".
"Database Nation: The Death of Privacy in the 21st Century", by Simson
Garfinkel, is about one of our most fundamental civil rights - the
right to personal privacy - and the serious threats to that right that
we are facing today.
Fifty years ago, in the book "1984", George Orwell imagined a future
in which privacy was vanquished by a totalitarian state that used
spies and video surveillance to maintain control. In 2000, we find
that the threats to our privacy are not coming from a monolithic "Big
Brother", but - even harder to grapple with - hundreds of sources, not
seeking to control us, merely to market to us, track us, count us, or
streamline paperwork.
The result, though, is still as chilling as "1984".
Read a sample chapter at:
http://www.oreilly.com/catalog/dbnation/chapter/ch06.html
For more information about the book, including Table of Contents,
index and author bio, see:
http://www.oreilly.com/catalog/dbnation/
******************************************************************************
SIMSON GARFINKEL is also signing books in the following locations
around the US:
For Boston area:
Jan 26, 2000, 7:30 pm
Barnes & Noble
1 Worcester Road
Framingham, MA 01701
508-628-5567
For Washington DC area:
Feb 3, 2000 at Noon
Reiter's Scientific & Professional Books
2021 K Street NW
Washington, DC 20006
Ph: 202-223-5561
For Seattle area:
Feb 7, 2000, 7:30 pm
Barnes & Noble Bookstore
15600 NE 8th Street Suite Q-1
Bellevue, WA 98008
425-641-3554
For San Francisco/Bay area:
Feb 10, 2000, 7:30 pm
Borders Books
Stonestown Galleria
233 Winston Drive
San Francisco, CA 94132
415-731-0665
Feb 11, 2000, 7:00 pm
Signing and Q&A
Barnes & Noble Bookstore
2352 Shattuck Avenue
Berkeley, CA 94704
510-644-3635
Simone Paddock, Online Evangelist
O'Reilly & Associates
[EMAIL PROTECTED]
www.oreilly.com
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Intel 810 chipset Random Number Generator
Date: Fri, 21 Jan 2000 00:38:52 GMT
On 20 Jan 2000 14:47:46 EST, in <867op2$[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Guy Macon) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>>
>>On 20 Jan 2000 05:16:43 GMT, in <8665nr$6ro$[EMAIL PROTECTED]>, in
>>sci.crypt [EMAIL PROTECTED] (Michael Kagalenko) wrote:
>>
>>>Paul Koning ([EMAIL PROTECTED]) wrote
>>>
>>>]Crystals? Not likely. Resistors, noise diodes, Zener diodes, all
>>>]those sound plausible, but crystals won't serve at all for this
>>>]application.
>>>
>>> Yes, they will. Crystals have thermal noise.
>>
>>OK, so just how much thermal noise would one measure from a crystal,
>
>Not much. Lots of signal, not much noise, but it is there.
>
>>how would we measure it
>
>The best way would be to ufe a standard Jitter test set. Anyone who
>designs CD players has one.
"Jitter" implies a repetitive wave from an oscillator.
I am satisfied that the major source of jitter in most crystal
oscillators is the noise at the analog-to-digital conversion junction.
This is not crystal noise, it is amplifier noise.
Very low noise techniques probably could pick up a noise voltage from
crystal pins, just like they can pick up noise across a resistor. I
expect that this would not be trivial, but if you think otherwise, I
stand ready to measure my stock of crystals.
>>and where can we find a published reference to back that up?
>
>Any databook from any crystal manufacturer.
Please, feel free to be a great deal more specific.
Jitter is an issue of circuit design, not crystal design. Crystals
are not sold in low-noise versions. There are low-jitter oscillator
circuits.
>>At one time, crystal filters were used in fine communications
>>receivers; such receivers are intimately involved with noise, and are
>>compared in part by actual noise measurement. We can thus reasonably
>>conclude that in communications receivers any noise which was added by
>>a crystal filter was far below the modest signal levels involved.
>
>Crystal filters are narrowband bandpass filters. Thet do add a bit of
>noise (not much) in band but it's worth it to reject noise and signal
>from out of band. (You use a crystal oscillator for a RNG, not a crystal
>filter)
>
>Despite the low noise/high signal, a crystal oclillator makes
>a fairly good RNG that is very easy to interface to a PC.
I think this is clearly false. You may wish to consider comments from
1992:
http://www.io.com/~ritter/RAND/NICORAND.HTM
>Send the TTL level output to an input line on your parallel
>port, wait long enough between measurements to make whether
>the signal is high or low random if the jitter is random,
>then run it through a Von Neuman compensator.
Any jitter is likely to be bipolar around the reference frequency and
phase. In the long run, it cancels out. In the short run it is
normally distributed and tiny. That means the jitter itself will be
undetectable in this application. Jitter is detectable as sideband
noise in communications use, or in comparison to a more-stable
reference. With a 20 MHz or 50 nsec clock, jitter may be around 8
psec. You will not measure that with any PC by itself.
What really happens in this application is that you have a stable
oscillator, and then sample that signal at times which vary due to
software, the memory refresh, and other interrupts and bus actions.
This is dangerous in the sense that the randomizing factors are not
controlled and may in the end be not all that random. The long term
stability of the crystal oscillator makes this worse. What we want
for random values is an unstable oscillator, not a stable one.
>This has an
>advantages over resistor noise in that it is less vulnerable
>to outside electrical interference.
No. Oscillator jitter comes from noise, typically junction noise.
The noise may be a little larger than Johnson noise, but not so that
it would resist deliberate interference or manipulation.
>The data rate is slow.
>
>What I can't decide is whether I prefer ceramic oscillators
>instead of crystal oscillators for this application.
I think "ceramic resonator" would be the correct term. They will be
less stable, but not nearly unstable enough.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: SRP optimisation
Date: Thu, 20 Jan 2000 17:41:17 -0700
Paul Crowley wrote:
>
> Unfortunately, it seems you *can* mount a password-guessing attack if
> you can fool a client into thinking you're the server. That's quite a
> bit harder, though.
Actually, I don't think so. This is because the server does not
send an unadorned B = g^b, but B = g^b + v (where v is the verifier
based on the password and salt). If you are pretending to be the
server, of course you can send any B you want. But since you don't
know v, you don't actually know the effective b (your purportedly
private key) either!
That is, to perform an off-line attack, you have to send B to get
M1. Now you can check each guess of a password, but to do that,
for each guess you compute v, and then you have to to a discrete
logarithm to get b, so you can compute K and check M1. (And of
course, we are presuming that discrete logs are infeasible).
John.
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Implementing access controll in embeded controller
Date: Thu, 20 Jan 2000 16:55:10 -0800
Niels Erik Danielsen wrote:
> I'm designing software for an embedded controller, controlling an industrial
> process.
> This controller has local and remote possibilities for operating the
> machine, and the system has different access levels ranging from gathering
> status, and operating the machine, to system configuration.
>
[ . . . much omitted . . . ]
>
> A PC program should then be able to generate a password to match any given
> username, and limitations, and access level, and keep track of the issued
> passwords.
>
> Questions
> I this the way to go ? I guess others have solved the same kind of problem.
> What kind of algorithms can be used in this application ?
> Is there any commercial products ? Freeware pieces of C code etc. ?
>
> What worries me is how keys is distributed, is it always possible to
> generate a password for a user with a given login name, limitations, and
> access level ?
At the risk of sounding discouraging, I strongly advise you
to begin by thinking through (and writing down) your requirements:
what capabilities you want, and what resources are available, but
*not* how the system will be implemented. How many users? How flexible
a structure of privileges? Do you have local, nonvolatile storage?
If everybody forgets his password, do you have to send the machine
back to the factory?
If you don't have a clear description of what you want, the
probability that you will get it is very small.
- Peter
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 01:04:11 GMT
On Thu, 20 Jan 2000 14:39:49 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>The point worthy to be repeated is that one need not keep a strict
>distinction between stream and block ciphers, i.e. there is no sharp
>boundary between these...
I claim there *is* a useful distinction between a cipher which can
work on the minimum possible amount of information -- a bit -- and one
which inherently requires multiple bits before it can start to
operate. Moreover, the distinction helps clarify various
characteristics of cipher operation.
The alternative is to say that stream and block ciphers are the same.
Indeed, we might as well say "all ciphering is substitution" and leave
it at that. But these claims are singularly unhelpful in providing
insight to cipher design.
Now, most real stream ciphers do in fact work on tiny byte-size
"blocks," and most block ciphers are in fact operated as stream
meta-ciphers. Thus, real use tends to blur a distinction which is
both clear and important for analytic purposes: A block cipher will
have data diffusion across the entire fundamental block, even from
latest data to "earlier" ciphertext within the block, and that will
not happen in a stream cipher. The distinction is thus measurable and
not just academic. It is just as useful to see a block cipher as a
huge keyed substitution, which has diffusion as a consequence. The
block width thus limits both the number of possible keys and code
values, and establishes a direct correspondence both to Simple
Substitution and classic codes.
Shall we see a stream cipher as a block cipher with a 1-bit-width
block? I don't think so: I don't see much diffusion there. The
reductio ad absurdum argument fails specifically because the useful
distinction first appears when we have a block whose size is larger
than one element.
Of course if you are designing a cipher, you can call it anything you
want. Others may then choose to interpret the design in ways which
facilitate an understanding of its operation, and which groups the
design with ciphers having similar characteristics. See, for example:
http://www.io.com/~ritter/GLOSSARY.HTM#CipherTaxonomy
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
