Cryptography-Digest Digest #673, Volume #9 Mon, 7 Jun 99 11:13:01 EDT
Contents:
Pseudo-random number generators Was: Re: rc4 vs. rand() (Herman Rubin)
Re: Key lengths vs cracking time ("Douglas A. Gwyn")
Re: Challenge to SCOTT19U.ZIP_GUY ("Oliver Wiedemann")
Re: Key lengths vs cracking time (Anonymous)
Re: rc4 vs. rand() (fungus)
Re: random numbers in ml ("Rick Braddam")
RSA Key relationships (Kai Buchholz-Stepputtis)
Re: Threatening SW ^besides^ Strong-Crypto (Rob Warnock)
Re: Micro-tutorial: one-time pads (OTPs) (Rob Warnock)
Simple Cipher (which is quite gross) ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Looking for a password encryption algorithm (Ari
=?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?=)
Re: random numbers in ml ("almis")
Re: RSA Key relationships (DJohn37050)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Pseudo-random number generators Was: Re: rc4 vs. rand()
Date: 6 Jun 1999 21:21:47 -0500
In article <[EMAIL PROTECTED]>,
Particle <[EMAIL PROTECTED]> wrote:
>I've implemented the RC4 algo, and would like
>to know what are it's advantages over plain rand()
>method... for example: in rc4 way I got:
>rc4init(key); // initializes the 8x8 box using key
>while((ch = fgetc(in)) != EOF)
> fputc((ch ^ rc4()) & 0xFF,out);
>// rc4() returns the next subsequent number
>how would this be different from say:
>srand(key); // init random number gen
>while((ch = fgetc(in)) != EOF)
> fputc((ch ^ rand()) & 0xFF,out);
>of course, without using the default rand() but some other
>*good* random number generator...
>wouldn't a random number generator make more sense since
>most good ones have been statistically analyzed, and generate
>statistically good random numbers, etc... ?
Pseudo-random number generators with small keys are highly
suspect. SOME statistical testing may have been done, but
for any such procedure, there is a test it will fail, and
some of the tests are quite complicated.
Procedures with short keys, like rand(), are unsuited for
complex simulation procedures, and probably not for such
things as cryptography.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Key lengths vs cracking time
Date: Mon, 07 Jun 1999 01:51:10 GMT
Jan Wessels wrote:
> Does anyone has some information relating to encryption algorithms
> and key length in relation to the time needed to break the encrypted
> data?
Yes: There is no simple relationship between these.
------------------------------
From: "Oliver Wiedemann" <[EMAIL PROTECTED]>
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 7 Jun 1999 03:09:26 GMT
David Scott wrote:
> >doEnce(p19 * a, un32 x)
> >
> ><snip - other variable declarations>
> >
> >Most people would assume that the pointer "a", points
> >to the beginning of an allocated block of memory. (there's
> >no comment to suggest otherwise)
> >
> >But if that were the case, ppo19 would be pointing to 2 bytes before
> >the allocated block - a serious programming error !.
>
> You are trying to strech a point. You know that in the method
> there is a rotation of the file so that space is added to the top and
> bottom of the virtual memory file so that the wrapping flows more
> smoothly. It was not hard to see where I allocated the file space
> so it could not have been to hard. Also since ppo19 = v-2 and v = a
> it is obvious that a is not the top of the memory segment or the
> program would not work.
Actually I think that Tim was right in saying it's a programming error. It
is correct that you leave some 'slack' when encoding and decoding the actual
files. However when you encrypt the 'keyraw.key' data or decrypt the
'keyenc.key' data, the arrays holding that data have no extra space at the
top or bottom. Let's have a look at the actual code in SCOTT19U.C:
remainder table definition:
p19 rt[T19BL], bt[T19BL], ft[T19BL];
in gettables() we find:
/* get file 'keyenc.key' */
if ((fpenc = fopen("keyenc.key", "rb")) == NULL) {
printf(" failure to open 'keyenc.key' file\n");
exit(1);
}
i = fread((char *) rt, 1, T19LL , fpenc);
if (i != T19LL) {
printf(" failure to read 'keyenc.key' file\n");
exit(1);
}
fclose(fpenc);
doDece(rt, (un32) T19LL );
definition of doDece():
void doDece(p19 * a, un32 x)
This means in 'doDece' the ppo19 pointer (ppo19 = v-2 and v = a
) might be used on an invalid memory location. I think similar may be true
in the 'doEnce' function, when encoding the keyraw file.
I'm not 100% sure if this is a bug or not, because I'm far from really
understanding the code - however it looks critical to me.
Best regards ... Oliver
------------------------------
Date: Mon, 7 Jun 1999 03:14:40 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Key lengths vs cracking time
On Sun, 06 Jun 1999 23:08:30 GMT [EMAIL PROTECTED] wrote:
>> Does anyone has some information relating to encryption algorithms
>and key
>> length in relation to the time needed to break the encrypted data?
>
Try http://surf.to/hookah/keystrength.htm
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: rc4 vs. rand()
Date: Mon, 07 Jun 1999 10:18:30 +0200
Particle wrote:
>
> I've implemented the RC4 algo...
> ...
> wouldn't a random number generator make more sense since
> most good ones have been statistically analyzed, and generate
> statistically good random numbers, etc... ?
>
You're treading a very thin line here. Most ciphers can be used
as random number generators (even DES) as well, but their properties
aren't necessarily perfect[*]. Wany "real" random number generators
OTOH have very good statistical output, but are useless for
cryptography (due to small keys, etc).
In real life the situation is usually a compromise. Random number
generators (eg. the BBS) which have both properties tend to be
complex and slow. The choice of algorithm should depend on the
task.
[*] With RC4, for example, the probability of two consecutive
output bytes being the same isn't exactly 1/256. When used as
a stream cipher this isn't a weakness but it would be bad in
a pure random number generator.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Mon, 7 Jun 1999 02:50:25 -0500
HackZoid of SideRs wrote in message
<[EMAIL PROTECTED]>...
>
>
>> I guess I must have been high. I meant the RCA1802
>> (The 6502 turned into the mess we call Pentium)
>> ...al
>
>No it didn't .... Z80 did ...
>
>MH
>
Not hardly. The Z80 was made by Zilog and was an improved
8080. The 8080 was made by Intel, and fathered the 8086. The
8086 was the first 16 bit chip from Intel and started the
80x86 line. If I remember correctly (and I don't always),
the 8088 used in the first IBM PC was actually introduced
after the 8086 to simplify board layout by use of an 8 bit
data bus. The grandfather of them all was the 4004 chip made
for a Japanese calculator manufacturer. It was "expanded" to
8 bits to become the 8008, which fathered the 8080.
See? It's nothing but a fancy calculator.
Rick
------------------------------
Date: Mon, 07 Jun 1999 10:21:29 +0200
From: Kai Buchholz-Stepputtis <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: RSA Key relationships
Hi,
Is there some good overview/article about relationships
between RSA key elements as e.g. d1=d2 AND e1=e2 => n1=n2
and so forth.
In addition about various key doublette (english synomym ?)
probabilities.
(Yes, I tried altavista, but I did not find very much.
Maybe, because I did not know the best keywords for it, sorry)
Thanks in advance,
Kai.
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Crossposted-To: comp.security.misc
Subject: Re: Threatening SW ^besides^ Strong-Crypto
Date: 7 Jun 1999 08:48:00 GMT
Geoffrey KEATING <[EMAIL PROTECTED]> wrote:
+---------------
| Well, you might look at the Wassenaar agreement lists. Apart from
| design software for weapons and suchlike, there is:
...
| - Apdative routing software in source
+---------------
By the way, in the past this has been held by ITAR to *include* such
standard widely/freely-available source as the standard Berkeley Unix
or Linux routing code -- in fact, *anything* that does RIP, OSPF, or
the like, and "adapts" to failed links or nodes.
[Note: There's a specific exemption for systems with only one LAN
interface that use RIP only to find their assigned router(s).]
-Rob
=====
Rob Warnock, 8L-855 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Micro-tutorial: one-time pads (OTPs)
Date: 7 Jun 1999 09:04:16 GMT
Sundial Services <[EMAIL PROTECTED]> wrote:
+---------------
| key distribution. OTPs require an endless supply of keys...
+---------------
Well, only as "endless" as the communications they protect. If you never
send more than a megabyte a day, then a single CD can contain enough OTP
to last for more than a year.
+---------------
| sender and receiver must have the current keys. It must be impossible
| for anyone to have a third copy or to intercept a copy of the pad.
+---------------
In his excellent novel "A Fire Upon The Deep", Vernor Vinge suggests
that one way of increasing the security of OTP key distribution is to
generate several *times* [he suggests "3"] the amount of key you really
need, and send each piece via a different route/medium/courier/whatever.
The actual OTP that's used between sender and receiver is then the XOR
of all of the pieces. That way, if one piece has been compromised, it
doesn't matter -- the enemy *still* can't decode the encrypted data
(unless *all* the pieces were intercepted & copied WITHOUT BEING DETECTED).
-Rob
=====
Rob Warnock, 8L-855 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: [EMAIL PROTECTED]
Subject: Simple Cipher (which is quite gross)
Date: Mon, 07 Jun 1999 09:51:45 GMT
In the spirit of using a lot of memory, I wrote a fairly simple 128 bit
cipher which uses a 64k 16-bit lookup table. The table is the only key
secret in the cipher. In the round function I used a 3-layer PHT to
perform a simple and cheap mixing operation, and the table provides for
the non-linear aspect of the cipher. The table is quite large at 128kb
making it not suitable for anything but desktop computers.
The cipher is so simple that I put both encryption and decryption
routines in the same function (to save more space). About 17
operations are required per byte in each block which makes it quite
efficient for software.
I was inspired by Scottu's really big s-box, however my cipher is
easier to understand, and implement. It doesn't require xMB of ram and
actually has comments. (So there!)
If you want to take a peak, it's at
http://people.goplay.com/tomstdenis/simple.c
I would question it's security, because well I am a nobody. I put the
default at 4 rounds which is because after 1 round I found that
flipping a single bit effects the entire output, and I took a
guestimate that no more then 8 rounds are required at all. four round
seems to good to be true (at 8 rounds about 25 operations per byte per
block are required).
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 7 Jun 1999 11:22:08 GMT
According to SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>:
> >He is just, darwinly, trying to remain alive, after all.
>
> Would it be to much to ask for a clear and accurate description of this
> last sentence?
Oops, sorry. Here is a description that fits your 'spelling standard':
he iz just darwilly tryng reman life after al.
See, I can make some effort. Your turn now.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Mon, 07 Jun 1999 09:38:33 GMT
<snip>
One thing that you missed is that RC4 is a RNG algorithm. It's
designed to be cryptographically secure which means it's unpredictable
to the left and right. It handles this by the 'XorIndex' calculation
which hides where the output actually came from. The swapping in RC4
is used to lengthen the output cycle.
I have heard things about short RC4 cycles, and some bad properties. I
would investigate them before using RC4 commercially. Better yet is to
use a block cipher in OFB mode.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Ari =?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?= <[EMAIL PROTECTED]>
Subject: Looking for a password encryption algorithm
Date: Mon, 07 Jun 1999 14:00:10 +0300
Hi
Simply, I'm looking for a reliable password encryption algorithm.
This is the situation: The passwords are to be stored in a database and
the client software will access the database via server programs.
Unfortunately the server programs are stateless, therefore a real
key-exchange type protocol cannot be implemented. The communications medium
cannot be considered secure, although non-authorized clients (or client
programs) are not a problem. The main issue is that the passwords are
stored plain-text (yeah, I know... :) and that should be changed. Any
ideas?
Unix-like crypt could be the solution, but since Unix is not involved in
any level, importing this mechanism to other platforms might not be a valid
solution.
One-way hash functions look like promising candidates, but which algorithm
to choose? Pros and cons required.
BTW, is there any papers or other discussion about password encryption in
general? I have found a lot of documents about the security of Unix crypt,
but hardly any about other methods.
Ari
--
*******************************************************
Ari V�h�-Erkkil� Consultant, Twin Systems Oy
Office: +358-(0)9-5840 4815 [EMAIL PROTECTED]
Mobile: +358-(0)40-586 6980 [EMAIL PROTECTED]
Fax : +358-(0)9-176 718
*** http://www.twin.fi/ *** http://www.iki.fi/vake/ ***
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Mon, 7 Jun 1999 07:30:34 -0500
Rick Braddam wrote in message <7jftk3$nd2$[EMAIL PROTECTED]>...
|Not hardly. The Z80 was made by Zilog and was an improved
|8080. The 8080 was made by Intel, and fathered the 8086. The
|8086 was the first 16 bit chip from Intel and started the
|80x86 line. If I remember correctly (and I don't always),
|the 8088 used in the first IBM PC was actually introduced
|after the 8086 to simplify board layout by use of an 8 bit
|data bus. The grandfather of them all was the 4004 chip made
|for a Japanese calculator manufacturer. It was "expanded" to
|8 bits to become the 8008, which fathered the 8080.
|
|See? It's nothing but a fancy calculator.
|
|Rick
|
|
I'm not sure... but i thought the 4004 was developed for
implementation on Singer sewing machines. ???
...al
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA Key relationships
Date: 7 Jun 1999 12:57:43 GMT
Look at IEEE P1363 for some info on RSA key gen.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Mon, 07 Jun 1999 14:28:29 GMT
In article <7jfd56$pv3$[EMAIL PROTECTED]>, "Oliver Wiedemann"
<[EMAIL PROTECTED]> wrote:
>David Scott wrote:
>
>> >doEnce(p19 * a, un32 x)
>> >
>> ><snip - other variable declarations>
>> >
>> >Most people would assume that the pointer "a", points
>> >to the beginning of an allocated block of memory. (there's
>> >no comment to suggest otherwise)
>> >
>> >But if that were the case, ppo19 would be pointing to 2 bytes before
>> >the allocated block - a serious programming error !.
>>
>> You are trying to strech a point. You know that in the method
>> there is a rotation of the file so that space is added to the top and
>> bottom of the virtual memory file so that the wrapping flows more
>> smoothly. It was not hard to see where I allocated the file space
>> so it could not have been to hard. Also since ppo19 = v-2 and v = a
>> it is obvious that a is not the top of the memory segment or the
>> program would not work.
>
>Actually I think that Tim was right in saying it's a programming error. It
>is correct that you leave some 'slack' when encoding and decoding the actual
>files. However when you encrypt the 'keyraw.key' data or decrypt the
>'keyenc.key' data, the arrays holding that data have no extra space at the
>top or bottom. Let's have a look at the actual code in SCOTT19U.C:
>
>remainder table definition:
> p19 rt[T19BL], bt[T19BL], ft[T19BL];
>
>in gettables() we find:
> /* get file 'keyenc.key' */
>
> if ((fpenc = fopen("keyenc.key", "rb")) == NULL) {
> printf(" failure to open 'keyenc.key' file\n");
> exit(1);
> }
> i = fread((char *) rt, 1, T19LL , fpenc);
> if (i != T19LL) {
> printf(" failure to read 'keyenc.key' file\n");
> exit(1);
> }
> fclose(fpenc);
> doDece(rt, (un32) T19LL );
>
>definition of doDece():
> void doDece(p19 * a, un32 x)
>
>
>This means in 'doDece' the ppo19 pointer (ppo19 = v-2 and v = a
>) might be used on an invalid memory location. I think similar may be true
>in the 'doEnce' function, when encoding the keyraw file.
>
>I'm not 100% sure if this is a bug or not, because I'm far from really
>understanding the code - however it looks critical to me.
I would say this is a "BUG" in the sense that it would make it hard to
compile on another machine. I checked scott16u which I have tested with
many more files has the exact same setup. You are correct in that when
one is building the table I am writting to 9 bits in front of the rt table and
this has undefined effects. The encrypting and decrypting does work it is
just that this is asking for trouble in that something in an area of memmory
unrelated to the rt could be modified with unforseen results.
the line:
p19 rt[T19BL], bt[T19BL], ft[T19BL];
should be replaced with the lines:
p19 rtW[T19BL+2], btW[T19BL+2], ftW[T19BL+2];
p19 *rt = rtW+1;
p19 *bt = btW+1;
p19 *ft = ftW+1;
The above should make it more clean.
I do like to skip some corners in coding but even
I have my limits. If one recompiles with the above
I think that for many of keys users on different machines
may have to use different programs. The reason that this
went undetected on the PC version was that the error
may not have caused a problem in how GNU C in my
machine laid memmory out. But I will change it. However
since after the "doDec.. is called in the porgram the
program that builds the tables to be used is called. In
this section it checks to see if a single cycle S-table is
built and it is. You can and I have decrypt and encrypt
many files. But one can not be sure that one is using
exactly the came S-table as one would use if program
was compiled using the fixes above.
This means the code for building the tables may really
be hardwired for the PC since who knows what those
bits are really used for. Yes Oliver I think you find what
we use to call on the Univac as a "feature" and I will
fix it. Yes it was not my intension to write out of the
rt area. So it is an error. But how many of you have written
a program this long with out a printer and not made any
errors.
>
>Best regards ... Oliver
>
>
Thanks Oliver
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
