Cryptography-Digest Digest #416, Volume #12 Fri, 11 Aug 00 11:13:01 EDT
Contents:
Re: Interesting new Rijndael paper by Robshaw & Murphy: (Vincent Rijmen)
Re: Pentium III h/w RNG ("Aztech")
Re: Explain S-boxes please ("Martin 'SirDystic' Wolters")
Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)
Re: New William Friedman Crypto Patent (filed in 1933) ("Bjarne Carlsen")
Re: Random Number Generator (tomstd)
WAP gateway to WWW - Will this configuration really fly from a security perspective
? (Mark Currie)
Re: The quick brown fox... (Mark Scott)
Re: Copyright isue - SERPENT (tomstd)
Re: Random Number Generator (Jerry Coffin)
Re: Random Number Generator (Jerry Coffin)
Re: 1-time pad is not secure... ("CMan")
Steganography (Bruce Barnett)
Re: Explain S-boxes please (Runu Knips)
Re: The quick brown fox... (JCA)
Newer SBOXGEN program (tomstd)
Re: Random Number Generator (Mark Wooding)
Re: 1-time pad is not secure... (Bob Silverman)
----------------------------------------------------------------------------
From: Vincent Rijmen <[EMAIL PROTECTED]>
Subject: Re: Interesting new Rijndael paper by Robshaw & Murphy:
Date: Fri, 11 Aug 2000 13:23:07 +0200
Our reaction to this document can be found at:
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/answer.pdf
Vincent
On Thu, 10 Aug 2000, Sam Simpson wrote:
> "Rijndael splits very cleanly into a layer of S-box transformations,
> a linear diffusion layer designed to provide mixing across the block,
> and a subkey layer.
>
> In this note we consider the linear diffusion layer of Rijndael. We
> derive the interesting property that any input text (or any input
> difference) to the linear diffusion component of Rijndael is always
> mapped to itself after at most 16 applications of the linear
> diffusion transformation. "
>
> http://isg.rhbnc.ac.uk/mrobshaw/
>
> --
> Sam Simpson
> Comms Analyst
> http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
> Delphi Crypto Components. PGP Keys available at the same site.
>
>
>
>
--
# Vincent Rijmen |
# | All true wisdom is found on T-shirts.
# phone +32 16 32 18 62 | (and in .signatures)
# [EMAIL PROTECTED] |
------------------------------
From: "Aztech" <[EMAIL PROTECTED]>
Subject: Re: Pentium III h/w RNG
Date: Fri, 11 Aug 2000 11:29:44 GMT
Hi,
I don't think it's actually the P3 but the i8xx line of chipsets, they
genenerate random patterns from fluterations in power and noise. OpenBSD has
support for it, and I can remember seeing an option for it in the 2.4.x
development kernels.
>From : http://www.openbsd.org/crypto.html
"Intel 82802AB/82802AC Firmware Hub RNG
The 82802 FWH chip (found on i810, i820, and i840 motherboards) contains a
random number generator (RNG). High-performance IPSEC requires more random
number entropy. As of April 10, 2000, we support the RNG. We will add
support for other RNG's found on crypto chips."
Az.
"David C. Barber" <[EMAIL PROTECTED]> wrote in message
news:8mvi5a$207f$[EMAIL PROTECTED]...
> The Pentium III is supposed to have some RNG function in it. A couple
times
> I'd heard that some analysis would be done with it, and even if it was
less
> than perfect, that that could be "fixed" with proper use. In the end, I
> never saw any analysis, though I'm sure some must have been done. Anyone
> have information and/or pointers on how well this function works?
>
> *David Barber*
>
>
>
------------------------------
From: "Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]>
Subject: Re: Explain S-boxes please
Date: Fri, 11 Aug 2000 13:53:51 +0200
>that these S-boxes have a inverse for decrypting.
In my opinion this is incorrect. Let's assume, there's
an S-Box, which replaces any bit wit '1's. There'd
exist no inverse. An f-function, which uses this
S-Box, would work both for encryption and decryption,
because it would produce the same output, even though
there exists no inverse for the S-Box.
(Although an S-Box which consists only of '1's wouldn't
be secure)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 11 Aug 2000 12:12:47 GMT
On Fri, 11 Aug 2000 02:11:31 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Consider the rotors as ABCDEFG. Four live inputs go to four SPDT
>switches under rotors ABCD, producing eight outputs.
I was going to note that there were many other possibilities as well,
but when I got to the end, the one I was going to mention had slipped
my mind.
In addition to the elaborate construction proposed there, and the
principle explained for five pinwheels that was used in the T52 and
A5, another arrangement might work like this:
Six live inputs could go to rotors ABCDEF, and seven outputs could be
used: A, not A, B, C, D, E, and F.
Then, these outputs could be dispatched to a second throw a bit down
the line, to produce fourteen signals:
A and B
A and (not B)
(not A) and C
(not A) and (not C)
B and D
B and (not D)
C and E
C and (not E)
D and F
D and (not F)
E and G
E and (not G)
F and A
F and (not A)
and then one output from each of a pair of switches could be used to
control a rotor, like this:
A is controlled by (B and (not D)) or (E and G)
B is controlled by (C and (not E)) or (F and A)
C is controlled by (D and (not F)) or (A and B)
D is controlled by (E and (not G)) or ((not A) and C)
E is controlled by (F and (not A)) or (B and D)
F is controlled by (A and (not B)) or (C and E)
G is controlled by ((not A) and (not C)) or (D and F)
Here, the chance of a rotor stepping is not 3/4 or 1/2, but 7/16, and
from one to six rotors will step each time, since if A, then either
rotor C or rotor F will step, and if not A, then either rotor D or
rotor G will step.
In addition to starting with four inputs, and keeping all their
inverses, or starting with six inputs, and retaining only one inverse,
one could also start with five inputs, so that a minimum of two rotors
and a maximum of five would move each time, for an arrangement
intermediate between this one and that noted previously.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Reply-To: "Bjarne Carlsen" <[EMAIL PROTECTED]>
From: "Bjarne Carlsen" <[EMAIL PROTECTED]>
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Fri, 11 Aug 2000 14:28:42 +0200
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 10 Aug 2000 19:16:04 +0200, "Bjarne Carlsen"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >AFAIK the cryptographic descriptions of the machine are still classified.
>
I guess I should have qualified that statement.
Cryptographic descriptions, meaning:
Actual blueprints and descriptions of the reasoning behind the lay-out of
the machine, together with the key-lists and the indicator systems. The
key-lists are probably all destroyed by now, and the indicator systems will,
I guess, remain classified for a long, long time, since some keying material
reportedly went missing in the early 80's.
The machine itself, including unwired or straight wired (A->A) rotors, was
declassified following the Walker/Pelton exposure. Today you may look and
touch - also with your favorite screwdriver - but NOT read the official
descriptions.
> In that case, you probably shouldn't be telling us things like
>
> >All the rotors were electrically connected, so all rotors participated in
> >the substitution. All rotors had the removable plastic rings. The
stepping
> >of all rotors were controlled via the slidebar/pawl system beneath the
rotor
> >cage. The three first rotors, stepped constantly, though in an irregular
> >fashion, guided by the rings, and contributed mechanically to the control
of
> >the stepping process of the rest of the rotors.
>
Pictures of KL-7 rotors and rings, which can be found several places in the
open literature, together with the pictures of the machine itself,
especially the top view on Jerry Proc's site, show this rather blatantly.
> Hopefully my uninformed speculations on this matter, not having had
> any direct contact with any secret cipher equipment, including the
> KL-7, will cause no harm.
>
> I remember when I saw the pictures of the KL-7 in Deavours and Kruh's
> book, I speculated on the division of the rotors in a group of three
> rotors and four rotors.
>
> I had thought that one possibility was a scaled-down SIGABA, with
> three control rotors and four cipher rotors. But this would mean there
> were only 16 possible steppings of the cipher rotors between each pair
> of letters, and that would be a weakness. Also, the book implied that
> the machine was intended to be less absolutely impregnable than the
> SIGABA.
Given the level of information exchanged via the KL-7, I would say that the
cryptologists at the NSA must have found a way to design the machine to be
*at least* as impregnable as the SIGABA. The implication in Kruh/Deavours
might have been a smoke-screen.
>
> Another possibility I imagined was that the machine might be a version
> of the Enigma, with the three rotors off to one side being used to
> create the wiring of a changing reflecting rotor connected to the
> other four.
>
> But the photograph of the rotor cage does indeed seem to imply, with
> 36 contacts on each end, that the signals just went in one end and out
> the other. The loopback - for an alphabet of either 32 or 26 symbols,
> presumably - would have taken place outside.
>
> What on earth, then, is that big extra space for?
>
> One plausible explanation finally occurred to me: a fat rotor that
> doesn't move. Why is it fat? *Rewirable* rotors tend to be bulkier
> than ordinary ones. (I suppose one of the seven rotors could be a
> really fat rewirable rotor, perhaps designed to be in one of two
> positions in the machine!)
>
> The previous poster's description of the rotor stepping as being
> electrically controlled by microswitches brought something to mind as
> well.
>
> The cams in some versions of the Siemens T-52 and the three shift
> registers in the A5 cipher had an unusual characteristic. They stepped
> each other, yet the way in which they did so was chosen so that they
> could never get 'stuck'.
>
> The basic principle used worked something like this:
>
> Given five shift registers or pinwheels to step one another, call them
> A, B, C, D, and E.
>
> Using an output from each one for stepping purposes (a different one
> than used to perform the encryption of plaintext), if the stepping of
> each pinwheel is controlled like this:
>
> A by C or not D
> B by D or not E
> C by E or not A
> D by A or not B
> E by B or not C
>
> then, we find that
>
> a) no wheel controls itself, and
> b) since D makes the stepping of wheel A certain, and not D makes the
> stepping of wheel B certain, and so on, there will always be some
> change each time.
>
> This principle does mean, though, that the pinwheels step 3/4 of the
> time. That is a good idea if they are producing output bits to XOR
> with plaintext. For a rotor machine, though, a figure closer to 1/2
> might be better.
>
> Since the KL-7, which inspired this discussion, has 7 rotors, how
> might we handle this case?
>
Again, I refer you to the top view - look closely at the pawls under the
rotor cage.
> With four SPDT microswitches, and three DPDT microswitches, which is
> certainly keeping the parts count down, one could control rotor
> movement through plastic cams on the rotors themselves through an
> arrangement like this:
>
> Consider the rotors as ABCDEFG. Four live inputs go to four SPDT
> switches under rotors ABCD, producing eight outputs.
>
> Use the DPDT switch under rotor E to swap (or not swap) outputs A and
> B.
>
> Use the DPDT switch under rotor F to swap (or not swap) outputs C and
> D.
>
> Use the DPDT switch under rotor G to swap (or not swap) outputs not A
> and not C.
>
> Finally, we can just wire-OR not B and not D together.
>
> So now we have seven outputs:
>
> two depending on rotors A, B, and E,
> two depending on rotors C, D, and F,
> two depending on rotors A, C, and G, and
> one depending on rotors B and D.
>
> One way they could be connected would be like this:
>
> (ABE)1 -> rotor D
> (ABE)2 -> rotor G
> (CDF)1 -> rotor A
> (CDF)2 -> rotor E
> (ACG)1 -> rotor B
> (ACG)2 -> rotor F
> (BD) -> rotor C
>
> Since rotor C moves 3/4 of the time, it should be the fourth rotor,
> the one in the middle of the seven. The other assignments should be
> random: I see no reason why the four contiguous rotors should
> correspond to ABCD and the three others to EFG.
>
> Usually, four rotors would step: only when two live outputs are OR-ed
> together in creating the (BD) output would only three rotors move.
>
> Obviously, this wiring pattern could be varied.
>
> So, for example, one could place a DPDT switch under rotor A, and use
> the second pole to choose between the B and D outputs for stepping
> rotor C.
>
> This would have the advantage of making all seven rotors step half the
> time.
>
No further comment, save that seven is not a magic number ;-)
> John Savard (teneerf <-)
> http://home.ecn.ab.ca/~jsavard/crypto.htm
Bjarne
------------------------------
Subject: Re: Random Number Generator
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 05:30:25 -0700
[EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
>> In article <8mtu40$9ck$[EMAIL PROTECTED]>, aernst331@my-
deja.com
>> says...
>> > Alex Random Number Generator
>> >
>> > The objective of this algorithm is to map finite
>> > key/seed to an infinite sequence of random bytes.
>>
>> This, of course, is impossible.
>
>Do you think that there is no mapping of finite sets of
natural
>numbers into set of infinite sets of natural numbers?
>Please evaluate this algorithm and you will believe.
If you think this is true you will seal your own fate. Even a
12 year old should figure this out.
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
Subject: WAP gateway to WWW - Will this configuration really fly from a security
perspective ?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 11 Aug 2000 12:39:23 GMT
Hi,
Apologies if this is perhaps a bit off-topic.
In the WAP protocol stack, WTLS or Wireless Transaction Layer Security provides
security and is similar to SSL-3 or TLS. However this is only between a
wireless device and a WAP server/gateway. In a WWW gateway scenario the WAP
gateway handles the SSL session with the WWW server and acts as a proxy on
behalf of the wireless client. Will this model really fly ? The WAP gateway
will effectively be a man-in-the-middle and have access to all user's sensitive
info.
The only way that I can see an acceptable security model for wireless-WWW
commerce with end-to-end security is to have WWW hosts implement WTLS or run
WAP servers. This sounds like a tall order to me.
IMHO even apart from the security aspect, the marriage of limited content
wireless devices to WWW is not good. Wouldn't it be better to create a separate
WWWW (Wireless WWW) ?
Comments welcome.
Mark
------------------------------
From: Mark Scott <[EMAIL PROTECTED]>
Subject: Re: The quick brown fox...
Date: Fri, 11 Aug 2000 14:28:24 +0100
Jackdaws love my big sphinx of quartz
(I see this previewing some Truetype fonts with Windows 2000).
Mark Scott +44 1256 343529 [EMAIL PROTECTED]
IBM eCRM Solutions for Domino, EMEA
------------------------------
Subject: Re: Copyright isue - SERPENT
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 06:42:11 -0700
Runu Knips <[EMAIL PROTECTED]> wrote:
>kihdip wrote:
>> A candidate for AES has to be free for everybody to use, but
is it correct
>> that SERPENT has some limitations in implementations because
of a copyright ??
>> If so, how much of the SERPENT implementation does this
copyright involve ??
>
>No, the only AES algorithm with a license problem is RC6, which
will
>only be free if it becomes AES, which is unlikely because it
doesn't
>offer key agility.
But's it is far simpler to implement, it's from RSA and it's
yankee material. Seems like enough for a technical round nose.
Hehehehe,
Tom
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 07:57:47 -0600
In article <8n0blf$4al$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Do you think that there is no mapping of finite sets of natural
> numbers into set of infinite sets of natural numbers?
> Please evaluate this algorithm and you will believe.
I have evaluated it. What you're claiming has long since been proven
absolutely, positively impossible. You're several centuries behind
the times if you think otherwise.
> > > - The probability to find in random sequence 0/1
> > > value bits is exactly 50%
> >
> > This shows a lack of bias, but that's a long ways from being a
> > comprehensive test of a PRNG.
> >
>
> Please check it yourelf.
I have, you idiot.
> > You PRNG fails some of the FIPS 140-2 tests fairly regularly. It
> > fails quite a few of the DieHard tests very consistently. Your PRNG
> > is clearly NOT suitable for cryptographic use.
>
> It is only your assumption. Let us proof it.
Quite the contrary -- I HAVE proven it, and you're just too stupid to
realize it. The code in DieHard that gives values of p=1.0000 gives
anybody who cares to look at its source code a way of predicting bits
from your generator with essentially perfect accuracy.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator
Date: Fri, 11 Aug 2000 08:10:08 -0600
In article <8n0aae$3fv$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Let me ask you how can man implement permutation of bits not using
> Assembler?
By learning to use a high-level language. Just for example, you
code:
lea esi, EffKey
xor ecx, ecx
xor edx, edx
@m0:
xor eax, eax
xor ebx, ebx
mov ax, [esi+ecx]
and al, 1fh
and ah, 1fh
reduces to the following in C:
short temp;
for (I=0; I<32;I+=2) {
temp = EffKey[0] + EffKey[1]<<8;
temp &= 0x1f1fh
Also note that your use of assembly language is _quite_ awful. Just
for example, it's trivial to combine:
and al, 1fh
and ah, 1fh
into:
and ax, 1f1fh
This is SO trivial that anybody who doesn't know it should NOT be
releasing anything they've written in assembly language for public
consumption. In fact, it's roughly equivalent to wearing a big sign
on your back saying you're a complete idiot.
> There are no weakness and holes in this algorithm.
This is yet another way of announcing to the world that you have an
IQ lower than room temperature (measured in Celsius).
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 11 Aug 2000 07:17:02 -0700
Ok, here is absolutely THE LAST WORD on one time pads:
"poMpYoihj"
There...
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote in message news:8mth1u$vpt$[EMAIL PROTECTED]...
> Here's a different viewpoint.
>
> I think all the crypto-books are wrong. One-time pad is only secure
> based on the assumption that random numbers do exist.
>
> But can you prove that random numbers really exist? No.
> Can you generate truely random numbers? No.
>
> It's like 1/x tends to zero but you'll never get zero, if you use
> enough bytes to hold the number.
>
> One-time pad is only computationally secure, no difference than any
> other systems. The key-generating process may be duplicated, if not
> exactly, to some probability. And because the key is so long, getting
> at least a portion of the key right will be easier than in systems with
> a shorter key.
>
> Get the picture? You can duplicate the key-generating parameters:
> computer model, OS, PRNG, date, time, location, hardware, software,
> room temperature, humidity, magnetic field... The list goes on and on.
> Then the longer the key, the higher possibility that you'll get
> something right.
>
> --Sisi
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Bruce Barnett <[EMAIL PROTECTED]>
Subject: Steganography
Date: 11 Aug 2000 10:18:50 -0400
Does anyone know of any references to a technique for watermarking of
text so that if more than one version of the text was examined,
differences might be seen, but it would still be difficult for two
individuals to create an version without revealing their identify.
I developed and implemented such a technique, and was wondering if
it was unusual, or if others have done something similar.
--
Bruce <barnett at crd. ge. com> (speaking as myself, and not a GE employee)
------------------------------
Date: Fri, 11 Aug 2000 16:27:12 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Explain S-boxes please
MVJuhl wrote:
>
> Could someone please explain where the S-boxes come from ? I mean, how are
> the computed.
> How would you select your own S-boxes ? What should you be careful of and
> what should you have in mind ?
>
> I only know that you substitute any given data with the content of the
> S-boxes in a specified order, and that these S-boxes have a inverse for
> decrypting. So if you would enlighten me, please do so.
>
> If you know of any links to papers explaining the S-box, please post/send
> them.
>
> Thanks
> M.V. Juhl
> [EMAIL PROTECTED]
Let me repost an older posting from Tom StDenis, which has also written
an SBox-Generator (http://www.geocities.com/tomstdenis/files/sboxgen.c):
Subject:
Re: Could RC4 used to generate S-Boxes?
Date:
Sun, 04 Jun 2000 15:07:05 -0700
From:
tomstd <[EMAIL PROTECTED]>
Organization:
http://www.remarq.com: The World's Usenet/Discussions Start
Here
Newsgroups:
sci.crypt
References:
1 , 2 , 3
In article <8hej6v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
>tomstd wrote:
>>
>>
>>In article <8hdt3k$apl$[EMAIL PROTECTED]>, Simon Johnson
>><[EMAIL PROTECTED]> wrote:
>>>I've read somewhere that RC4 is secure against both diff & lin
>>>cryptanalyis. I figure this secuirty must be derived from its
s-
>>box. My
>>>real question is, is the secrecy of the s-box that makes it
>>secure or
>>>does the algorithm generate diff & lin optimized s-boxes?
>>
>>Chances are you have a bit of reading todo on sbox
construction.
>>
>>The reason RC4 is secure is that it's hard to model the
internal
>>state based on output only. Some 'weak keys' have been
>>identified which leak more information about the state.
>>
>>The sboxes RC4 makes are by no means secure on their own (i.e
in
>>a feistel cipher), and don't always have optimial cryptographic
>>properties (SAC, BIC, non-linear, bijective, low xor-pairs).
>>
>>Tom
>
>Sorry for being a bother, but I am a clueless newbie who has a
>special interest in RC4 (the ciphersaber implementation, really)
>and the above went over my head. Could someone explain the
above
>in simple terms?
>
Sure no prob. RC4 is a STREAM CIPHER, not a sbox generator.
The only reason RC4 is secure is that it's hard to model the
internal state (i.e the table) from only the output.
RC4 does not always make secure sboxes for block ciphers or
other components. In a block cipher generally you use the same
sbox over and over (without any change) so it has to have some
ideal cryptographic properties. Such as being non-linear (avoid
the output and keybits being expressed by one boolean expression
with a higher probability), or low input-output xor pairs to
avoid differential cryptanalysis (all pairs are equally low
probable), or satisfy SAC which states "If bit j of the input
changes bit i of the output will change with prob 1/2", or BIC
which states "bit j and i (j != i) of the output are not
linearly dependant". RC4 is not designed to make 8x8 boxes that
fulfill these requirements.
Asides from that RC4 is not a super prng anyways, it's better
then nothing but that's about it.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion
Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: The quick brown fox...
Date: Fri, 11 Aug 2000 07:20:06 -0700
Have a look in the following page for a wealth of pangrams.
http://einstein.et.tudelft.nl/~arlet/puzzles/sol.cgi/language/english/sentences/pangram
wtshaw wrote:
> And now for something different:
>
> Without disputing the chance of the sentence, "The quick brown fox jumps
> over the lazy dog," being observationally illustrated, we know that it
> contains all twenty-six letters we commonly use.
>
> Requiring the whole alphabet, does anyone know of other alternatives,
> perhaps shorter ones and with no increase in nonsense content?
>
> Escaping syntax, how about the shortest number of disjointed words that
> incorporate the whole alphabet?
> --
> Too bad from the party members point of view that Ventura has
> gone, for what the Reform Party needs is a good referee and
> someone who understands how to *fix* things, before hurt sets in.
------------------------------
Subject: Newer SBOXGEN program
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2000 07:43:50 -0700
I saw a post referencing sboxgen cool... well glad somebody
likes it..
I updated sboxgen to limit the entries in the xor-table in the
first column (actually just limit the maximum value) when the
input is larger then the output
Also I made it perform more accurate SAC testing.
The source is on my website and is free for all purposes.
Tom,
--
http://www.geocities.com/tomstdenis/
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Random Number Generator
Date: 11 Aug 2000 14:56:40 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > >- 57% Avalanche Effect
> >
> > Avalanche of what?
>
> If only one bit of key/seed is changed this produces 57% changed bits
> in random sequence.
Errr... But that's hopeless. You want a mean of precisely 50% and
relatively small variance (err... about 4, I think). 57% is *way* off.
> > >- The probability to find in random sequence 0/1
> > > value bits is exactly 50%
> >
> > Gosh really?
>
> Yes!Gosh.
Whoops. That's a shame. This is a distinguisher!
-- [mdw]
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 11 Aug 2000 14:52:12 GMT
In article <8mth1u$vpt$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Here's a different viewpoint.
Thank you for this "viewpoint". I think the rest of the world
will see it for what it is; hand waving gibberish.
>
> I think all the crypto-books are wrong. One-time pad is only secure
> based on the assumption that random numbers do exist.
Fortunately, mathematics does not depend upon what *you* think, but
upon what can be proved.
>
> But can you prove that random numbers really exist? No.
False. Read any book on probability theory.
> Can you generate truely random numbers? No.
False. Radioactive decay and quantum processes are truly random.
So is e.g. thermal noise from a diode. So are distribution of
quadratic residues of a large prime.
Furthermore, for a OTP to be secure it isn't necessary to generate
a sequence of 'truly' random numbers. It is only necessary to
generate a sequence which *CAN NOT BE DISTINGUISHED FROM TRULY RANDOM
by a COMPUTATIONALLY UNBOUNDED ADVERSARY*.
>
> It's like 1/x tends to zero but you'll never get zero, if you use
> enough bytes to hold the number.
This is gibberish.
>
> One-time pad is only computationally secure, no difference than any
> other systems. The key-generating process may be duplicated, if not
> exactly, to some probability.
"some probability" here is exponentially small in the length of the key,
i.e. you can duplicated a k-bit key with probability no more than
1/2^k. This is indistinguishable from 'truly random' even by an
unbounded adversary.
> Get the picture? You can duplicate the key-generating parameters:
> computer model, OS, PRNG, date, time, location, hardware, software,
> room temperature, humidity, magnetic field... The list goes on and on.
> Then the longer the key, the higher possibility that you'll get
> something right.
Yes, there is a significant probability that you can guess some
sub-portion of the key. The problem with this is that even if you do,
you can not know that you HAVE GUESSED CORRECTLY.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
