Cryptography-Digest Digest #876, Volume #10 Mon, 10 Jan 00 11:13:01 EST
Contents:
Re: Is there a sci.crypt FAQ? (Volker Hetzer)
Re: Is there a sci.crypt FAQ? ("Dan Coyle")
Re: simple string encryption ("Derek Potter")
Simple Encryption ... ("Derek Potter")
Re: 8-round Blowfish (Keith A Monahan)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Re: Simple Encryption ... (Septyn)
Testvectors for testing =?iso-8859-1?Q?Schorr=B4s?= identification (Wolfram
=?iso-8859-1?Q?Kl=FCber?=)
Rijndael on the 8051? ([EMAIL PROTECTED])
Re: 8-round Blowfish (John Savard)
Re: Simple Encryption ... (Anton Stiglic)
Re: Little "o" in "Big-O" notation (Anton Stiglic)
Re: frequency analysis with homophones (Mok-Kong Shen)
Re: is signing a signature with RSA risky? (Anton Stiglic)
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) ("Tony T. Warnock")
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) ("Tony T. Warnock")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: modifiec game of life encryption, to be analyzed ([EMAIL PROTECTED])
Re: Intel 810 chipset Random Number Generator (Keith A Monahan)
Re: Intel 810 chipset Random Number Generator (David Wagner)
----------------------------------------------------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Is there a sci.crypt FAQ?
Date: Mon, 10 Jan 2000 12:40:00 +0000
[EMAIL PROTECTED] wrote:
>
> Hi
>
> Is there a FAQ for sci.crypt?
Yes. ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/cryptography-faq/
> I'm looking for a fairly technical introduction to
> hillclimbing/genetic algorithms useful in
> cryptanalysis.
You are unlikely to find anything there.
Encryption algorithms are designed not to be solveable that way.
(I.e. their solution space is supposed to consist of a plane
with a single raised dot in it.)
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Re: Is there a sci.crypt FAQ?
Date: Mon, 10 Jan 2000 06:41:17 -0600
<[EMAIL PROTECTED]> wrote in message
news:85celk$t0v$[EMAIL PROTECTED]...
> Hi
>
> Is there a FAQ for sci.crypt? I'm looking for a
> fairly technical introduction to
> hillclimbing/genetic algorithms useful in
> cryptanalysis. I have a Maths degree.
>
> Cheers
> Ben Pickering.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Here's one
http://www.faqs.org/faqs/cryptography-faq/
------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: simple string encryption
Date: Mon, 10 Jan 2000 09:52:25 -0000
"Paul Agics" <[EMAIL PROTECTED]> wrote in message
news:85a2if$hp1$[EMAIL PROTECTED]...
> Where can I get some simple string encryption examples?
http://www.derekpotter.freeserve.co.uk/freebies.htm#encoder
[Doesn't handle line breaks]
------------------------------
From: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Simple Encryption ...
Date: Mon, 10 Jan 2000 11:11:15 -0000
There are times when it would be cool (Ok, so
you now know this is going to be one of *those*
questions!) to be able to encrypt something not
so much to stop it being read by third parties
but to prove to the *recipient* that you have
some information but you aren't prepared to
divulge it *yet*. Like in a Usenet wrangle
where you both want to prove you know something
that the other claims you don't - but neither
wants to say the answer in case the other claims
they knew it all along. I guess we've all been
there.
So you need an encrytion scheme which can be
done both ways by hand - so that anyone watching
you can verify that you're being truthful, and
one in which it's impossible to create a key
from gibberish and arbitrary plaintext. Otherwise
you might just create a suitable key when your
opponent reveals his version of the answer.
I use a simple scheme where you:
1 Assign each character a numerical value (0-n)
REVEAL that map c <-> v
2 Choose two keys which are simple English sentences
Keep them secret for a while.
3 For each character in the plaintext, add its
numeric value to those of the corresponding
characters in the two keys. Use mod(n) rounding
and repeat the keys as necessary. Map the number
back to a character for a readable string.
Now that's all very simple and here's an example:
map: A=1 B=2 etc (A-Z only plus space, n=26)
plaintext: MARY HAD A LITTLE LAMB
key1: THERES A HOLE IN MY BUCKET
key2: JACK AND JILL WENT UP THE HILL
M -> 13
T -> 20
J -> 10
sum = 43
43 mod 26 = 17
17 -> Q
So the first character is Q.
The beauty of this
scheme is that it's easy to come up with the sum
of the two keys but very hard indeed to come
up with two matching "well known sayings" that
happen to work. Or is it?
I use two keys to stop people doing a scan for
common letter groups which just might reveal
enough of the key to guess the rest.
Any comments?
http://www.derekpotter.freeserve.co.uk/freebies.htm#encoder
Derek.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: 8-round Blowfish
Date: 10 Jan 2000 14:21:27 GMT
Someone will correct me if I'm wrong, but we really don't have any
metric that tells us one algorithm is stronger than another. Since we
have no way of proving an algorithm's security, we have no way of saying
that 3DES is any more(or less) secure than Blowfish.
Comparing key sizes won't really help make that determination between
different ciphers. A 128-bit key used with one cipher might be weaker
than a 64-bit key in another cipher.
Although this isn't necessarily conclusive, a lot of people use TIME as a
metric. The longer the algorithm has been around, the longer it's been
analyzed by cryptanalysts, the more resistive it will probably be to
known attacks. This says nothing of it's strength against unknown
attacks.
Of course, the cipher's author is important too. If I write a cipher
it will certainly be less secure(most likely) than say if Bruce S wrote
a cipher.
DES (not 3DES) has been around for a long time, been reviewed by many people
for a long time, including the NSA(which had hands in changing one of the
S-BOX entries before giving its approval). Now I'm not sure if it's safe
to EXTEND the security 'respect' of DES to 3DES.
Blowfish has been around not quite as long, (1994, right?) but it hasn't
had any successful attacks in the full-round version, to my knowledge.
It has gained more and more respect over the years and I feel it will
continue to do so.
Remember that although newer ciphers have been designed to withstand newer
cryptanalytic attacks, they don't have the advantage of being reviewed
in depth by everyone in the community.
I hope this helps,
Keith
Thierry FALISSARD ([EMAIL PROTECTED]) wrote:
: Bruce Schneier says in his famous Blowfish paper :
: "It is probably safe to reduce the number of iterations from 16 to 8 without
: compromising security. The number of iterations required for security
: may be dependent on the length of the key. Note that with the current
: subkey generation procedure, an 8-iteration algorithm cannot accept
: a key longer than 192 bits."
: May I infer from this that 8-round Blowfish (192-bit key) is at least
: as strong as triple-DES (168-bit key) ? (or even stronger)
: I know there were some attacks against 8-round Blowfish,
: in very particular cases though (I mean, not realistic cases).
: From what I could judge,16-round Blowfish is 2 or 2.5 faster
: than simple 56-bit 16-round DES. Well, this is fast, but not so
: fast in my opinion... 8-round Blowfish is a good compromise
: that could be preferred.
: Any opinion is welcome.
: @ < http://os390-mvs.hypermart.net >
: @ ("Is there life after MVS ?")
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Mon, 10 Jan 2000 15:35:53 +0100
John Savard wrote:
>
> However, it is possible, at least with a static Huffman code
> (actually, there is no reason why this wouldn't work as well for
> Adaptive Huffman compression), to represent the last symbol in a
> message with fewer bits. This has to do with the fact that the Huffman
> codes for symbols have the prefix property. The last symbol does not
> need to have this property, since it doesn't have to contain the
> information of how many bits it contains - the representation has to
> stop when the message itself runs out of bits.
But exactly here Scott would oppose. (In my understanding) for him
any (correct) compression has to terminate in certain 'normal' way.
Any 'abnormality' would mean some information exploitable by the
analyst. Perhaps there is indeed some value, if your discussions with
him could be carried to a proper end.
M. K. Shen
------------------------------
From: Septyn <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Mon, 10 Jan 2000 14:31:22 GMT
Derek Potter wrote:
>
> There are times when it would be cool (Ok, so
> you now know this is going to be one of *those*
> questions!) to be able to encrypt something not
> so much to stop it being read by third parties
> but to prove to the *recipient* that you have
> some information but you aren't prepared to
> divulge it *yet*. Like in a Usenet wrangle
> where you both want to prove you know something
> that the other claims you don't - but neither
> wants to say the answer in case the other claims
> they knew it all along. I guess we've all been
> there.
>
> Derek.
This sounds like an old trick (Renaissance?) people would do to prove
they have proven/discovered something without revealing what it was.
Before the full meat of the information was published, they'd write up a
short paragraph describing the important parts, then sort the individual
letters into alphabetical order and publish that (or mail it off to
whoever was doubting them, etc.) as evidence. Later, when the full
information was revealed, the alpha-sorted paragraph would be included
as a "signature".
Does anyone else know what I'm talking about here? I can't remember
where I read about this method of validation....
Sep
------------------------------
Date: Mon, 10 Jan 2000 15:46:18 +0100
From: Wolfram =?iso-8859-1?Q?Kl=FCber?=
Subject: Testvectors for testing =?iso-8859-1?Q?Schorr=B4s?= identification
Hello everyone,
for a hardware implemented version of the functions: a) x = �^ r
mod p and
b) y = ae + r mod q
wheras a, e have a length of 512 bit and r, q are 1024 bit
integer-words.
according t o Schnorr�s scheme, i�m looking for Test-Vectors, to test
the corrctness of my realisation.
Does anyone have a recommendation to approptiate literature or a link,
for solving my problem?
Thank you in advance for your invested time!
Wolfram
------------------------------
From: [EMAIL PROTECTED]
Subject: Rijndael on the 8051?
Date: Mon, 10 Jan 2000 14:42:44 GMT
Does anyone have an 8051 implementation of Rijndael they would like to
share? Even messy assembly code would be appreciated.
Thanks,
Dan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 8-round Blowfish
Date: Mon, 10 Jan 2000 14:31:22 GMT
On Mon, 10 Jan 2000 12:18:42 +0100, "Thierry FALISSARD"
<[EMAIL PROTECTED]> wrote:
>May I infer from this that 8-round Blowfish (192-bit key) is at least
>as strong as triple-DES (168-bit key) ? (or even stronger)
Well, that's hard to say. It could be that strong, since with
key-dependent S-boxes, it is not known how to usefully employ
differential cryptanalysis against it.
And because the procedure for creating the S-boxes is so extensive, it
does not seem that it can be attacked.
But one does not really know what new techniques the future holds. So
estimates of relative strength this precise are really not possible
for ciphers that are considerably different.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Mon, 10 Jan 2000 09:51:54 -0500
Derek Potter wrote:
> There are times when it would be cool (Ok, so
> you now know this is going to be one of *those*
> questions!) to be able to encrypt something not
> so much to stop it being read by third parties
> but to prove to the *recipient* that you have
> some information but you aren't prepared to
> divulge it *yet*. Like in a Usenet wrangle
> where you both want to prove you know something
> that the other claims you don't - but neither
> wants to say the answer in case the other claims
> they knew it all along. I guess we've all been
> there.
What you need is a Zero-Knowledge proof. There
exists alot of types, the way you develope it depends
on the task at hand. There is a ZK proof, for example,
to convince someone that you know the factors p, q,
of some integer n, without revealing any info on p or q.
A nice property of a ZK proofs is that if Peggie interacts
with Vicky so as to prooves proove in ZK that she knows
the answer to a certain problem P, Vicky can't use the
information of that conversation to proove to someone
else that she knows the answer to the problem.
So if you have a ZK proof for your problem at hand,
Alice could use it to proove to all the other Usenet
members that she knows what she claims she knows,
if Bob listens in, he will not learn anything that would
enable him to do the same thing, he would have to
execute a ZK proof that is independant to proove that
*he* also knows the answer.
Anton
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Little "o" in "Big-O" notation
Date: Mon, 10 Jan 2000 10:06:07 -0500
> >
> > He's got it exactly reversed -- it should be
> > f(x) = o(g(x)) iff f(x)/g(x) -> 0 as x->oo.
> > (The "little o" is to suggest that it grows
> > more slowly than g.)
And another way to define it (which might be more
practical for some types of proofs) is
f(x) = o(g(x)) iff
for any constant c > 0, there exists a constant n0 > 0
such that 0 <= f(n)/g(n) < c for all n >= n0.
just my my 0.02$
Anton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Mon, 10 Jan 2000 16:20:44 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > ... the 'statistical significance' of the sort that
> > you found is of such 'uncertainty' (on the scale of my personal
> > 'subjective' measure) that I wouldn't start put much energy
> > straightaway in following the direction 'indicated' by the computing
> > results.
>
> If the statistical analysis is performed correctly,
> the significance of the results should also be known.
Certainly I don't have full knowledge of the present case. What I
think could be problematical is the (probable) fact that the size of
the space of homophones relative to that of the plaintext alphabet
is here fairly large, so that one could make a number of different
assumptions about the mappings and obtain almost the same (presumed)
plaintext frequency distribution, so that there is not much to
decide which one of these candidates of mapping is the correct one,
unless one has additional informations. Further, the assumption of
the original poster that each plaintext character is mapped to J
(a constant) number of homophones is rather extraordinary in an
crypto context, I guess. (Certainly, nothing is absolutely
impossible.)
M. K. Shen
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: is signing a signature with RSA risky?
Date: Mon, 10 Jan 2000 10:18:30 -0500
==============E3491B91CEFF7B027C293225
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tim Tyler wrote:
> No. If you're using a signing method with a publicly available key, and
> you have the information that the message has been signed by a particular
> party (who has perhaps been identified by traffic analysis), then
> failure of signature verification allows you to systematically reject
> keys used in the main encryption, without performing any other sort of
> frequency analysis on the message at all.
>
> If the message's signature verification fails, you /know/ you are not
> using the correct key to decrypt (assuming the message is not corrupt).
O.k., I see. But then again, there are plenty of ways
for you to found out if you are decrypting with the
write key or not, simply by observing the message you
get when you decrypt, depending on the system, you will
probably be looking for something specific. One example
would be a specific header like "From: ". You can create
your own little algo that searches for this, if it's there
you accept, if it's not you reject. So I don't think that
a use of "encrypt then sign" could be justified for that
reason, "encrypt then sign" is a bad usage of crypto safe
crypto protocols.
Anton
==============E3491B91CEFF7B027C293225
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tim Tyler wrote:
<blockquote TYPE=CITE>No. If you're using a signing method with a
publicly available key, and
<br>you have the information that the message has been signed by a particular
<br>party (who has perhaps been identified by traffic analysis), then
<br>failure of signature verification allows you to systematically reject
<br>keys used in the main encryption, without performing any other sort
of
<br>frequency analysis on the message at all.
<p>If the message's signature verification fails, you /know/ you are not
<br>using the correct key to decrypt (assuming the message is not
corrupt).</blockquote>
<pre>O.k., I see. But then again, there are plenty of ways</pre>
<pre>for you to found out if you are decrypting with the</pre>
<pre>write key or not, simply by observing the message you</pre>
<pre>get when you decrypt, depending on the system, you will</pre>
<pre>probably be looking for something specific. One example</pre>
<pre>would be a specific header like "From: ". You can create</pre>
<pre>your own little algo that searches for this, if it's there</pre>
<pre>you accept, if it's not you reject. So I don't think that</pre>
<pre>a use of "encrypt then sign" could be justified for that</pre>
<pre>reason, "encrypt then sign" is a bad usage of crypto safe</pre>
<pre>crypto protocols.</pre>
<pre></pre>
<pre>Anton</pre>
<p> </html>
==============E3491B91CEFF7B027C293225==
------------------------------
Date: Mon, 10 Jan 2000 10:27:15 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> > Bradley Yearwood wrote:
> > > Whether the raw output from the hardware register is sufficiently
> > > unbiased and otherwise random for specific uses, this document does
> > > not say. They do recommend running e.g. FIPS 140-1 tests on the
> output
> > > after initialization.
> >
> > Actually they recommend running FIPS 140-1 or something similar as
> part of detecting whether the device is present.
>
> Apparently there is no reliable way of detecting the RNG.
> You read 1 bit from a pre-defined memory location to see
> it is there, and read from other locations to get the random
> data. You are on your own to figure out whether the data is
> really random enough that it is likely to be coming from
> the RNG.
>
> It warns about multi-threaded apps using the RNG, but
> nothing about different apps using the RNG. Apparently
> bad things can happen if 2 apps try to use it at once.
>
> This looks pretty brain-damaged to me.
This 'feature' isn't designed to be useful. It is designed to sell chips.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: Mon, 10 Jan 2000 08:23:58 -0700
Reply-To: [EMAIL PROTECTED]
Of course "syndrome" had changed in the last 50 years from sin-dro-me to
sin-drome.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: Mon, 10 Jan 2000 08:26:21 -0700
Reply-To: [EMAIL PROTECTED]
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony T.
>Warnock) wrote:
>
> >"unionize" is fun to give to automatic hyphenation routines.
>
> Here are two sentences to give to automatic language translators:
>
> Time flies like an arrow.
>
> Fruit flies like an orange.
"The spirit is willing but the flesh is weak."
------------------------------
Date: Mon, 10 Jan 2000 10:40:37 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Vernon Schryver wrote:
> In article <859sqo$5go$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
> > ...
> >Apparently there is no reliable way of detecting the RNG.
> >You read 1 bit from a pre-defined memory location to see
> >it is there, and read from other locations to get the random
> >data. You are on your own to figure out whether the data is
> >really random enough that it is likely to be coming from
> >the RNG.
> >
> >It warns about multi-threaded apps using the RNG, but
> >nothing about different apps using the RNG. Apparently
> >bad things can happen if 2 apps try to use it at once.
> >
> >This looks pretty brain-damaged to me.
>
> I wouldn't want to be misunderstood as defending what sounds like a weak
> design, but that criticism is wrong.
>
> As far as the hardware can tell, there is no consistent difference between
> a "multi-threaded app" and an operating system running "2 apps." There
> is no necessary difference as far as the CPUs, support chips, controllers,
> memory, buses, etc. are concerned, at least if you widen your definition
> from what some WIN32 application writers (but not Microsoft) or what some
> POSIX user code writers (but not competent UNIX kernel hacks) think is a
> thread. Anyone who doesn't see that without thinking about it shouldn't
> be writing code that might affect the state of any global hardware
> registers, including merely reading keyboard and timer chips.
All true. All irrelevant.
A trivial alternative to this design is one in which the race condition is designed
out of existence. The software polling should be able to access both the "data ready"
status bit and the data sample in a single (read) bus transaction. Sensible computer
architects have been doing this for decades. Intel doesn't seem to care about the
quality of their architecture.
> The right
> way to use this random chip is as one source of randomness for something
> like /dev/random, which would not only fetch and distill randomness from
> the chip and elsewhere, but mediate between uses of randomness, and not
> only for user-mode applications but within the operating system, such as
> for initial TCP sequence numbers. (See RFC 1948).
The value of such hardware support is minimal for most users of random numbers.
Simulations and such don't care about unpredictability, so they don't usually need
hardware sources of entropy. The only purpose for distilling entropy is security
applications. And a basic principle of security is to trust as few pieces of software
as possible. Thus the creation of a central entropy (not randomness) manager implies
the creation of a central weakness for secure applications.
The alternative, letting each app have safe, direct access to the hardware, makes it a
bit less probable that an error in the manager, or a compromised manager, will
compromise security.
------------------------------
Date: Mon, 10 Jan 2000 10:43:59 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Roger Schlafly wrote:
> Vernon Schryver <[EMAIL PROTECTED]> wrote in message
> news:85acr0$nv$[EMAIL PROTECTED]...
> > As far as the hardware can tell, there is no consistent difference between
> > a "multi-threaded app" and an operating system running "2 apps."
>
> So why does the Intel manual suggest a way to use the RNG in
> a multi-threaded app, but not give a clue about how to get it to work
> for 2 apps?
Because the example for a multi-threaded app works when applied at the OS level. To
the OS the applications look like threads. The fact that some share address spaces
(are threads within a single app) doesn't change the model for the OS. If the OS
provides a semaphore for controlling access to the RNG any number of apps can safely
share the resource.
>
>
> >The right
> > way to use this random chip is as one source of randomness for something
> > like /dev/random, which would not only fetch and distill randomness from
> > the chip and elsewhere, but mediate between uses of randomness, and not
> > only for user-mode applications but within the operating system, such as
> > for initial TCP sequence numbers. (See RFC 1948).
>
> That is your opinion, but it does not appear to be what Intel had in mind.
------------------------------
Date: Mon, 10 Jan 2000 10:48:38 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Vernon Schryver wrote:
> How much would you like to bet that the Intel employees who designed the
> facility expected that the operating system would mediate between the
> application wanting random bits and the various concurrent threads of
> execution that need random bits? I'm confident that they understand (and
> understood) the issue well enough, even if their main design target was
> software from Redmond. The odds are better than even that some of them
> have heard of /dev/random and thought that their design should be used
> within it.
$100 says they didn't think about it at all. had they considered the usage of the
device the interface would look considerably different. I suspect some engineer was
handed a feature to implement and all the effort went into the quality of the data and
none went into the quality of the interface. N.b., the interface would logically
include the hardware device registers and any software needed to drive it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: modifiec game of life encryption, to be analyzed
Date: Mon, 10 Jan 2000 15:09:32 GMT
Thanks Tim, you have been most most helpful. Much appreciated.
last note:
I had a quick try with a 3D version, 32x32x16 where an array of 32,32
contains 16bit words at random and in patterns to simulate a two byte
read from file just in case 3D was any better. 1 hour later I had it
working and tested functional. Load up a recognizable pattern in the
bits and watch..... 32 iterations later it's completed the cycle!!!!
Just goes to show that more complex in appearence does not mean more
complex in reality...
back to the drawing board.
do not know if I'll become a fredkin 'life'cake but, hey, I'm halfway
there don't ya think?
all your links are invaluable for sifting through the 80meg I have
downloaded over the past 20 or so days...
D10n...
[o]
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 10 Jan 2000 15:52:11 GMT
Guy,
Guy Macon ([EMAIL PROTECTED]) wrote:
: [1]
: Does SHA1 put out more bits than it is seeded with? If so, how can we
: call those bits random?
Well SHA1 always puts out 160 bits, despite what it's seeded with. If the
input is less than 512 bits(minimum block size for SHA), then it is padded
out to 512 bits. From _Applied Cryptography_,
"First append a one, then as many zeros as necessary to
make it 64 bits short of a multiple of 512, and finally a 64-bit
representation of the length of the message before padding."
The extra bits are definitely not random, OTOH, they are completely
predictable given a known length.
: [2]
: Does the nature of SHA1 match the behavior of variable delays between
: delivery of the random bytes?
Good question. From what I've seen, though, SHA1 can crank out a hash
faster than 75K/s on most platforms.
: [3]
: Is there any way to derive the input to the SHA1 from the output,
: and thus let me see the original thermal-random data?
Nope, as a cryptographically secure hash function, it should be computationally
hard to compute the input given the output. And remember, when the input
is larger than 160 bits, then there will be several different inputs which
map to the same output. This would be a collision.
Also from AC,
"The SHA is called secure because it is designed to be computationally
infeasible to recover a message corresponding to a given message digest"
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 10 Jan 2000 07:56:13 -0800
In article <85br4v$[EMAIL PROTECTED]>,
Guy Macon <[EMAIL PROTECTED]> wrote:
> Correct me if I am wrong, but it seems that the chip has a small processor
> or state machine in it that handles the memory cell programming and does
> a SHA1 hash on the output of the thermal noise source.
What makes you say that? That's not my understanding.
The URL posted in this thread purportedly describes how to get access
to the raw (unhashed) bits.
------------------------------
** 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
******************************
