Cryptography-Digest Digest #782, Volume #8 Mon, 21 Dec 98 13:13:02 EST
Contents:
Re: What is Randomness? (Dr. Yongge Wang)
md5 sample implementation
Re: Slow Key Scheduling (Mok-Kong Shen)
Re: break-even point n! vs Miller-Rabin ? (Leif Nilsen)
Re: biometrics (David A Molnar)
Re: Protocol flaw in widely-deployed access control software (Bryan G. Olson; CMSC
(G))
Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
Re: Computers getting faster? (Mok-Kong Shen)
Re: (fwd) Strike to protest Wassenaar! (Lutz Donnerhacke)
Re: On living with the 56-bit key length restriction (Matthias Bruestle)
Re: PGP Signature Hash, Algorithm & Key Size ([EMAIL PROTECTED])
Re: Cryptography board game! (was: CipherSaber for Dummies?) ("jay")
Hashing for randomness (Logi Ragnarsson)
Re: Protocol flaw in widely-deployed access control software (Michael Sierchio)
For Sale : Computer and Cryptology Books FS ([EMAIL PROTECTED])
Re: DIRT ? (NUTSA)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dr. Yongge Wang)
Subject: Re: What is Randomness?
Date: 21 Dec 1998 04:42:09 GMT
Indeed, for the randomness you may go to
Martin-Loef's definition of randomness.
(Chaitin has an equivalent difinition)
but all these definitions are for infinite sequences.
For finite sequence, Kolmogorov complexity
(or Chaitin) complexity may be a good way
to define randomness....
Andrew Wall ([EMAIL PROTECTED]) wrote:
: Bill,
: Can you tell me more about auto correlation?
: I have tried using an FFT on random numbers and I get a plot which has all
:frequencies present, looking a lot like the input, but
: shouldn't all frequencies be present more or less evenly?
: I have also thought that an FFT may not be that much use (eg I used a 1024 point
:FFT) as you should need to examine a very large
: amount of data (several megabytes?) at one time to ensure that any non-random
:looking parts are just a fluke and equally likely as
: any other sequence to arise.
: Andrew
: Bill Thomas wrote in message <[EMAIL PROTECTED]>...
: >a uniform random number generator can be tested by auto correlation, and then
: >by a spectrum - its white noise i.e., equal energy at all frequencies. The
: >repeat of the sequence is governed by
: >the pn generator used to produce the uniform random numbers. pn generators
: >can be made to
: >any length. where the sequence starts is set by the initial value (seed) in
: >the pn generator.
: >
--
======================================================.
Yongge Wang | |
Dept. of EE & CS | |
Univ. of Wisconsin--Milwaukee | |
P.O.Box 784 |Yongge Wang |
Milwaukee, WI 53201 |2545 N.Frederick Ave. |
|Apt. 104 |
Tel: (414)229-5731 |Milwaukee, WI 53211 |
Fax: (414)229-2769 | |
[EMAIL PROTECTED] |Tel: (414)3324794 |
http://www.cs.uwm.edu/~wang |Fax: (414)3324794 |
======================================================'
------------------------------
From: <[EMAIL PROTECTED]>
Subject: md5 sample implementation
Date: Mon, 21 Dec 1998 11:06:29 +0200
Hi all,
I want to find out a -very_clear- md5 implementation. I know RSA's
reference implementation, GNU fileutils' md5 implementation and that of
SSLeay but they are optimized for performance. Any of you know a more
clear implementation for presentation purposes?
Regards,
- burak
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Slow Key Scheduling
Date: Mon, 21 Dec 1998 08:59:12 +0100
Bruce Schneier wrote:
>
> On 19 Dec 98 17:25:14 GMT, [EMAIL PROTECTED] () wrote:
>
> >Bruce Schneier ([EMAIL PROTECTED]) wrote:
> >: All a slow key schedule does is make brute force searches that much
> >: harder. It helps DES just as much as any other algorithm in that
> >: respect.
> >
> >Yes, but only up to a point. If DES with independent subkeys is subject to
> >an attack with complexity 2^65, then, if you use a slow key schedule to
> >improve DES with a 56-bit key, you still can't make it _stronger than with
> >independent subkeys_. Hence, only slowing the key generation process by up
> >to 512 times (plus, of course, a correction for the difference in time
> >constants between trying a regular 56 bit key, and the steps in the 2^65
> >attack) is effective.
>
> Yes. Of course. The point of a slow key schedule is not to make a
> cipher stronger, but any given attack slower.
>
> Your math is correct.
>
> >On the other hand, a block cipher that is, with independent subkeys, so
> >strong that only brute-force attack is possible _on the independent
> >subkeys_, can be "improved" in security by a much greater amount by a slow
> >key schedule. (Of course, a slow key schedule doesn't really increase the
> >disparity between the time to encrypt and the time to crack, so one can
> >also argue that as soon as a slow key schedule becomes practical, it is
> >useless...)
>
> Yes. Of course.
The idea underlying my proposed WEAK3-EX is to ensure through
a sufficiently large number of rounds that brute force is the
only practically vaiable means of attack and (then) simultaneously
increase the initialization time to an amount to defeat brute
force. If efficiency is not a major issue, which can be the case
e.g. when private persons have to communicate confidentially with
relatively short messages, increasing the number of rounds alone
(i.e. without the mechanism of initialization time), which of course
also results in immense increase in the time for brute force, is
sufficient, since the larger processing time of the user can be
justified by his emergency need when more efficient means is not
available. I am currently testing a modification of my WEAK2
based on this idea and expect to release it these days.
M. K. Shen
------------------------------
From: Leif Nilsen <[EMAIL PROTECTED]>
Subject: Re: break-even point n! vs Miller-Rabin ?
Date: Mon, 21 Dec 1998 08:45:52 +0100
David A Molnar wrote:
> Now have to go find a method for yielding guaranteed primes (although
> something tugs at me that such methods are likely to be very expensive, or
> not exist) and do the same thing, I guess. Back to the drawing board.
>
Why no go back to some of the work that has been done in this area. Maurer's
algorithm (See HAC) provides an effective method for generation of provable primes!
Leif N
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: biometrics
Date: 21 Dec 1998 07:58:29 GMT
Myself <[EMAIL PROTECTED]> wrote:
> Handy, and the menu system could even track eye movements, instead of
> requiring keypresses, to make selections. No more busted keys at the
> ATM (just spraypainted iris-cams). and a messy sneeze would be
> disastrous. How physically reliable and vandal-resistant are
> fingerprint readers?
am I the only one who would worry about pranksters putting something nasty
n the eyepieces ?
On a different note, what prevents me from setting up a fake ATM and
capturing your biometric data the same way I capture PIN numbers, then
using it elsewhere? Perhaps it won't be of much use with an ATM's iris
scanner, but what if I pop the lid off the ATM , cut the wire from the
scanner, and then hook it to my "handy bank of people" ? or if biometrics
are widespread, used as passphrases and such, and so I can go look for
easier targets ?
It is a neat idea, and it's no work to remember, but it sounds
fundamentally like a very long and complicated passphrase that can't ever
be changed.
-David
------------------------------
From: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G))
Subject: Re: Protocol flaw in widely-deployed access control software
Date: 21 Dec 1998 10:33:08 GMT
Michael Sierchio ([EMAIL PROTECTED]) wrote:
: Bryan Olson wrote:
: > Just by snooping an attacker won't get to choose the
: > message to be encrypted, so all he gets are known, not
: > chosen, pairs. He can generate as many of these as he
: > wants without snooping, just by knowing the public key.
: No - we are talking about known plaintext/ciphertext pairs
: in which the ciphertext is always generated with the private
: key. This doesn't support a chosen plaintext attack, but
: a dictionary of ciphertext encrypted with a user's and
: server's private keys and the corresponding plaintext may
: grow quite large.
I don't think you understood the point. The attacker can
generate as many known plaintext/ciphertext pairs as he
wants. If he chooses y and encrypts it with the public
key to get x, that's the same pair he would get by snooping
if the server chose x and the client responded with y.
Public key systems necessarily allow attackers unlimited
amounts of known plaintext.
--Bryan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Mon, 21 Dec 1998 14:15:45 +0100
[EMAIL PROTECTED] wrote:
> As I understand it, the restriction is on exporting software/hardware
> which uses something more powerful than 56 bit encryption. There is
> nothing to forbid messages encrypted in much more powerful algorithms
> from being exchanged across the borders. Wouldn't the answer be to
> quickly establish easily implementable standards such that independend
> implementations from whatever country could interoperate freely (ie A
> German implmentation in Germany could communicate freely with a US
> implementation here.
I know too little about hardware. But to get two compatible software
implementations is hardly any problem in the current state of the art
of high-level programming languages and software engineering.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Computers getting faster?
Date: Mon, 21 Dec 1998 14:27:56 +0100
John Savard wrote:
>
> While this discovery won't fundamentally tilt the balance between
> cryptography and cryptanalysis, the way a working _quantum_ computer
> would, it still would up the ante, requiring bigger and more
> complicated ciphers:
I use to think that a cipher that is designed to be inherently
variable and in particular can be arbitrarily scaled up by the user,
is a good response to this kind of future challenges.
M. K. Shen
======================================================
M. K. Shen, Postfach 340238, D-80099 Muenchen, Germany
+49 (89) 831939 (6:00 GMT)
[EMAIL PROTECTED]
http://www.stud.uni-muenchen.de/~mok-kong.shen/
(Last updated: 18th December 1998. Origin site of
WEAK3-EX -- A Layman's 56-bit Data Encryption Algorithm.
Containing 2 mathematical problems with rewards totalling US$500.)
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: (fwd) Strike to protest Wassenaar!
Date: 21 Dec 1998 12:54:48 GMT
* Mok-Kong Shen wrote:
>Lutz Donnerhacke wrote:
>> * Mok-Kong Shen wrote:
>> >Lutz Donnerhacke wrote:
>> >> Simple. Please do not fight those guys on our side.
>> >> No. I do not know who is where.
>> >
>> >So you don't know on which side you yourself are. That means
>> >the probability is 0.5 that you happen to be situated on the Wassenaar
>> >side and the probability is 0.5 that you are on the other side.
>> >Am I right?
>>
>> Yes. Consider it as 'incufficient input'. The real challenge is the national
>> law.
>
>Anyway what did you mean 'those guys on our side' when you don't
>know on which side you yourself are??
There are people protecting the basic human right to encrypt stronly. There
are people enforcing the export restrictions to some countries. There are
people acknowledging the right of the government to intercept and decrypt
messages.
Several of them belong to more than one group. And all of them had a very
good reason for doing so.
My position is clear. I do not accept any restriction on strong
cryptography. But I do accept the governmental right to fight criminals.
But I urge the police officers to use conventional observation if
wiretrapping fails due to encryption. I do not accept the development of
weaker cryptography to pass the not yet accepted export regulation in the
hope the guys at the other end knows how to reassable a stronger cipher from
the parts. I do not accept patented algorithms in order to restrict the
usage. I do not accept export restrictions at all. But I can laugh on export
restrictions on commercial cryptography.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: On living with the 56-bit key length restriction
Date: Mon, 21 Dec 1998 13:50:10 GMT
Mahlzeit
Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
> philosophy of my WEAK serious of products, is needed. (I am yet
> unaware of any previously known crypto designs incorporating almost
> ubiquitous 'variability' as is done in the WEAK series.) In my
An example for a scalable key setup is MDC from Peter Gutmann.
It allows to specify the number of iterations.
Another possibility is RC4. It is not designed to have a variable
key setup time, but it is suggested for enhanced security to
skip the first e.g. 256 random bytes created with it. This can
also be used to scale up the key setup time.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Mahlzeit sagte der Kanibale, als Zwiebie in ihrem Kessel vor sich hin
koechelte... "Na Mahlzeit!" murmelte auch der Medizinmann und wandte
sich mit Grauen ab....
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Signature Hash, Algorithm & Key Size
Date: Mon, 21 Dec 1998 12:22:33 GMT
In article <[EMAIL PROTECTED]>,
Nathan Kennedy <[EMAIL PROTECTED]> wrote:
> Tom McCune wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Since SHA1 and RIPEMD160 hashes can be used with RSA keys and
> > their standard (and official) sizes up to 2048 bits, does doing this
> > with the larger 2048 bit RSA key result in any greater signature
> > security than standard 1024 bit DSS keys with the SHA1 hash? Or
> > phrasing it differently: Does a signature using the SHA1 hash
> > with a 1024 bit RSA key, equal the security of a signature using SHA1
> > with a 1024 bit DSS key; and, is any greater security achieved by
> > using
> > a 2048 bit RSA key for the signature with an SHA1 (or RIPEMD160) hash?
> >
>
> You are correct--however I do not know the breakpoint. I believe GPG
> limits the signing keys to 1024 for this reason.
<SNIP>
PGP limits DSS keys to a maximum size of 1024-bits because thats the limit
imposed in FIPS-186. All other implementations of DSS also implement keys of
between 512 & 1024 bits.
Regards,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "jay" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Cryptography board game! (was: CipherSaber for Dummies?)
Date: 21 Dec 1998 15:19:38 GMT
Robert Munyer <[EMAIL PROTECTED]> wrote in article
<75liuo$shs$[EMAIL PROTECTED]>...
> CipherSaber, the board game!
>
> I wonder if Milton Bradley would be interested...
>
> You'll also need two other playing pieces, which can sit on a
> chessboard square along with a Scrabble chip and still not cover
> the labels. I think a little pewter rabbit and turtle, the size
> of monopoly game pieces, would be good.
> [etc...]
I love it!! The world's first Wassenaar listed board game!
Seriously, though, playing with this for a little while will do more for
intuitive understanding of RC4 and encryption in general than reading the
algorithm or using PGP.
jay
------------------------------
From: [EMAIL PROTECTED] (Logi Ragnarsson)
Subject: Hashing for randomness
Date: 21 Dec 1998 17:12:24 GMT
Hi!
I'm writing a cryptography library in java (www.hi.is/~logir/cryptonite
if you are interested) and have just written a random number generator
based on MD5. However, it is slightly different from the implementations
I have seen before, which, of course, makes me nervous.
My source of entropy is based on counting how many times a separate
thread goes through a loop in a given period. This should be worth a few
bits of entropy, but it is hard to tell. If it is dumped to file it is
non-compressable with gzip or zip, but then, so is the output of the
linear congruental PRNG in java.
Is there a better way to test the quality of the entropy source?
Now, when expanding this to a longer sequence I do the following:
Generate a seed s_{-1},s_0 of twice 512 bits from the entropy source.
Define s_{i+1} = f_i(s_i), where f_i is chosen randomly (using the
entropy source) from 2^16 different simple permutations.
(basically, f_i adds two random bytes to two of the bytes in the
array containing s_i. It loops through which bytes are modified)
The output of the generator is r_i = H(s_{-1}..s{i}), H is the MD5 hash
function without appending the length of the message.
Does this make sense? Pease rip it to pieces :)
TIA,
Logi
--
Logi Ragnarsson - [EMAIL PROTECTED] - Math and CS student at Univ. of Iceland
Some day we all shall be out of scope. (Beware the garbage collector.)
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Protocol flaw in widely-deployed access control software
Date: Mon, 21 Dec 1998 08:43:27 -0800
Reply-To: [EMAIL PROTECTED]
"Bryan G. Olson; CMSC (G)" wrote:
> I don't think you understood the point. The attacker can
> generate as many known plaintext/ciphertext pairs as he
> wants. If he chooses y and encrypts it with the public
> key to get x, that's the same pair he would get by snooping
> if the server chose x and the client responded with y.
I did understand the point, but was attempting to point out
the vulnerability to a *chosen* plaintext attack by server
spoofing, since the protocol authenticates the client first.
------------------------------
From: [EMAIL PROTECTED]
Subject: For Sale : Computer and Cryptology Books FS
Date: Mon, 21 Dec 1998 16:18:10 GMT
I am selling some computer books at an auction with less than 3 days left.
Computer books for sale:
Amazing 3D Games Adventure Set W/CD NO RESERVE
Mac and Power Mac SECRETS W/Floppies NO RESERVE
Photoshop Filter Finesse W/CDRom NO RESERVE
Fix Your Own Lan 2nd Edition NO RESERVE
Mathmatical Cryptology Hardcover Book NO RES
http://cgi3.ebay.com/aw-cgi/eBayISAPI.dll?ViewListedItems&userid=tralornik
Thanks
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (NUTSA)
Crossposted-To: alt.2600,alt.2600.hackerz,alt.hacker.learning
Subject: Re: DIRT ?
Date: Mon, 21 Dec 1998 16:44:39 GMT
On Sat, 19 Dec 1998 01:57:24 -0000, "donoli" <[EMAIL PROTECTED]>
wrote:
>
>[EMAIL PROTECTED] wrote in message
><75e00q$4lh$[EMAIL PROTECTED]>...
>>Anybody know how to tell if you have the "DIRT"
>>trojan installed on your PC. Also, what is the
>>best way to remove it?
>>
>Try the Dirt Devil. It worked for me. Donoli.
>
>
Now are you guys being facetious in your followups to this inquiry
about the D.I.R.T. program??? Is there a program called Dirt Devil
that will detect and remove this electronic surveillance crap??? This
has caused me some concern since I surfed over the home site of the
software company offering this to law enforcement agencies and the
military following a lead provided by a ZD net article about online
spy tools. The indications I got from the site was that something WAS
being installed on my box. For those who do not know D.I.R.T. is
similar to B.O. but a whole lot meaner and newer... Please Let me
know if you will if there IS a detecter and remover...
------------------------------
** 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
******************************
