Cryptography-Digest Digest #747, Volume #11 Wed, 10 May 00 07:13:00 EDT
Contents:
Re: Q: Searching for authentication protocols (=?iso-8859-1?Q?Tom=B4s?= Perlines
Hormann)
TLAs (was: Re: Tempest Attacks with EMF Radiation) (Jonathan Thornburg)
Re: Scary Possibility: Ticklish Chips (Jonathan Thornburg)
Re: Prime Generation in C,C++ or Java ("User923005")
Re: An argument for multiple AES winners ("Sam Simpson")
Re: Why no civilian GPS anti-spoofing? / proposal (Jonathan Thornburg)
Open source cryptography library: BeeCrypt (Bob Deblier)
Re: F function. (Mark Wooding)
Re: Some pencil and paper cyphers (Roger Fleming)
Re: Why no civilian GPS anti-spoofing? / proposal (Thomas Schmidt)
Re: More on Pi and randomness (Tim Tyler)
----------------------------------------------------------------------------
From: =?iso-8859-1?Q?Tom=B4s?= Perlines Hormann <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Q: Searching for authentication protocols
Date: Wed, 10 May 2000 10:26:35 +0200
> Strong password authentication protocols like SRP and SPEKE also exchange
> a symmetric session key as a byproduct of successful authentication.
> You can use this key to provide session integrity and confidentiality.
I have printed out your papers about it, and will read through them
carefully.
BTW: can you tell me who is succesfully applying your protocol? Has it
been (crypto-)analysed from third parties???
Do you know an evaluation vs. other well-known protocols?
Thanks for you informations...
> --
> Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
> E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
> Phone: (650) 723-1565 exchange for security deserve neither."
> http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
--
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] (Jonathan Thornburg)
Subject: TLAs (was: Re: Tempest Attacks with EMF Radiation)
Date: 10 May 2000 10:58:28 +0200
In article <8f0pl8$[EMAIL PROTECTED]>,
Guy Macon <[EMAIL PROTECTED]> wrote:
>What really ticks me off is Asynch Transfer mode. Uh, fellows, the
>acronym "ATM" is already taken...
Only in some parts of the world. The thing you put a bank card into
to get money, which is an "ATM" (Automatic Teller Machine) in Canada
and the USA, is a "bankomat" in Europe.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Seen on usenet:
Q: "If we're not supposed to eat animals, why are they made of meat?"
A: "If we're not supposed to eat people, why are they made of meat?"
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Scary Possibility: Ticklish Chips
Date: 10 May 2000 11:02:49 +0200
zapzing wrote:
> Here's something to keep you awake at night:
> What if some of the chips for doing DES etc. have
> been made "ticklish" , that is what if some
> sort of irritant, such as a dose of radiation
> or an electrical input that is out of band
> would prompt the chip to divulge its key.
In article <[EMAIL PROTECTED]>,
Volker Hetzer <[EMAIL PROTECTED]> wrote:
> Much easier. You design a chip. You give
> the design to a company for manufacturing.
> Manufacturer has connections to government
> and - your chip has an undocumented debug
> feature triggered by a certain combination on
> your 100+ pins or a specific fluctuation in the
> power supply.
More generally, anyone along the way can introduce hardware backdoors,
just as anyone along the software path can introduce software backdoors.
The following (very funny) posting by Henry Spencer to the Linux-IPSEC
mailing list from about 6 months ago makes this point quite well:
## http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
_________________________________________________________________
Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
_________________________________________________________________
* To: Linux IPsec <[EMAIL PROTECTED]>
* Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
protected 100Mbit Ethernet
* From: Henry Spencer <[EMAIL PROTECTED]>
* From: [EMAIL PROTECTED]
* Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
* In-Reply-To: <[EMAIL PROTECTED]>
* Reply-To: [EMAIL PROTECTED]
* Sender: [EMAIL PROTECTED]
_________________________________________________________________
William H Geiger writes:
> I don't know if you still follow the CP list but we have
> been having a long debate on the trustworthiness of Intel
> hardware, especially their RNG...
At first I thought this was pretty much a non-issue here. The problem
with the RNG is that it's so hard to decide whether its output is "really"
random. But 3DES is a deterministic transform which can be tested against
other implementations, so you can easily establish whether the chip is
really doing 3DES or not.
Alas, then I got to thinking. Suppose one built a 3DES accelerator chip
so that, if and only if:
(a) the chip is doing near-continuous encryptions at high speed, and
(b) the keys are changing every packet or two, and
(c) the chip detects -- via a simple mechanism like a little hash table --
a key which has appeared before, recently, and
(d) this key has not been marked "compromised" in the hash table, and
(e) an internal 16-bit packet counter is all-1s,
then
(!) mark the key compromised in the hash table, XOR the key with the
string "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!", prefix it with a
random-looking constant bit pattern, and sprinkle the resulting bits into
the encrypted data, in a haphazard but deterministic pattern.
This is, of course, an encryption error. But rules (a)-(e) make it
essentially irreproducible, so it won't happen a second time (and will be
quite difficult to reproduce even in a test setup). Almost certainly it
will get written off as a random error, and the affected packet will be
re-processed correctly and re-sent, and all will be well.
Except that an eavesdropper on the high-speed wire just looks for the
constant bit pattern in the right places in a packet, and (almost) every
time he sees it, he's nabbed an encryption key.
There's no limit to the complexity that can be added -- especially if
you're willing to consider active wiretapping, with the chip going into
this mode only if it sees (say) an ICMP ping with the right data in it --
to defeat attempts to find this sort of thing on the test bench.
I fear I agree with William; nothing short of peer review of the hardware
design makes such a device trustworthy.
Henry Spencer
[EMAIL PROTECTED]
([EMAIL PROTECTED])
-
This is the [EMAIL PROTECTED] mailing list. It is a
restrict-Post filtered version of [EMAIL PROTECTED]
_________________________________________________________________
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Amount of all stock owned by the least wealthy 90% of America: 18%
Amount of all stock owned by the most wealthy 1% of America: 41%
-- Economic Policy Institute
------------------------------
From: "User923005" <[EMAIL PROTECTED]>
Subject: Re: Prime Generation in C,C++ or Java
Date: Wed, 10 May 2000 02:23:19 -0700
Brian McKeever <[EMAIL PROTECTED]> wrote in message
news:8faef0$mms$[EMAIL PROTECTED]...
> Lewis-Oakes <[EMAIL PROTECTED]> wrote in message
> news:8f6s6l$cbi$[EMAIL PROTECTED]...
> > Is there a quick and relatively short algorithm in any of these
languages
> > for generating primes? The primes do not have to be huge, to the order
of
> 5
> > to ten digits in decimal.
> > Thanks
> > Justin Lewis-Oakes
>
> For the Java, see the class java.math.BigInteger. One of the constructors
> creates probable primes of any specified length.
I'm curious as to how long it takes this class to create ten digits worth of
primes.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Date: Wed, 10 May 2000 10:28:22 +0100
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> David Eppstein wrote:
>
> > "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > > > Also, Hitachi has written to NIST claiming that they have
patent
> > > > coverage on ideas implemented in all 5 AES candidates apart
from
> > > > Rijndael....
> >
> > > Q: Is this new information since the AES3 conference? That is,
has Hitachi
> > > given more information since then?
> >
> > Yes. See
> >
http://csrc.nist.gov/encryption/aes/round2/comments/20000410-sharano.
pdf
> > for Hitachi's letter to NIST, and
> > http://patent.womplex.ibm.com/details?&pn=US04982429__ and
> > http://patent.womplex.ibm.com/details?&pn=US05103479__
> > for the actual patents.
>
> That means that the AES winner is very likely to have patent
problems,
> analogous to a new born with some genetical weakness.
Rijndael isn't covered by this claim.
Besides, SHA-1 is (allegedly...) covered by the same two Hitachi
patents...NIST clearly doesn't have a problem promoting algorithms
that alledgly infringe on these "dubious" patent claims. I'd expect
that NIST has looked at prior art and realised these claims are
baseless?
> I am personally
> very much surprised by this fact. (I have been too lazy to scan
through
> materials on the NIST page about AES, excepting those directly
> describing the various algorithms. On the other hand, I have
subscribed
> to 4 mailing lists pertaining to crypto, with one specific about
AES. Yet
> I have never got any informations of the sort above before.)
<SNIP>
Regards,
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Crossposted-To: sci.geo.satellite-nav
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: 10 May 2000 11:27:53 +0200
In article <8f35o6$o7i$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
>This actually scares me, now that a multi-carrier civilian system (L5
>etc.) has been announced, and airliner navigation will depend on it.
>One can imagine a terrorist action sending slightly spoofed GPS
>signals that cause two planes to crash into each other. It could be
>done by an unmanned transmitter near an airport. If it was only active
>for a few minutes and then permanently shut down, chances are that nobody
>would ever figure out what had happened.
Yup. This is one of a number of reasons why GPS isn't 100% reliable
(more precisely, why it doesn't meet the aviation industry's reliability
standard of < 1e-9 undetected failures per hour), and (thus) why it won't
be ready for use as a _primary_ navigation source for aircraft any time
soon.
I have a pdf file of
Johns Hopkins University Applied Physics Laboratory
Report VS-99-007, January 1999, MBA01, Revised
"GPS Risk Assessment Study Final Report"
done by JHU/APL under contract from the US FAA. I must have fetched
this somewhere on the web, but I'm afraid I can't find the URL. :( :(
At any rate, this study discusses the risks of jamming/spoofing in some
detail.
There are also risks from "friendly" jamming/spoofing: the US military
sometimes conducts GPS jamming/spoofing exercises, and historically they've
sometimes "forgotten" to notify civilian users: In article
<[EMAIL PROTECTED]> (sci.geo.satellite-nav, sci.space.policy;
13 March 1999), Allen Thomson <[EMAIL PROTECTED]> wrote
> Jamming of GPS Is Opposed
> Coast Guard Worried Pentagon May Affect Navigation
> By Bradley Graham
> Washington Post Staff Writer
> Saturday, March 13, 1999; Page A02
> [EXCERPTS]
>
> In a case of clashing military and civilian interests, the U.S. Coast
> Guard has told the Pentagon not to expect approval of any more training
> exercises in U.S. waters that involve the muddling of satellite
> navigational signals.
>
> Coast Guard authorities say they are worried that the military's periodic
> jamming of the Global Positioning System (GPS) could interfere with the
> Coast Guard's requirement to provide reliable navigational assistance to
> civilian ships that have come to rely solely on GPS.
>
> [deletia]
>
> Asked yesterday about the Coast Guard action, Pentagon spokesmen said the
> matter is under review. In view of the conflict, Langhorne Bond, a former
> head of the FAA, wrote Defense Secretary William S. Cohen and
> Transportation Secretary Rodney E. Slater this week urging a reassessment
> of government plans to phase out ground-based navigational aids and allow
> civilian planes and ships to navigate solely by satellite systems.
>
> "Both the Coast Guard and the Pentagon have reasonable concerns," Bond
> said yesterday. "It's the policy that allows civilian users to switch to
> GPS-only that's at fault and needs to be reconsidered."
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Seen on usenet:
Q: "If we're not supposed to eat animals, why are they made of meat?"
A: "If we're not supposed to eat people, why are they made of meat?"
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Open source cryptography library: BeeCrypt
Date: Wed, 10 May 2000 11:34:04 +0200
Hi all!
A couple of days ago my company erroneously posted a press release to
this newsgroup. It was intended that when I got back from my short
break, I would make the following announcement:
My employer, Virtual Unlimited B.V., has graciously given permission to
release the cryptography library I have developed as open source under
the GNU Lesser General Public License. Virtual Unlimited feels that it
is essential that the cryptographic routines used by our products be
open for inspection, and that strong cryptography should be available to
everyone for protecting your privacy.
The purpose of the library is not to solve one specific problem, like
file encryption, but instead to offer a toolkit which can be used both
by open source projects and commercial applications - provided they
respect the LGPL license agreement. As far as we know there are no
patent or royalty issues involved in the use of this library.
The BeeCrypt library, which is an ongoing project, contains primitives
for:
- entropy sources for initializing pseudo-random generators
- pseudo-random generators: FIPS-186, Mersenne Twister
- block ciphers: Blowfish
- hash functions: SHA-1
- keyed hash functions: SHA-1/HMAC
- multi-precision integer library, with assembler-optimized
routines
- probabilistic primality testing, with optimized small prime
trial division
- discrete logarithm parameter generation over a prime field
- Diffie-Hellman key agreement
- ElGamal signature scheme (two variants)
In the coming weeks and months I will continue to work on expanding the
number of algorithms, optimizing of core routines such as hash functions
and block ciphers. In addition, supporting elliptic curves is high on
the priority list, as is comformance to the draft IEEE P1363 standard.
Since the library is used by our own products, expanding the library
also means adding features to that software (e.g. adding blockciphers,
expanding the library to use a hardware cryptographic accelerator).
At the time of posting, the library has been tested to run under
Linux/glibc2.1 (x86) and Solaris 2.x (sparc and x86). Assembler
optimizations are available for x86 and ultrasparc. Several more
platforms are planned for the near future, but porting should be easy
enough to any UN*X-like platform, provided you have an ANSI compatible C
compiler which supports 64 bit integers.
The library can be found at http://beecrypt.virtualunlimited.com/ on a
webserver with bandwidth provided by UUnet Netherlands. An anonymous CVS
server will be set up in the near future. Should you be interested in
providing a mirror page for download of this library, please contact me
at [EMAIL PROTECTED], or on the address below.
If you have benchmark results, please share them with me. I'm sure that
there's plenty of tweaking I can do to make the library faster, but as
it is, it's pretty fast. I know that for modular exponentiation my code
is several times faster than a commercial product we once planned on
using. Primality testing is also a lot faster than what is available in
Java.
If you wish to assist in porting the library to platforms as yet
unavailable, I will be glad to offer any assistance I can.
Contributions, remarks and requests are more than welcome.
Sincerely,
Bob Deblier
Virtual Unlimited B.V.
web : www.virtualunlimited.com
email: [EMAIL PROTECTED]
phone: +31 40 2558039
fax : +31 40 2558031
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: F function.
Date: 10 May 2000 10:00:24 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> BTW how are you messuring the diff probs?
Given the table s(x), I iterated over all inputs x and (nonzero) input
differences delta, and built a frequency table d_{i,j} which represented
the number of inputs x such that s(x) (+) s(x (+) i) = j. I then chose
the maximum final value of any of the d_{i,j}.
That was the intention, anyway.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: Some pencil and paper cyphers
Date: Wed, 10 May 2000 09:11:07 GMT
"Mr. Tines" <[EMAIL PROTECTED]> wrote:
>These are of course completely un-analysed; but are the results of
>musings following on after reading _Cryptonomicon_, and the manual
>stream cipher that discusses. I've not done exhaustive searches to find
>if these are at all novel.
>
>Base-26 ARCFOUR - where all the 0-255 iterations become 0-25, and mod26
>replaces mod256. [...]
>Like the stream cipher generated by the Solitaire cipher, this keystream
>would be added to encrypt and subtracted to decrypt rather than simple
>XORed.
>
>Iterated Playfair with diffusion. [...]
Obviously great minds think alike because _both_ these methods were suggested
during the last great pencil and paper thread, about 2 years ago. With
human operated ARCFOUR-26, I would suggest using the first few outputs (or
some other method) to shuffle a 26 x 26 Vigenere table, and use that for the
combining operation instead of modular addition or xor. Not only is it much
stronger, but for humans it is also faster and less error prone (if you rule
your table up neatly when you've shuffled it!!).
The iterated Playfair idea I analysed in some detail. In particular, I
actually calculated the work factor (in human seconds) to acheive a given
level of diffusion from various n character polygrammatic substitutions.
Digrams - as in Playfair - turned out to be the most efficient, as well as
the easiest to key up and most secure (the only >3-gram substitutions I found
to be practical were Hill ciphers, which are linear). I wanted to diffuse over
a 32 character block so that the entropy within each block (~= 1.6 x 32 = 51.2
bits) would be enough to eliminate the risk of repeated blocks. If the
permutation is efficiently designed, the number of letters to which a change
diffuses in each round doubles, so we get full avalanche in 5 rounds. Alas!! I
can tell you from experience that a 5 round iterated Playfair over a 32 letter
block is far too much work, and far too error prone, for a human.
speaking only for myself
------------------------------
From: Thomas Schmidt <[EMAIL PROTECTED]>
Crossposted-To: sci.geo.satellite-nav
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: Wed, 10 May 2000 12:16:19 +0200
Jonathan Thornburg wrote:
...
> I have a pdf file of
> Johns Hopkins University Applied Physics Laboratory
> Report VS-99-007, January 1999, MBA01, Revised
> "GPS Risk Assessment Study Final Report"
> done by JHU/APL under contract from the US FAA. I must have fetched
> this somewhere on the web, but I'm afraid I can't find the URL. :( :(
> At any rate, this study discusses the risks of jamming/spoofing in some
> detail.
...
See
http://gps.faa.gov/Library/Documents/documents.htm
--
-------------------------------------------------------------------
Thomas Schmidt e-mail: [EMAIL PROTECTED]
------------------------------
Crossposted-To: sci.math
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: More on Pi and randomness
Reply-To: [EMAIL PROTECTED]
Date: Wed, 10 May 2000 10:35:32 GMT
In sci.crypt JCA <[EMAIL PROTECTED]> wrote:
: If I tell you the decimal in position N in the expansion of Pi
: you won't be able to tell me anything about the following decimal
: sequence short of doing the computation yourself.
Even if you *don't* tell me N, it's still possible to make positive
statements about the sequence. This was discussed on the other thread:
according to mathmaticians, PI doesn't behave randomly.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
** 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
******************************
