Cryptography-Digest Digest #248, Volume #9 Thu, 18 Mar 99 13:13:04 EST
Contents:
Problems & failures of Centralised Key Distribution (sb5309)
Re: Random salt (Bryan Olson)
Re: Crypto transmission in noisy ambient (Bryan Olson)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Hash algorithm (getting better all the time0 ([EMAIL PROTECTED])
Re: Something, perhaps fun, to decrypt... Give it a try. (Erwin Bolwidt)
What is the MAC. ?? ("ZinHa")
Re: Hard problems? ([EMAIL PROTECTED])
Re: Quantum Computation and Cryptography ([EMAIL PROTECTED])
Re: How do you discover the order of a elliptic curve over Zp? ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (R. Knauer)
Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED (Mark Currie)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: DIE HARD and Crypto Grade RNGs. (Coen Visser)
Re: a5 ("Lassi Hippel�inen")
Re: Testing Algorithm (hash) (Jim Gillogly)
Re: a-8d~0.2844.5k:-89y ("hapticz")
----------------------------------------------------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Subject: Problems & failures of Centralised Key Distribution
Date: Thu, 18 Mar 1999 16:17:43 +0800
Reply-To: [EMAIL PROTECTED]
I have come across a statement which mentions the problems and failures
of centralised key distribution and the use of central server, before
the advent of the public-key cryptography.
Can anyone point me to where I can learn more about this ?
Thanks.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Random salt
Date: Thu, 18 Mar 1999 01:01:10 -0800
[EMAIL PROTECTED] wrote:
alex had written:
> > How to use random salt values when hashing password with SHA1?
> > For example, I want to generate random key and for this purpose hash
> > password with 64 bits of salt.
>
> The purpose of a salt is to thwart OTP attacks.
No, it's to thwart dictionary attacks; it avoids the "small codebook"
problem. The way "salt" is typically used, it does not need to be
random, only different every time.
--Bryan
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Crypto transmission in noisy ambient
Date: Thu, 18 Mar 1999 00:48:26 -0800
Chris Monico wrote:
> There's an _obvious_
> solution that I've mentioned several times, and has been thus far
> ignored (or at least, not addressed, or the postings got lost-I don't
> know):
> Construct a Goppa code that allows for enough random errors to
> be purposely induced (so as to foil syndrome decoding) and still has
> enough error correcting capability for the given channel. Then use a
> McEliece type cryptosystem with that code.
I think it's a poor solution. You end up with a McEliece system
with the limitation that you can't change nearly as many bits as
you would if using an error-free channel. Even if I were using
McEliece, I'd still solve the noisy channel problem with an
independent error-correction code. I want to choose my
cryptographic parameters based on the adversarial environment,
and my error-correction scheme based on the channel
characteristics.
This is a job for protocol layering. Use the appropriate
error-correction technique to build a reliable channel, then solve
the cryptographic problem assuming error-free transmission.
--Bryan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Thu, 18 Mar 1999 10:04:37 +0100
Christopher wrote:
>
> Second, does anyone know where I can find DIEHARD, I found a link the
> other day but it was broken. Thanks in advance.
According to my knowledge (about a year ago) the orginal software
of Diehard released by its designer was buggy (I did some test runs).
Someone else rewrote it in C, did some corrections and posted an URL
to this group. Later I found that that URL was no longer valid. I am
ignorant of whether the designer of Diehard has released a new
corrected version of his software. It would be of intest to know that.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Hash algorithm (getting better all the time0
Date: Thu, 18 Mar 1999 11:33:39 GMT
I performed more tests on TH1 and found that a) the source code doesn't follow
the pseudo code, and b)the plain text should have more effect on the output.
I plan to update TH1 to work on variable sized blocks instead of just one byte
at a time. What I plan to change is the D = ... in the inner loop.
I have updated TH1 so you can pick up a copy at my website. The testing on
32- bit registers is continuing as I type, however the 16-bit results look
promising 0.39% across the board. And if you use enough rounds it has no
linear-correlation between two messages.
It's at:
http://members.tripod.com/~tomstdenis/crypto.htm
The test data will be up soon (March 18th 1999).
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Erwin Bolwidt <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: Something, perhaps fun, to decrypt... Give it a try.
Date: Thu, 18 Mar 1999 12:41:23 +0100
The site is http://www.kipling.com/hacker/frame_hacker.html
Their idea is that you go to their shops to find the solution..
- Erwin
------------------------------
From: "ZinHa" <[EMAIL PROTECTED]>
Subject: What is the MAC. ??
Date: Thu, 18 Mar 1999 22:18:58 +0900
I read about "MAC"..
Of course, It does not mean "Mac PC" made by APPLE Co.
It called Multiplication..?????
I can't get any other informations about it.
Please let me know "MAC" include Web site possible.
Any help will be thanks. please.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Hard problems?
Date: 18 Mar 1999 15:06:44 +0100
> I've seen NP-complete problems, but what's an analogy which describes PSPACE,
> PSPACE-complete, or EXPTIME problems? Assume I know little to nothing about
> number theory, information theory or complexity theory, other than those
> terms.
The generic PSPACE-complete problem is satisfyability of quantified boolean
formulae.
Other exemples are:
- Given a directed graph with a starting point s, and the following game:
Two players move a pebble along the edges in turns, starting from s.
A player looses if she moves to a vertex already visited or cannot move.
Who wins the game?
- Who wins a given game of Go (japanese game). The size of the board and
the pebbles already present are variable in this problem.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computation and Cryptography
Date: 18 Mar 1999 14:56:12 +0100
> so, what's wrong with having three outputs and "throwing away" the
> output of the other two?
"Throwing away" is not a unitary operation.
Non unitary operations are possible (you can reset the
quantum computer), but the destroy the superposition
of quantum states which make the qc useful.
---
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How do you discover the order of a elliptic curve over Zp?
Date: Thu, 18 Mar 1999 15:02:29 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> jason main wrote:
> >
> > I need to find out the order of a general elliptic curve over the ints.
> > modulus a large prime. Any descriptions, or pointers to documentiation
> > would be helpful. I've heard that Shank's is used but all references that
> > I've tracked down say that this is a discrete log algorithm. If I had the
> > DL, I would not need the order, so I am confused. This is being used to
> > decrypt a el-gammal style protocall....
>
> Go to the IEEE P1363 web page and hunt around for the Annex.
See the following paper:
L. Dewaghe
Remarks on the Schoof-Elkies-Atkin Algorithm
Math. Comp. Vol 67, #223 Jul 98
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Thu, 18 Mar 1999 15:17:08 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 18 Mar 1999 09:51:01 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> Secondly, we *can* measure Kolmogorov complexity to arbitrary degrees
>> of precision for some types of strings.
>For trivial strings, like all 1's, I am very sure that one can.
>But we need a measure for practical sequences, for practical
>applications.
There is no direct measure of cryptographic strength for strings
themselves. You must characterize the process that generates the
strings, not characterize the output itself.
There is no such thing as a crypto random number per se, only a crypto
random process - and you cannot characterize the process by its output
since that would be begging the question. The best you can do is
perform diagnostic tests on the output which can be used as an alarm
that the random process might be malfunctioning.
Strictly speaking, if you find that the random process is not
malfunctioning, you cannot discard the string that generated the alarm
or the cryptanalyst could learn how you are discarding strings - and
that would introduce a weakness into the overall generation process.
Bob Knauer
"Every government always exercises the maximum amount of power its
rulers feel the people will stand for without revolting."
-- Alongside Night
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: The Magic Screw, Non-Secret Encryption, and the Latest WIRED
Date: 18 Mar 1999 16:30:23 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>Actually the public key system provides the key management for the
>secret key system, thereby, creating a hybrid system. That's what
>algorithms like Diffie-Hellman and KEA are specifically intended to
>do. There are better, more secure schemes also.
I assumed that the the original poster (John Savard), when he referred to a key
"generated and used via public key mechanisms", meant the use of something like
Diffie-Hellman. A mathematical discovery which invalidates the use of DH would
break a system which relies solely on DH for key establishment. I
understood John Savard to mean that you should combine this "dynamic" secret
key with more "static" ones already known by both communicators. In order to
have a secret key already known at two or more communicators, you would have to
maintain a secret key distribution scheme. In order to prevent reliance on
public key schemes entirely, you would have to maintain a traditional secret
key management scheme.
>Actually, they can't afford it in terms of cost, complexity, speed or
>security. In the Type 2 systems (FORTEZZA), they have even gone to
>decentralized public key management to reduce the burden. Remember
>that KEA is the Type 2 key management algorithm, declassified and made
>public last June by the big boys, purely for financial reasons.
If it is truely the case that the big boys cannot maintain a pure secret key
management system, then John Savard's original concerns may be valid. However,
I suspect that they have other mechanisms in place to avoid the sole reliance
on any one specific technique.
Mark Currie
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 18 Mar 1999 10:56:40 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>
>> That is *NOT* true, on at least two counts. First, if you have a
>> quantity that you can determine approximately, it needn't be
>> determinable to within an arbitrary degree of precision for
>> comparisons to be useful -- using a stopwatch, I can only measure
>> time to tenths of a second, and yet, it's still a useful instrument.
>>
>One always need a precision that corresponds to the application.
>If that precision can be attained in practice, then it is o.k.
>Otherwise it is not o.k.
>
>> Secondly, we *can* measure Kolmogorov complexity to arbitrary degrees
>> of precision for some types of strings.
>
>For trivial strings, like all 1's, I am very sure that one can.
>But we need a measure for practical sequences, for practical
>applications.
You're displaying an appalling ignorance of what can and cannot
be done w.r.t. the measuring of Kolmogorov compleixty. There's
a very good paper by Chris Hillman available on the Web, with the
title "All Entropies Agree For A Set" (to which I refer you).
I take the liberty of quoting :
"It is obviously very difficult to compute [the Kolmogorov
complexity of a string x] directly from the definition. Indeed,
the algorithmic complexity of a string is uncomputable in the
technical sense that there exists no algorithm which, when run with
any finite string s as input, is guaranteed to terminate in a
finite time with output Ku(s). However, this does not imply that
one can *never* [emphasis original] find exact values or even sharp
estimates of complexity."
He then goes on to discuss how, for instance, the K-complexity of
a typical string generated by a Bernoulli process agrees "pretty
nearly" (his words) with the Shannon-entropy of the source -- and
indeed with several other formalism of the "entropy" of a dynamic
system.
And, of course, these dynamic systems underly a hell of a lot of
cryptography -- the various approaches to "chaos-based encryption"
rely on dynamic systems theory. Closer to home, the Bernoulli
process is one of the characterizations of the ideal random number
generator. And so forth.
So, in direct response to your post -- we can, and do, accurately
measure Kolmogorov complexity for useful, practical sequences to
useful and practical degrees of precision and accuracy. The formal
uncomputability of K-complexity need not be any more of a barrier
to using it any more than our (equivalent) formal inability to
prove that a program terminates keeps us from writing and using
computer programs.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Coen Visser)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 18 Mar 1999 17:34:06 GMT
[EMAIL PROTECTED] (Patrick Juola) writes:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Patrick Juola) writes:
[...]
>>> Secondly, we *can* measure Kolmogorov complexity to arbitrary degrees
>>> of precision for some types of strings.
>>For trivial strings, like all 1's, I am very sure that one can.
Not for every 1-string. Consider 1^n (n repetitions of 1's) with
n incompressible.
>You're displaying an appalling ignorance of what can and cannot
^^^^^^^^^^^^^^^^^^^
Are you too stressed to be polite/reasonable?
>be done w.r.t. the measuring of Kolmogorov compleixty. There's
>a very good paper by Chris Hillman available on the Web, with the
>title "All Entropies Agree For A Set" (to which I refer you).
Could you give a URL/bibliographic reference?
>I take the liberty of quoting :
[ interesting statements edited ]
>So, in direct response to your post -- we can, and do, accurately
>measure Kolmogorov complexity for useful, practical sequences to
>useful and practical degrees of precision and accuracy. The formal
>uncomputability of K-complexity need not be any more of a barrier
>to using it any more than our (equivalent) formal inability to
>prove that a program terminates keeps us from writing and using
>computer programs.
You have to remember that the Kolmogorov complexitiy is often
defined +/- O(1). This constant can be very large, so how can you say
that you can approximate it to arbitrary precision?
Regards,
Coen Visser
------------------------------
From: "Lassi Hippel�inen" <[EMAIL PROTECTED]>
Subject: Re: a5
Date: Wed, 17 Mar 1999 16:44:26 +0200
http://jya.com/crack-a5.htm contains some interesting stuff and pointers.
-- Lassi
Andrew Haley wrote:
> Maciej Maciejonek ([EMAIL PROTECTED]) wrote:
> : Anybody knows any facts about cipher a5 (a3,a8).
>
> It's not a very good cipher.
>
> : I'm interested in algorithm of this cipher, becouse I'm considering
> : its implementation in hardware ( Altera environment )
>
> Search for the following news artile on http://www.dejanews.com
>
> From: [EMAIL PROTECTED] (Ross Anderson)
> Newsgroups: sci.crypt,alt.security,uk.telecom
> Subject: A5 (Was: HACKING DIGITAL PHONES)
> Date: 17 Jun 1994 13:43:28 GMT
>
> Andrew.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithm (hash)
Date: Thu, 18 Mar 1999 09:45:07 -0800
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> (About TH1)
> What other tests can I perform on my algorithm? And if possible how to
> implement them. I have performed entropy and linear tests, I believe it
> pasted both.
>
> It's at:
> http://members.tripod.com/~tomstdenis/crypto.htm
(URL corrected from "dens" to "denis".)
Your frequency tests don't match mine. I replaced the driver
part of th1.c as shown at the end of this msg, in order to run
a bunch of randomish 20-byte plaintexts through it. By the way,
strlen() will stop on a null byte, so your driver as it stands
won't hash general binary files. My modification outputs the
hashes of 2^20 20-byte plaintexts taken from /dev/urandom but
does not change the actual hash code.
On the first run I looked at frequencies of the bytes in the
2^20 hash outputs, and found at the low end:
60219 0.0036 10
60474 0.0036 20
60691 0.0036 08
60748 0.0036 21 !
61149 0.0036 41 A
61300 0.0037 40 @
That is, bytes with few 1-bits are under-represented. At
the high end:
71548 0.0043 fb
71740 0.0043 fc
72605 0.0043 fd
73025 0.0044 00
74218 0.0044 fe
79420 0.0047 ff
That is, bytes with a lot of 1-bits are over-represented, and so
is the null byte.
On ten more runs I did a frequency count just on bits, and got
the following:
# bytes # 1-bits # 0-bits
16777216 67860374 66357354
16777216 67857865 66359863
16777216 67853799 66363929
16777216 67862038 66355690
16777216 67849171 66368557
16777216 67851891 66365837
16777216 67849785 66367943
16777216 67859263 66358465
16777216 67865924 66351804
16777216 67842645 66375083
Unless I've done something wrong, it looks even worse than SHC2.
Here is the testing harness I used.
#define TESTING
/* test */
#include <stdio.h>
main()
{
char buf[150];
WORD i, key[8];
#ifdef TESTING
long foo;
int baz;
FILE *ranfile;
ranfile = fopen("/dev/urandom", "r");
if (ranfile == NULL) return;
for (foo = 0; foo < (1 << 20); foo++)
{
#endif
/* clear key */
memset(key, 0, sizeof(key));
/* hash all input */
#ifdef TESTING
for (baz = 0; baz < 20; baz++)
buf[baz] = getc(ranfile); /* Random 20-byte inputs to the function. */
sh(buf, 20, key);
for (i = 0; i < 8; i++)
printf("%c%c", key[7-i] & 0xff, (key[7-i] >> 8) & 0xff);
}
#else
while (fgets(buf, 150, stdin))
sh(buf, strlen(buf), key);
for (i = 0; i < 8; i++)
printf("%04x ", key[7 - i]);
#endif
--
Jim Gillogly
26 Rethe S.R. 1999, 17:02
12.19.6.0.11, 6 Chuen 4 Cumku, Second Lord of Night
------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Re: a-8d~0.2844.5k:-89y
Date: Thu, 18 Mar 1999 13:10:46 -0500
aSBzdGlsbCBkb24ndCBiZWxpZXZlIGl0IGlzIHBvc3NpYmxlIHRvIHdhbGsgb24gd2F0ZXIgb3Ig
YWxsIHRoZSBvdGhlciBidWxsc2h0LiAgICANCg0KLS0gDQpiZXN0IHJlZ2FyZHMNCmhhcHRpY3pA
ZW1haWwubXNuLmNvbQ0KDQoNCg==
------------------------------
** 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
******************************
