Cryptography-Digest Digest #15, Volume #9 Mon, 1 Feb 99 10:13:04 EST
Contents:
Re: Recluse Creates Encryption-Based Imagery (Jim)
Re: Truth, theoremhood, & their distinction (Torkel Franzen)
Re: Who will win in AES contest ?? (Fabrice Noilhan)
Re: SCOTT19U (Fabrice Noilhan)
Re: Understanding Feistel Networks (Phil)
Re: SCOTT19U (Thomas Pornin)
Re: RNG Product Feature Poll (R. Knauer)
Re: What is left to invent? (R. Knauer)
Re: Random numbers generator and Pentium III (R. Knauer)
Re: Pentium III... (Stefek Zaba)
Re: Truth, theoremhood, & their distinction (John Forkosh)
Re: SCOTT19U (Casper H.S. Dik - Network Security Engineer)
Re: RNG Product Feature Poll (Dan S. Camper)
Re: yet another U.S export restriction ques... (chris)
Re: RNG Product Feature Poll (R. Knauer)
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Jim <[EMAIL PROTECTED]>
Subject: Re: Recluse Creates Encryption-Based Imagery
Date: Mon, 01 Feb 1999 03:55:44 -0500
Douglas A. Gwyn wrote:
> JTyburczy wrote:
> > Rural savant challenges classical neuroscience with new 'fractile' image
> > process. Challenged by experts. Story at:
> > http://members.aol.com/jrubu/noyes.htm
>
> What did that have to do with cryptology?
The pictures are good looking. Starbox (down at the bottom) makes a pretty
good wallpaper or background. He didn't have much in the way of
how he does this stuff, although, it looks really artsy.
Look, the poster said it challenged "neuroscience". Obviously a
misdirected quote. Shades of Archimedes Plutonium :)
This would make a nice project to come up with an automated
program to morph regular photographs in this way. It would be
a bit more challenging than a simple algorithm, since, you have to
decide on which area to morph as well as anticipating that the
morph will make it look fractal-like. Anyway, I think that's what
he's doing... judicious choice of cropping on nature photographs.
He could have me fooled, though.
------------------------------
From: Torkel Franzen <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: Truth, theoremhood, & their distinction
Date: 01 Feb 1999 08:22:32 +0100
Michael Hovdan <[EMAIL PROTECTED]> writes:
> When you distinguish between truth and theoremhood - do you mean that
>some theorems are *not* true? Or that some mathematical truths are
>*not* theorems?
"Theorem" is relative to a theory, "true" is not. It is a
mathematical theorem that for any theory T satisfying some basic
conditions, some mathematical truths are not theorems of T or some
mathematical falsehoods are theorems of T. These are purely technical
observations. Presumably such mathematical distinctions between truth
and theoremhood are what the original poster had in mind.
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: Who will win in AES contest ??
Date: 1 Feb 1999 09:46:09 GMT
According to Hironobu Suzuki <[EMAIL PROTECTED]>:
> It's true that twofish is faster than serpent. But I disagree with
> you. When I made Linux cipher filesystem, I checked thier performance
> on my computer.
>
> Twofish hi/fn 28.7Mbps
> Serpent Ross J Anderson 18.7Mbps
On the other hand, you have assembly coded implementations, which are
the most meaningful since you care for speed:
On PPro: Serpent is 921 cycles, and Twofish is 258 cycles. Even if you
make a 16 rounds serpent, twofish will be nearly twice as fast. Those
are the best implementations available today (as far as I know).
Technically, for an encrypted file system, this does not make sense to use
C if asm is faster.
Fabrice
------------------------------
From: [EMAIL PROTECTED] (Fabrice Noilhan)
Subject: Re: SCOTT19U
Date: 1 Feb 1999 09:53:17 GMT
According to <[EMAIL PROTECTED]>:
> Hint think indian. Also if stuck with a native SUN C aompiler good
> luck you we need it. But try gcc instead of cc you may already have
> the best C compiler on your SUN.
Nonsense. Whenever you write an algorithm, you have to care about
endianess. If your C code is not portable, and if you don't issue a
document on the algorithm, don't be surprised if noone is considering
your algorithm as serious.
BTW, the best C compiler on Sun is Sun's cc, especially for
cryptographic purposes. And it's the only compiler which handles native
64-bit registers and instructions. If you stick to gcc, you usually get
worse performances. egcs is a *little* better on this point of view.
Fabrice
------------------------------
From: Phil <[EMAIL PROTECTED]>
Subject: Re: Understanding Feistel Networks
Date: Mon, 01 Feb 1999 02:04:32 -1000
Anthony wrote:
>
> I've recently been trying to understand how Feistel networks such as DES
> work.
> I can follow the descriptions of what happens in the network but I am
> struggling when it comes to the decryption process. It is intuitively
> satisfying that the key schedule should be reversed but when it comes to
> the s-boxes I am confused. It seems to me that for the decryption to
> work the s-boxes would have to be somehow inverted so as to reverse the
> encryption. However I know that this is not the case.
>
> Is there some special property of the DES s-boxes that is vital to
> allowing the decryption to be done this way?
No.
>
> I would be very grateful for any information that might help me
> understand this process or for any reference that contain this sort of
> information. All the texts I have consulted treat this topic
> descriptively without delving into the inner workings of these networks.
>
> Thanks in advance,
>
> Anthony.
The special property is not in the S-Boxes. It is in the XOR gates. The
XOR function allows a reversal of information transformations. Look at
the truth table of XOR. It has 2 inputs L and R and an output C. If you
use C as an input with R, the output is L:
L = 1011
R = 1110
C = 0101
0101 XOR 1110 = 1011 = L
This way the input was recovered without going backwards through the XOR
function. Going forwards through the XOR recovered the original input L.
The L and R in DES are the Laft and Right block halves. Only one half is
transformed in each round. The other half is from a previous round. It is
this carrying of the results from a previous round to be XORed in the
current round which allows decryption to be done by going "forward"
through the Feistel network. You can write equation with round
subscripts that shows that this works perfectly.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: SCOTT19U
Date: 1 Feb 1999 10:16:04 GMT
According to Fabrice Noilhan <[EMAIL PROTECTED]>:
> BTW, the best C compiler on Sun is Sun's cc, especially for
> cryptographic purposes. And it's the only compiler which handles
> native 64-bit registers and instructions.
Actually there is a version of gcc for sparc64, but I do not know
whether it interacts cleanly with Solaris 7 or not. It should be
usable, since Solaris 7 and Linux both use the Elf64 binary format on
ultrasparc, however I have not tried it. I guess it would not beat Sun's
cc 5.0, but it might be rather good if you try the patches from David
Miller.
Anyway, I agree with you: non-portable optimized code is acceptable
for time-critical tasks, but if it is supposed to be some sort of
documentation, it is pure crap. Some sort of "security by obscurity".
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Mon, 01 Feb 1999 11:32:18 GMT
Reply-To: [EMAIL PROTECTED]
On 31 Jan 1999 16:50:38 -0500, [EMAIL PROTECTED] (Herman
Rubin) wrote:
>>Since any decay occurs at random, the interval between any two of them
>>is random. Intervening events, like other decays, are totally
>>irrelevant to the randomness of the two events that do get measured.
>The intervals are random, but may or may not be independent.
How can the time at which one radioactive decay is detected be
dependent the time another decay is detected? Notice that I said
"detected" not decayed.
If you are alluding to undetected events, due to the detector being
unable to detect two closely spaced decays, those undetected events do
not cause other events, the ones that are detected, to be dependent on
one another. The events that are detected are still completely random
in time.
>Also, how are you using the device to generate the random bits?
>If you are waiting a length of time and using parity of the number
>counted, the bias of the bit produced is not zero, and is improved
>by having even a substantial amount of dead time.
The method we have been discussing is written up on the HotBits site:
http://www.fourmilab.ch/hotbits/
Briefly stated, one measures the time between two detected events and
compared it to the time between the next two detected events. Half the
time the interval comparison will produce a 1 bit if the first
interval is longer than the second and a 0 bit if it is shorter, and
the other half the time it will produce the reverse. This eliminates
any bias in the measurements.
>I have a report on this.
Please share it with us.
>However, I suggest that several runs be taken, and the results
>XOR'ed. One cannot reasonably test randomness to more than one
>part in 10^3, if that.
What do you mean by "test randomness"? If you are talking about
statistical tests on the output strings then those tests do not
characterize the TRNG adequately. The best they might do is give you a
level of confidence, which is not good enough for the proveable
security of the OTP cyyptosystem.
>But if one combines 8 such bit streams,
>and 5 pass the test, the result should be quite good.
There is no "should" in the OTP cryptosystem. PRNGs pass statistical
tests, but are unsuitable for the OTP. Only a TRNG will be
satisfactory, and it cannot be characterized properly by examining its
output, only by examining its internal design.
Bob Knauer
"I place economy among the first and most important virtues and
public debt as the greatest dangers to be feared. We must not
let our rulers load us with perpetual debt."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is left to invent?
Date: Mon, 01 Feb 1999 11:10:17 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 29 Jan 1999 00:54:28 +0000, Toby Kelsey
<[EMAIL PROTECTED]> wrote:
>>I was told that the probability for an intelligible message, other
>>than the intended message, is vanishingly small when the message
>>length exceeds the unicity distance. Therefore only one possible
>>plaintext is intelligible - your intended message.
>Yes, this is true for current cryptosystems which do not attempt to
>generate plausible messages with incorrect keys.
>It is not true generally.
I am still confused.
The unicity distance for a 56-bit key system like DES is 8.2 ASCII
characters. If the message is significantly longer than that 8.2
characters, there is only one possible plaintext out of the 2^56
possible decryptions that is an intelligible message, and that is the
intended message that was encrypted.
IOW, under a brute force attack, all of the 2^56 - 1 plaintexts that
are not the intended message will not be fully intelligible, only the
one which is my message.
Please elaborate on your contention with an example.
Bob Knauer
"I place economy among the first and most important virtues and
public debt as the greatest dangers to be feared. We must not
let our rulers load us with perpetual debt."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers generator and Pentium III
Date: Mon, 01 Feb 1999 11:13:28 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 31 Jan 1999 19:20:14 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Well, on this particular subtopic your obtuseness can be considered an
>existential proof that the value of statistical evaluation of random sequences
>is hard. You can fix that.
Now you are forced to resort to ad hominems - because your arguments
are failing to convince anyone, and you know it.
That makes your further comments totally irrelevant to this
discussion.
<plonk>
Bob Knauer
"I place economy among the first and most important virtues and
public debt as the greatest dangers to be feared. We must not
let our rulers load us with perpetual debt."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: Pentium III...
Date: Mon, 1 Feb 1999 11:09:00 GMT
In sci.crypt, Terry Ritter ([EMAIL PROTECTED]) wrote:
> Producing cryptographic random values on a web server does not sound
> like a great idea to me.
A "great" idea it may not be, but - at a plausible guess - well over 90%
of "cryptographic random numbers" in fielded use today are being generated
on web servers and clients. I make this guesstimate on the grounds that the
most widely-deployed crypto protocol on the Net is SSL/TLS, with HTTP as the
dominant traffic carried by SSL. The session keys are generated by the
client alone (SSLv2), or co-operatively by client and server (SSLv3/TLS).
Depending on the platform, the degree of interaction with less predictable
external events may be lesser or greater - /dev/random on Linux boxes,
crufty combinations of (high-resolution) hard disk seek times and activities
of other processes on Windows implementations. It's very rare for fielded
e-commerce sites to run RNG hardware at the server end - and even if you do,
there's no way for the server to influence the session key under SSLv2 :-(
Having an on-chip source of unpredictability to stir into the mix should be
a help; it won't be if it's carelessly implemented or carelessly used, though.
Stefek
------------------------------
From: [EMAIL PROTECTED] (John Forkosh)
Crossposted-To: sci.math,comp.theory
Subject: Re: Truth, theoremhood, & their distinction
Date: 1 Feb 1999 07:03:36 -0500
Michael Hovdan ([EMAIL PROTECTED]) wrote:
: I think you will find that 'philosophical' view expressed
: in most books on mathematical logic.
I'd recommend
Philosophy of Logic, 2nd Edition
W.V. Quine
Harvard University Press, 1986
ISBN 0-674-66563-5
Particularly Chapter 3, Truth and Satisfaction, from whose
preface: "Logic chases truth up the tree of grammar."
John ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Subject: Re: SCOTT19U
Date: 1 Feb 1999 11:10:05 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
[EMAIL PROTECTED] (Thomas Pornin) writes:
>Actually there is a version of gcc for sparc64, but I do not know
>whether it interacts cleanly with Solaris 7 or not. It should be
>usable, since Solaris 7 and Linux both use the Elf64 binary format on
>ultrasparc, however I have not tried it. I guess it would not beat Sun's
>cc 5.0, but it might be rather good if you try the patches from David
>Miller.
The egcs compiler "sort-of" supports Solaris in 64 bit mode. Unfortunately,
the current egcs snapshots are very unstable.
And Linux may run in 64 bit mode on Sparc, I don't think they quite did
64 bit userland yet (on SPARC)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: [EMAIL PROTECTED] (Dan S. Camper)
Subject: Re: RNG Product Feature Poll
Date: Mon, 01 Feb 1999 08:05:08 -0600
In article <792j7e$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Herman Rubin) wrote:
>Also, how are you using the device to generate the random bits?
>If you are waiting a length of time and using parity of the number
>counted, the bias of the bit produced is not zero, and is improved
>by having even a substantial amount of dead time. I have a report
>on this.
The data is generated a byte (8 bits) at a time. A particle detection
interrupts the incrementing of a 16-bit register, running in the
background. The high and low 8 bits of that register are XOR'd together
to produce the output byte. The register is not reset between
detections. I don't remember offhand if the register is seeded at zero
when power is first applied or not. The device has been tuned so that the
16-bit register cycles once (on average) between detections.
This was the fastest algorithm we could find for producing data that
passes Diehard in its raw form. The method used in HotBits -- comparison
timing between three detection events -- is rather slow. For what it's
worth, both methods produced very similar results in Diehard.
DSC
____________________________________________________________________
Dan S. Camper [EMAIL PROTECTED]
Borrowed Time, Inc.
------------------------------
From: [EMAIL PROTECTED] (chris)
Subject: Re: yet another U.S export restriction ques...
Date: Mon, 01 Feb 1999 14:18:09 GMT
On Sat, 30 Jan 1999 01:55:23 GMT, Kent Briggs <[EMAIL PROTECTED]>
wrote:
>
>The export regulations prohibit an application from using double
>encryption. All encryption meant for export from the U.S. requires at
>least a one-time review by the NSA and they will simply reject anything
>"cute" that you try to do to get around the 56-bit key limit. You
>probably won't even get to use a 56-bit key unless you pick an algorithm
>from their "approved" list (RC2, RC4, DES, CAST).
>
what if i compressed the data, then ran it through a block cipher? it
seems to me that compression (of the zlib flavor) could be seen as a
kind of keyless stream cipher (a hash?).
also, i thought the approval was now automatic, in cases of 56 bits or
less? i wouldn't be surprised if i was mistaken, but i remember
reading something like this.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Mon, 01 Feb 1999 14:15:46 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 01 Feb 1999 08:05:08 -0600, [EMAIL PROTECTED] (Dan S. Camper) wrote:
>For what it's
>worth, both methods produced very similar results in Diehard.
Insecure PRNGs can pass Diehard, but that does not make them suitable
for the proveably secure OTP cryptosystem.
You must certify the security of your generator based on its design
and its internal performance, not its output.
I am not saying that your device would fail a design analysis, just
that relying on statistical testing of the output is a poor way to
characterize a TRNG.
Bob Knauer
"I place economy among the first and most important virtues and
public debt as the greatest dangers to be feared. We must not
let our rulers load us with perpetual debt."
--Thomas Jefferson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
Date: Mon, 01 Feb 1999 15:32:46 +0100
R. Knauer wrote:
>
>
> Li and Vitanyi in their book on Kolmogorov Complexity demonstrate that
> all probabilistic measures of randomness fail except for algorithmic
> complexity. They show many reasons why stochastic randomness is not
> suitable for finite strings. For example if p is the probability for
> the bit 1 to occur, then infinite strings will have an infinite number
> of 1s as aexpected only if p>=1/2. If p<1/2, then there are only
> finite number of 1s in an infinite sequence. IOW, if p = 0.5-epsilon,
> then the infinite number is not random.
I am not familiar with the book. But I suspect that you misunderstood
something. The assertion above 'If p<1/2, then there are only
finite number of 1s in an infinite sequence' is obviously false.
Counter-example: 001001001001.......... Here p=1/3<1/2. But obviously
there are infinite 1's.
M. K. Shen
------------------------------
** 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
******************************
