Cryptography-Digest Digest #223, Volume #14 Tue, 24 Apr 01 12:13:01 EDT
Contents:
Re: Security proof for Steak ("Tom St Denis")
Re: First analysis of first cipher (Mark Wooding)
Re: Security proof for Steak ("Henrick Hellstr�m")
Re: OTP breaking strategy ("Tony T. Warnock")
Re: Security proof for Steak ("Tom St Denis")
Re: Wolf's Secure Channel Theorem ("Mark G Wolf")
Re: Micro Video Camera Suitable for Documents? (Samuel Paik)
Re: Censorship Threat at Information Hiding Workshop (Eric Lee Green)
Re: OTP WAS BROKEN!!! (Lou Grinzo)
Re: OTP WAS BROKEN!!! ("ink")
Re: Censorship Threat at Information Hiding Workshop ("Sam Simpson")
Re: Security proof for Steak ("Henrick Hellstr�m")
Re: Wolf's Secure Channel Theorem ("Mark G Wolf")
Re: Triple-DES vs. RC4 ("Scott Fluhrer")
Re: Wolf's Secure Channel Theorem ("Jack Lindso")
Blowfish Advanced - What happened to Blowfish32? (Frog2)
Re: OTP WAS BROKEN!!! (Ben Cantrick)
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Re: _Roswell_ episode crypto puzzle ("Michael Cock")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 12:59:39 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9c3sre$1v9$[EMAIL PROTECTED]...
> Have a look at http://www.streamsec.com/sattacks.asp
>
> It might be considered to be a draft so far. I would appreciate any
> comments.
I wouldn't trust that design for one simple reason. It's too complicated.
You think if RC4 was 100 lines long it would be so popular?
Honestly are all stream cipher designers idiots like me?
Ingredients for a good secure PRNG
1. Take a nice long perioded linear PRNG such as a LFSR or LFG
2. Muddle the bits in a cocher way such that all outputs are possible and
equal probable
Then you simply analyze step 2. (Which could be Algorithm M and despite
what Terry says Marsaigla only analyzed the case afaik of using two LCG's
not LFSRS or LFGS).
Starting with a known long perioded generator is a requirement. By looking
at the muddle in the "Steak" cipher you cannot tell (neither by looking at
RC4 which by coincident Schneier plays the Number game P398 second
paragraph, shame on him!).
Not only that but if you want people to really read your design you should
organize your info into a paper (even an informal one) where you describe
all your notation, then describe the parts of the cipher, your rationale
etc...
Tom
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: First analysis of first cipher
Date: 24 Apr 2001 13:40:59 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Last week I posted my first cipher (now dubbed "Brontosaurus") and
> was challeged to cryptanalyze it. Once again, point out WHY I'm going
> wrong as well as where:
<grin>
> The short analysis is that Bronto will be "easily" broken using
> differential cryptanalysis techniques. The primary weakness of the
> cipher is that S-boxes with 4-bit entries, chosen at random, are
> used. At this point, I think that the weakness is due primarily to the
> small m, and not necessarily due to the fact that the entries are
> randomly chosen.
With an S-box that small, you must choose it carefully, rather than
trusting to luck.
> Since the S-boxes are the only part of the cipher which provides
> non-linearity, the strength of the cipher depends almost entirely on
> the strength of the S-boxes.
No. Everything there has an important function. Each component is weak
in isolation. You must combine them together so that they strengthen
each other. A cipher is an ensemble piece.
> Next, I'm going to try to determine the del_Input, del_Output table for
> the F function of my cipher.
Unless you have some clever algorithm in mind for this, it will take Too
Long.
-- [mdw]
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 15:42:49 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:%MeF6.44155$[EMAIL PROTECTED]...
> I wouldn't trust that design for one simple reason. It's too complicated.
> You think if RC4 was 100 lines long it would be so popular?
There is no security proof of that magnitude for RC4, rather the opposite.
And Steak is definetly less complicated than any secure block cipher I know
of, and, in fact, less complicated than most stream ciphers too.
Did you really look at the pseudo code at http://www.streamsec.com/salgo.asp
?
> Starting with a known long perioded generator is a requirement. By
looking
> at the muddle in the "Steak" cipher you cannot tell (neither by looking at
> RC4 which by coincident Schneier plays the Number game P398 second
> paragraph, shame on him!).
Yes, you could. All you have to observe is (1) the security proof, and (2)
that there is cipher text feedback. If some state of Steak would give rise
to a short cycle (which it can't), the plain text would have to have exactly
the same period or the cycle would be broken before it started.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Tue, 24 Apr 2001 07:49:11 -0600
Reply-To: [EMAIL PROTECTED]
newbie wrote:
> What is a random process?
> What it appears today to be truly random will be very predictable
> tomorrow.
> Randomness is nothing more than some mechanisms above our actual
> computational power.
That's one type of "randomness," which is used in classical statistical
mechanics.
The randomness of quantum mechanics is quite different. It's intrinsic
to a system's behavior.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 13:57:59 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9c3vtr$5id$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:%MeF6.44155$[EMAIL PROTECTED]...
>
> > I wouldn't trust that design for one simple reason. It's too
complicated.
> > You think if RC4 was 100 lines long it would be so popular?
>
> There is no security proof of that magnitude for RC4, rather the opposite.
> And Steak is definetly less complicated than any secure block cipher I
know
> of, and, in fact, less complicated than most stream ciphers too.
That's bullocks. Look at GOST, RC5 and Blowfish for example. They are all
trivially simple ciphers to implement.
> Did you really look at the pseudo code at
http://www.streamsec.com/salgo.asp
is your D sbox bijective?
Have you tried differential or linear cryptanalysis against this? from what
I can tell all your security lies in D.
> > Starting with a known long perioded generator is a requirement. By
> looking
> > at the muddle in the "Steak" cipher you cannot tell (neither by looking
at
> > RC4 which by coincident Schneier plays the Number game P398 second
> > paragraph, shame on him!).
>
> Yes, you could. All you have to observe is (1) the security proof, and (2)
> that there is cipher text feedback. If some state of Steak would give rise
> to a short cycle (which it can't), the plain text would have to have
exactly
> the same period or the cycle would be broken before it started.
Long period != security.
So what. a 128-bit LFSR has a huge period but it isn't secure either.
>
>
>
> --
> Henrick Hellstr�m [EMAIL PROTECTED]
> StreamSec HB http://www.streamsec.com
>
>
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Wolf's Secure Channel Theorem
Date: Tue, 24 Apr 2001 09:26:54 -0500
> Your conjecture is wrong.
>
> Proof: Cut the wire!
There are no wires in information space. Humans certainly need a physical
medium for communication exchange, but having a secure channel and
communicating over that channel are two different things. In other words
you could prevent communication from taking place, but if it did take place
you wouldn't be able to tell what was said. Let me give you a very real
world example. If you went to a foreign country and didn't understand the
language, the native people around you could communicate securely without
you ever knowing what was being said.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Micro Video Camera Suitable for Documents?
Date: Tue, 24 Apr 2001 14:29:58 GMT
John Savard wrote:
> >Do you mean at the same time? As in, one image captures the entire document?
> >If so, you probably need at around
> > 200 dpi * (8.5 in x 11 in) => 1700 pixels x 2200 pixels capture format.
> >This is not a format you can display on a VCR.
>
> 100 dpi or even 60 dpi would do.
60 dpi is probably too low. Consider you are imaging 10 pt type--that's
12 characters/inch. At 60 dpi you've got about 5 pixels per character--
probably too low for accurate recognition.
--
Samuel S. Paik | [EMAIL PROTECTED]
3D and digital media, architecture and implementation
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Censorship Threat at Information Hiding Workshop
Reply-To: [EMAIL PROTECTED]
Date: 24 Apr 2001 09:30:52 -0500
On 24 Apr 2001 09:34:36 GMT, Markus Kuhn <[EMAIL PROTECTED]> wrote:
>BTW, it seems this SDMI issue has caught some attention in the media:
>
>http://www.theregister.co.uk/content/8/18434.html
An almost verbatim copy of John Young's story at cryptome.org.
I bet John is quite pleased to find that the guys at
The Register (a rather impudent tweaker of status quo, quite
entertaining, though not always accurate!) are readers of
cryptome.
>http://www.inside.com/jcs/Story?article_id=29036&pod_id=9
Quite entertaining. Read Declan McCullagh's reporting in Wired on the
Jim Bell show trial too (let's see, let's try this guy, but let's not
allow him to subpoena a single witness and let's not allow him access
to the prosecution's evidence as required by discovery rules, wow!
Sounds like a Soviet era show trial to me!).
--
Eric Lee Green http://www.badtux.org mailto:[EMAIL PROTECTED]
Phoenix Branch -- Eric Conspiracy Secret Labs
Cruisin' the USENET since 1985
------------------------------
From: [EMAIL PROTECTED] (Lou Grinzo)
Subject: Re: OTP WAS BROKEN!!!
Date: Tue, 24 Apr 2001 14:41:32 GMT
"You are the more smart in the world."
I think we finally have a replacement for "all your base are belong to
us" and "someone set us up the bomb." <g>
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Thank you for your comments.
> You are the more smart in the world.
> I'm stupid.
> Ok
> Are you satisfied?
>
>
>
>
> Tom St Denis wrote:
> >
> > "newbie" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Did you read what I wrote?
> >
> > Who cares what you write anymore? You're as rude as I am and alot stupider
> > which is a bad combo. Learn to admit defeat (a lesson I had to learn a few
> > times...).
> >
> > Your argument that the OTP is not secure is very immature and lacks formal
> > reasoning. You say "well it looks non-random so it must be the solution".
> > You fail to recognize that the number of non-random plaintexts is
> > astronomical....
> >
> > Tom
>
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: OTP WAS BROKEN!!!
Date: Tue, 24 Apr 2001 16:46:31 +0200
"Lou Grinzo" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]...
> "You are the more smart in the world."
>
> I think we finally have a replacement for "all your base are belong to
> us" and "someone set us up the bomb." <g>
>
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > Thank you for your comments.
> > You are the more smart in the world.
> > I'm stupid.
> > Ok
> > Are you satisfied?
Lou... you might not believe it, but English is not everybody's first language.
Cheers,
ink
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Tue, 24 Apr 2001 15:47:31 +0100
To be fair, they probably got the story from Slashdot:
http://slashdot.org/article.pl?sid=01/04/21/1319251&mode=thread
--
Regards,
Sam
http://www.scramdisk.clara.net/
Eric Lee Green <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 24 Apr 2001 09:34:36 GMT, Markus Kuhn <[EMAIL PROTECTED]> wrote:
> >BTW, it seems this SDMI issue has caught some attention in the media:
> >
> >http://www.theregister.co.uk/content/8/18434.html
>
> An almost verbatim copy of John Young's story at cryptome.org.
> I bet John is quite pleased to find that the guys at
> The Register (a rather impudent tweaker of status quo, quite
> entertaining, though not always accurate!) are readers of
> cryptome.
>
> >http://www.inside.com/jcs/Story?article_id=29036&pod_id=9
>
> Quite entertaining. Read Declan McCullagh's reporting in Wired on the
> Jim Bell show trial too (let's see, let's try this guy, but let's not
> allow him to subpoena a single witness and let's not allow him access
> to the prosecution's evidence as required by discovery rules, wow!
> Sounds like a Soviet era show trial to me!).
>
> --
> Eric Lee Green http://www.badtux.org mailto:[EMAIL PROTECTED]
> Phoenix Branch -- Eric Conspiracy Secret Labs
> Cruisin' the USENET since 1985
>
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 16:54:29 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:HDfF6.44357$[EMAIL PROTECTED]...
>
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> news:9c3vtr$5id$[EMAIL PROTECTED]...
> > "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> > news:%MeF6.44155$[EMAIL PROTECTED]...
> >
> > > I wouldn't trust that design for one simple reason. It's too
> complicated.
> > > You think if RC4 was 100 lines long it would be so popular?
> >
> > There is no security proof of that magnitude for RC4, rather the
opposite.
> > And Steak is definetly less complicated than any secure block cipher I
> know
> > of, and, in fact, less complicated than most stream ciphers too.
>
> That's bullocks. Look at GOST, RC5 and Blowfish for example. They are
all
> trivially simple ciphers to implement.
Maybe, bit firstly I wouldn't call 64-bit block ciphers secure, and secondly
the key stream function of Steak is actually just about as simple as far as
I can tell.
The only complex part of the implementation of Steak is the initial key set
up, but that's because the initial key hashing is incorporated in the
cipher, so that as much use as possible is made out of the 1 kilobyte
maximum key size.
> is your D sbox bijective?
D is not really an s-box, but rather the composition of four s-boxes and a
static invertible 32-bit matrix, in about the same way as e.g. the software
implementation of the s-boxes and the MDS function of TwoFish. Have a look
at http://www.streamsec.com/mt.asp I even give you the inverse.
> Long period != security.
>
> So what. a 128-bit LFSR has a huge period but it isn't secure either.
Eh? You didn't understand the security proof, did you? ;-)
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Wolf's Secure Channel Theorem
Date: Tue, 24 Apr 2001 10:01:54 -0500
> Let Alice stand at one end of the channel and Bob at the other. Eve is
> between Alice and Bob and can listen in to anything that passes between
Sounds kinky!
> So here are my results (which could be wrong, I'm looking for feedback
> :-) ) :
It's so freaking simple I want to blurt it out but...
> "Wolf's Secure Channel Theorem - once a secure authentic channel has
> been established between two distinct points in space it can be
> maintained indefinitely" is TRUE (and assuming there's a protocol to
> ensure authenticity) IFF:
I've been thinking about this authenticity protocol as you put it. The
problem arises from the fact that we are not dimensionless points in space.
Well at least some of us are not. I'm still trying to integrate physical
space with information space. Initially the points would have to come into
"contact", if that makes any fucking sense. I do believe I have a Corollary
to my Theorem.
_______________________________________________
Corollary 1 to the Secure Channel Theorem:
Once three secure authentic channels have been established between three
distinct points in space all further secure authentic channels can form "at
a distance".
_______________________________________________
> the secure channel is established with a cipher with perfect secrecy
> using quantum key exchange between Alice and Bob.
Quantum Shuantum. BTW, if any of this stuff is new I better be getting a
reference. Otherwise I'm going to send a big hairy guy to butt fuck you and
burn your house down. Of course some of you might like that first part.
Ok, then I'll call you plagiarizing thieves. Gosh I'm feeling full of
myself this morning, how unbecoming of me.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Triple-DES vs. RC4
Date: Tue, 24 Apr 2001 08:05:34 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Michael Schmidt <[EMAIL PROTECTED]> wrote:
>
> > I'm looking for some performance survey about Triple-DES and RC4 (128
> > bit) used for payload encryption, preferably on a Pentium II or higher
> > processor (i.e. PC). I am aware that I'm comparing a block cipher with
> > a stream cipher.
>
> RC4 is a factor of 25 faster on my PIII (using my own implementations).
>
> > However, Triple-DES and RC4 seem to be the only 2 popular, secure and
> > really commonly used payload encryption schemes, as used in SSL/TLS
> > (web browsers) as well as in Java (Java Cryptographic Architecture -
> > JCA).
>
> My preference is for Blowfish. It's about 3.4 times slower than RC4. I
> trust it a lot more, though (for whatever that's worth).
>
> > Furthermore, how is the licensing situation for RC4, when used
> > commercially outside the US? Schneier writes in Applied Cryptography
> > that RSA would give you a hard time if you try to use it unlicensed,
> > although there's no legal ground to that.
>
> I've not seen this happen to anyone yet. Consider that RC4 is used,
> unlicensed, in just about every web server running Apache with SSL
> support. A fuss would have been kicked up if RSA had tried to do
> anything.
>
> > Are there any serious attacks known against 128 bit RC4?
>
> I think there's cause for concern.
>
> As Tom says, there's an attack which can distinguish a gigabyte of
> output from an RC4 generator from random data. It also manages to
> work out some of the generator's internal state, although not enough to
> matter. (I hope Scott Fluhrer will correct this if it's wrong.)
It's correct (although that's a second attack that ferrots out tiny parts of
the RC4 state). However, Mantin and Shamir pointed out at FSE2001 that the
second attack could be improved somewhat -- they pointed out there there
were more RC4 internal states that leak tiny amounts of information,
although they did not elaborate about how often those occurred.
Unfortunately, it still appears that even with that additional information
leakage, there still isn't enough to mount any sort of attack.
>
> Recently, an interesting phenomenon was noted: the second output byte
> from RC4 is zero with double the hoped-for probability. This attack
> doesn't recover any key material, but it perhaps indicates that the
> algorithm hasn't been subjected to enough analysis yet.
--
poncho
------------------------------
From: "Jack Lindso" <[EMAIL PROTECTED]>
Subject: Re: Wolf's Secure Channel Theorem
Date: Tue, 24 Apr 2001 18:19:52 +0200
Wolf:
>If you went to a foreign country and didn't understand the
> language, the native people around you could communicate securely without
> you ever knowing what was being said.
This is incorrect since in that case you can remember everything which was
said and then learn the language ==> insecure.
For your theorem to work not only does it need be secure, moreover it should
be completely inaccessible by anyone except the originator and the
destination. Notice that it also need be unchangeable by anyone, not by the
originator nor the receiver (thus neither by anyone else), since you can't
be allowed to reject content you sent.
>From the earlier points it can be drawn that such a channel doesn't exist in
our world, or let me rephrase isn't known to exist in our world.
--
Designing the future is all about envisioning the Infinity.
http://www.atstep.com
=============================================================
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9c42hb$87i4$[EMAIL PROTECTED]...
> > Your conjecture is wrong.
> >
> > Proof: Cut the wire!
>
> There are no wires in information space. Humans certainly need a physical
> medium for communication exchange, but having a secure channel and
> communicating over that channel are two different things. In other words
> you could prevent communication from taking place, but if it did take
place
> you wouldn't be able to tell what was said. Let me give you a very real
> world example.
>
>
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 24 Apr 2001 15:49:31 -0000
Subject: Blowfish Advanced - What happened to Blowfish32?
Can anyone help me with this newbie question?
The latest version of Blowfish Advanced no longer has the Blowfish32
algorithm in it. Why is that?
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: OTP WAS BROKEN!!!
Date: 24 Apr 2001 10:00:12 -0600
In article <[EMAIL PROTECTED]>,
Lou Grinzo <[EMAIL PROTECTED]> wrote:
>"You are the more smart in the world."
>
>I think we finally have a replacement for "all your base are belong to
>us" and "someone set us up the bomb." <g>
WHAT YOU SAY??
(Would you believe there's actually a "alt.all.your.base.are.belong.to.us"
newsgroup? I shit you not!)
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
"Konya wa hurricane, baby!" -Priss Nukem
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Tue, 24 Apr 2001 18:00:29 +0200
This is a resume of the discussions I had with Brian Gladman
both in the group and privately with e-mail in the last few
days:
My original post suggested a modification of the scheme of
Wichmann and Hill of combining PRNGs using multipliers of
the form:
c1*r1 + c2*r2 + ....... mod 1
where c1 etc. are values close to 1.0. In a subsequent post
I said that (1) from theoretical consideration the improvement
of the distribution should be very well obtained if one of the
multipliers is exactly 1.0 and that (2) on reasons of
continuity such improvement should also be obtainable even
none of the multipliers is exactly 1.0.
Brian Gladman argued against (2) from theory, where the
distribution c1*r1 + c2*r2 mod 1, with r1 and r2 uniform,
can be shown to be non-uniform. I, on the other hand,
continued to believe that this deviation from uniformity of
the resulting stream would be negligible for practical
purposes, since the multipliers are chosen close to 1.0.
I am indeed mistaken with (2), as the chi-square test with
two pairs of statistically good PRNGs clearly demonstrate
below. In the following, the number of categories used is 100.
N is the sample size. The PRNGs used are indicated by M (mwcg
of Marsaglia), C (cong of Marsaglia), P (of Park and Miller)
and E (of L'Ecuyer).
N M C 0.9M+1.1C 0.9M+1.0C
10^3 99.60 91.40 81.20 91.20
10^4 122.16 107.88 115.88 126.18
10^5 119.03 97.71 153.79 133.10
10^6 126.97 122.15 699.99 115.54
10^7 110.93 95.88 6003.11 108.65
N P E 0.9P+1.1E 0.9P+1.0E
10^3 88.20 108.80 96.20 114.80
10^4 76.72 99.58 101.66 107.98
10^5 78.16 126.05 142.72 109.02
10^6 123.57 88.24 776.08 104.55
10^7 109.62 105.47 6102.31 100.51
The PRNGs M and C are taken from a C++ program code supplied by
Brian Gladman, while P and E are coded by me, with arbitrarily
chosen seeds.
A point that is very worthy of note is that the non-uniformity
of the combination 0.9*r1+1.1*r2 mod 1 is only evident at
sample sizes of the order of 10^5 or larger, which corresponds
to an average entity of 1000 or more per category, while one
commonly reads in textbooks that a very much smaller sample
size would have been sufficient. This means that, in order to
carefully test PRNGs, which is particularly important in the
context of crypto, one should always have a large sample size
combined with a sensitive test for uniformity.
Brian Gladman has ploted with his own computations with M
and C diagrams showing the relationship between the chi-square
values and N in a visually very impressive way. He has also
examined cases where the deviation of the multipliers form 1.0
is as small as 0,025 and found that reliable detection is
even then possible with N=3*10^6. I like to thank him for his
efforts in showing the fallacy of my claim (2).
M. K. Shen
------------------------------
From: "Michael Cock" <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: _Roswell_ episode crypto puzzle
Date: Tue, 24 Apr 2001 17:00:39 +0100
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 24 Apr 2001 06:50:32 GMT, [EMAIL PROTECTED] (Steve
> Roberts) wrote, in part:
>
> >This puzzle (with its million possible answers) prompts me to post THE
> >RIGHT QUESTION which you should ask entities that claim to be visiting
> >space aliens.
>
> Hmm.
>
> 11100100100111011001 is 3444731 octal, or 936409 decimal. (And E49D9
> hex.) So on an octal calculator, upside down, it looks like IELhhhE.
> (On a decimal one, GOh9EG.)
>
> It's much too short to be much of a secret message.
>
> 101010 is 42, is the "right answer", the right question to which it
> was the answer was the goal for which the Earth was created, as we all
> know.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
Split into 5 groups, then convert to decimal, the convert to letters
following a=1, b=2 gives n,d,i,m,i
Is there a character called Ndimi?
Is it a anagram of Mindy, slightly corrupted for confusion's sake, implying
that the TV show isn't as serious as it makes out, but actually aspires to
reach the level of Mork and Mindy?
Could it be the code for a virus that can somehow be entered into an alien
operating system completely destroying their ship and the aliens (too easy
for an ObPuzzle).
Cheers,
Michael
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
