Cryptography-Digest Digest #181, Volume #14 Thu, 19 Apr 01 09:13:00 EDT
Contents:
Re: Prime Numbers Patterns? ("Douglas A. Gwyn")
Re: OTP breaking strategy ("Douglas A. Gwyn")
Re: "UNCOBER" = Universal Code Breaker ("Jack Lindso")
Re: First cipher (Mark Wooding)
Re: Proof of RSA (Mark Wooding)
Re: OTP breaking strategy ("Jack Lindso")
Re: OTP breaking strategy ("Tom St Denis")
Re: First cipher ("Tom St Denis")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Re: OTP breaking strategy (John Savard)
Re: "UNCOBER" = Universal Code Breaker (Richard Heathfield)
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: OTP breaking strategy (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Prime Numbers Patterns?
Date: Thu, 19 Apr 2001 11:12:40 GMT
Wizartar wrote:
> Is there any logic to prime numbers, ...
There must be, since any mathematician will agree that they're
rational numbers.
> All numbers ending in 0, 2, 4, 5, 6, 8, once you get above 9 are
> defiantly not a prime numbers.
You should note a relationship between those digits and the
base (10) you seem to be using to express numbers. Instead
of worrying about primes in general, which is much too hard
a problem, perhaps you should concentrate on explaining this
relationship. That's a more suitable pre-collegiate task.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 11:16:29 GMT
newbie wrote:
> You think that I do not know what I'm talking about.
> You have the right to think so.
Indeed, we have the obligation to think so, based on the ample
evidence you have given us.
------------------------------
From: "Jack Lindso" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 14:14:49 +0200
> While I actually agree with you, the above line of reasoning seems
> to make some assumptions that might not be correct. We know of many
> examples in other fields where a general theory has been easier to
> find than a specific theory.
It's almost always more difficult to find a general algorithm/theory rather
then a specific one, however it is also much more enlightning finding the
general theory. In any case a general theory should always exist for a
specific problem if that problem is solvable with a specific algorithm.
--
Designing the future is all about envisioning the Infinity.
http://www.atstep.com
=============================================================
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jim Gillogly wrote:
> > since we don't have practical special-purpose attacks on many of the
> > modern ciphers, it's way premature to talk about a general attack
> > that solves all of them.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: First cipher
Date: 19 Apr 2001 11:21:14 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Here's my first attempt at a block cipher. Please critique
> and explain WHY as well as where I'm going wrong.
Who said that dinosaurs are dead? This is DES, bigger than ever...
> 1.) Feistel network, blocklength 64 bits, 128-bit key, 16 rounds
Fair enough.
> 2.) Key schedule to create 16 64-bit subkeys
> a. Split key into two 64-bit subkeys (k1, k2).
> b. To generate the next two subkeys, permute
> k1, k2 then left circular shift (LCS)
> the result of each permutation. The number of
> shifts is determined by the value of two bits
> (say b1,b0 for example) from the permutation output.
> The result of the k1 permutation, LCS(b1,b0) becomes k3.
> The result of the k2 permutation, LCS(b1,b0) becomes k4.
> c. Repeat (b) until 16 64-bit subkeys are obtained.
>
> Is the LCS(b1,b0) necessary? I wondered if a simple permutation
> would be sufficient since the key is assumed to be random and
> secret...
This is not a good idea. The problem is that you're using real key bits
in the cipher. If an attack discovers some bits of a round key, it's
actually found some real bits of the key, and therefore bits of other
round keys. The rotations make life a little more difficult but not a
lot. I think you want something with more one-wayness.
Also, there's very little communication between the two halves of your
key. I think that's a bad idea. The DES key schedule is a marvellous
piece of minimalist design, but emulating it is extremely dangerous.
> 3.) Function (operates on 32-bit half of 64-bit plaintext block)
> a. Permute
>
> b. E-box which permutes and expands 32 bits to 64 bits
>
> c. XOR with 64-bit subkey
>
> d. Compression substitution (64 bits to 32 bits)
> Eight bits from (c) are chosen, say b7,b6,...,b0
> Two bits, say b1,b0 chose one of four S-boxes. Each S-box
> is an 8x8 matrix with 4-bit elements which are chosen
> randomly. Three other bits, say b4,b3,b2 , choose the
> S-box row, the last three bits choose a S-box column.
>
> The process is repeated on 8 different bits from (c), etc.
>
> e. Left circular shift the output from (d) with the number
> of shifts determined by two bits from the subkey.
>
>
> The output of (e) is the input to the Fiestel network...
>
>
> Any hints on how to analyze security and efficiency would be
> appreciated.
I don't have enough information to actually show particular attacks
against this. Too little of the interesting stuff isn't actually
specified.
Moving the permutation (a) to after the substitution (d) will make the
cipher faster in software. You can pre-apply the permutation to the
entries in the S-box table. Otherwise, bit-permutations become quite
expensive.
The expansion in (b) is effectively free in both software and hardware.
The structure in (d) looks like one big 8-to-4-bit S-box to me. So
there's just one S-box, which is used everywhere. This isn't a
disaster, but see below for what I think is a better idea. (The
structure of the narrowing S-box needs to depend on the preceding
expansion.)
I think step (e) is a bad idea. It complicates analysis, and could
introduce unwanted weaknesses. The varying rotations in the key
schedule are probably a good idea, though -- they will protect against
related-key attacks.
Once you've done that, your cipher is exactly as efficient as DES in
software, and probably not far off in hardware (except that the table is
larger).
Now for the picky details. The security of this system depends on the
exact choices of your permutations and S-box.
The expansion will help a bit here. I assume that this is a DES-like
expansion where single input bits are made to affect multiple S-box
lookups. I think I'd recommend a full overlap here: the inputs to the
S-boxes should be bits 0-7, 4-11, 8-15, 12-19, 16-23, 20-27, 24-31,
28-3. I think that's the best you can do.
I'd suggest a different structure for your S-box in the light of this.
The S-box should probably select one of 16 bijective mappings using the
outermost four bits of the input byte, and push the innermost four bits
through this map. This means that each bit is used (a) to select a
bijective map for some other bits, and (b) pushed through such a map
itself. I'd recommend having more than one such S-box, though -- at
least two, alternating across a round.
Don't choose the S-box mappings completely at random. You need to
design the S-box and permutation at the same time. The most difficult
problem is that the F function as a whole can't be bijective. You need
to ensure that the maximum probability of a differential x -> 0 through
F is 2^-10 or less. That's a tall order. The fact that the expansion
gives complete overlap (unlike DES, which has only 50% overlap) protects
your cipher from t_i -> t_j differentials which are usually an inherent
problem with DES-style S-P networks. A single-bit change in the input
to F will definitely affect the input to two S-boxes.
Good luck.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Proof of RSA
Date: 19 Apr 2001 11:26:59 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> One example which springs to mind is the RSA variant (proposed by Takagi)
> where the modulus is not square-free: the modulus might be p*p*q.
> Obviously, given any plaintext of the form k*p*q, you always get a
> ciphertext of 0, and therefore in that system, D(E(M))=M is *not* a theorem.
I like that. It gives you a handy nudge to tell you when you've
accidentally factored the modulus. ;-) (At least that shows that the
function is bijective with high probability.)
-- [mdw]
------------------------------
From: "Jack Lindso" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 14:28:18 +0200
There is one thing you forgot, its not a proper text or a language, those
are bits {0,1} which are passed throe F (which can be and usually is XOR)
permuted with a
<!RANDOM!> OTP >> ~ an Infinite number of results dependant on the OTP.
--
Designing the future is all about envisioning the Infinity.
http://www.atstep.com
=============================================================
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It is hard to break OTP but not impossible.
> Let me explain my strategy. You think that I do not know what I'm
> talking about.
> You have the right to think so.
>
> 1. What the crypto is able to know before trying to crack OTP
> Hypothesis :
> a. The plaintext is correct english or french or any other language.
> b. The plaintext is relating to specific domain ( business, bank,
> geology, etc...)
> c. The cryptanalyst could distinguish between truely random sequence and
> non random sequence.
> d. The cryptanalyst could know semantic sequence ( noun, verb, etc..)
>
> 2. How could he resolve OTP encryption ?
>
> a. Build or use bit-string database specific to a domain related to OTP
> encryped message.
> If it is business, he can use database of words, sentences specific to
> business. Every database is
> ordered ( the more occurent to the less occurrent )
>
> b. How decrypting algo will work?
>
> Conditions :
> 1. ciphertext is 00101010001111010010010001001001000100100......
> 2. length of ciphertext bit-string = n
>
> Algo
>
> First step : (goal : see if output is random or not )
>
> 1. pick the more occurent words or sentences
> 2. slide the bit-string bit by bit ( input ) from the position 1 to [n -
> (length of words or sentence )]
> 3. for every position compute the word or the sentence with ciphertext
> using XOR.
> Sample
>
> ciphertext = 0 0 1 0 1 0 1 0 0 0 1 1 1
> 1010010010001001001000100100......
> first try (input) 1 0 1 0 0 1 0 1 0 0 0 1 0 1 0........
> Xor (output) 1 0 0 0 1 1 1 1 .....
>
> 4. Check if output is random or not.
> 5. If it is random assign value 1 to the first position of the input
> then else 0.
>
> 6. Continue sliding the input at the right (positon 2) ...do the same
> operation until [n - (length of words or sentence )]
>
> 7. When you finish with the first input you input the second using the
> same operations.
>
> 8. You do that until you finish your database.
>
> At the end of this step you will a large table with :
>
> lines = words and sentences ordered (i)
> column = positions from 1 to [n - (lowest length of words or sentences
> (j)
> x( i,j ) is the value 0 or 1 ( truly random or not )
>
> Second step of selection ( goal -> valid position or not)
>
> 1. For the first check if its position is unlikely valid or not
> Sample : word = credit "
>
> The word credit is unlikely to be the starting -> the value is 0, I
> change on my table the previous value if it is 1
> then else no change
> 2. the second position I check semantically valid or not etc....
> 3. I repeat until the last position.
> 4. I repeat the same previous operations for the folowing words and the
> sentences on my table.
>
> Third step ( goal -> combinig the words and the sentences to form a
> sentence that have a sense )
>
> This step is the more difficult because it is not easy to compute it
> without looking at the table and choosing
> manually witch words and sentences to combine.
>
> I think that this strategy have to be more analysed to allow to insert
> in every step appropriate sub-algo.
> The deciphering need a work team with linguist, domain expert (
> business, bnk, etc..) and statistician.
> My strategy have to be improved. I know that.
> OTP is not unbreakable.
>
>
>
>
>
>
>
>
> .
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 11:33:57 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It is hard to break OTP but not impossible.
> Let me explain my strategy. You think that I do not know what I'm
> talking about.
> You have the right to think so.
Believe what you want it was proved a long time ago that an OTP is not
breakable. Why not read up on it in applied crypto or HAC?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 11:41:05 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Here's my first attempt at a block cipher. Please critique
> and explain WHY as well as where I'm going wrong.
I used todo this. You should try to include your own cryptanalysis as well.
Even if you don't have breaks you should include "I think this area is where
I would attack".
> 1.) Feistel network, blocklength 64 bits, 128-bit key, 16 rounds
>
> 2.) Key schedule to create 16 64-bit subkeys
> a. Split key into two 64-bit subkeys (k1, k2).
> b. To generate the next two subkeys, permute
> k1, k2 then left circular shift (LCS)
> the result of each permutation. The number of
> shifts is determined by the value of two bits
> (say b1,b0 for example) from the permutation output.
> The result of the k1 permutation, LCS(b1,b0) becomes k3.
> The result of the k2 permutation, LCS(b1,b0) becomes k4.
> c. Repeat (b) until 16 64-bit subkeys are obtained.
>
> Is the LCS(b1,b0) necessary? I wondered if a simple permutation
> would be sufficient since the key is assumed to be random and secret...
LCS? That's not a standard function AFAIK. A circular (or cyclic) shift is
denoted by <<< or >>>. What does LCS(x,y) mean?
> 3.) Function (operates on 32-bit half of 64-bit plaintext block)
> a. Permute
>
> b. E-box which permutes and expands 32 bits to 64 bits
>
> c. XOR with 64-bit subkey
>
> d. Compression substitution (64 bits to 32 bits)
> Eight bits from (c) are chosen, say b7,b6,...,b0
> Two bits, say b1,b0 chose one of four S-boxes. Each S-box
> is an 8x8 matrix with 4-bit elements which are chosen
> randomly. Three other bits, say b4,b3,b2 , choose the
> S-box row, the last three bits choose a S-box column.
>
> The process is repeated on 8 different bits from (c), etc.
This will suffer badly from differential attacks IMHO. Unless you
design your sboxes very carefully. Also standard terminology for a 256
element array with 4-bit elements is a 8x4 not 8x8. Unless your rows and
columns are very independent of each other (and differentially distanced
too) this will be easy to break.
> e. Left circular shift the output from (d) with the number
> of shifts determined by two bits from the subkey.
This is crytographically useless since a differential attack will make the
same output differences in the same spots... (rotate is key constant).
> The output of (e) is the input to the Fiestel network...
>
>
> Any hints on how to analyze security and efficiency would be
> appreciated.
Well first why do you expand to 64 bits in your round function? Typically
it's idea to make your round function a bijection.
I would read up on cryptanalysis too..
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 11:42:25 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > All equal sized messages are equal probable,
>
> No, they're not.
I meant thru the OTP.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 11:43:11 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > An OTP is not possible to break since all messages are equally
> > probable.
>
> No! No wonder the newbie is so confused.
What? All solutions are equal probable since all keys are equal probable.
That's why the OTP is secure.
Tom
------------------------------
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: Thu, 19 Apr 2001 14:37:29 +0200
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > ... Now please present
> > your chi-square results in an easily understandable
> > way in conformance with common practice. Please use
> > confidence level of 0.95 or higher.
>
> I recommend presenting the inverse-chi-square (e.g. using the
> QChiSq function found in my ihat archive). That way the same
> result can be directly compared to whatever significance level
> the user chooses.
Could you say a bit about your 'ihat archive'? (How to
access that? Are there documents about the inverse-
chi-square?)
>
> > It is generally preferred to have a larger number of categories
> > rather than fewer categories and large number of entries per
> > categories,
>
> No. For hypothesis testing, the strongest result (best
> discriminating ability) occurs when all the available information
> goes into a simple yes/no determination (2 categories).
>
> A rule of thumb is that Pearson's chi-square test often gives
> misleading results if there are not at least 5 counts in each
> bucket.
Sorry, either I misunderstood you or you misunderstood
the current context. The current discussion is about
testing the 'uniformity' of the output of PRNGs (or
post-processed outputs of these), i.e. streams of
real-valued numbers in [0,1). Do you mean using just
two categories, i.e. [0,0.5), [0,5,1) in the chi-square
test to determine whether a stream under study is
uniform or not? (I suppose certainly not.)
M. K. Shen
------------------------------
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: Thu, 19 Apr 2001 14:38:52 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >Bryan Olson wrote:
> >>
> >> Mok-Kong Shen wrote:
> >> > Mok-Kong Shen wrote:
> >> > > The PRNGs are assumed to be independent (I forgot to
> >> > > explictly say that) and uniform.
> [Snip...]
> >> > Addendum: The scheme of Wichmann and Hill is intended
> >> > to get a more uniform stream from a number of not well
> >> > uniform streams.
> [...]
>
> [Bryan]
> > You now say the
> > intentions contradict what you just said was assumed.
>
> > 'What' I said contradicts 'what' I assumed?
>
> Yes. The edits above should make that clear.
You snipped the part that is essential for the point
you raised here. So I reproduce that below:
Addendum: The scheme of Wichmann and Hill is intended
to get a more uniform stream from a number of not well
uniform streams. The assumption I made above that
the PRNGs are uniform is for discussion of the
theoretical point you raised which I quote below:
The modification destroys an important property of
the basic combination method: as long as the streams
are independent, if any of the streams are uniform
then the sum is uniform.
So in that situation we assume that there are uniform
streams to start with.
Essential is my last sentence above. The quote from
you mentioned 'uniform'. Actually the scheme of Wichmann
and Hill is intended to get more uniform streams from
not so uniform ones. So we couldn't, strictly speaking,
argue about your quote (and hence your claimed
'distruction') at all, since we don't have any 'exactly'
'uniform' streams. (Should I on this ground have said that
the material of your quote is 'irrelvant' and stopped the
discussion on that with you?) On the other hand, it is
obvious that the theorem involved in you quote above is
'theoretically' interesting, for it forms the base on
which the scheme of Wichmann and Hill is oriented (just
like a good pseudo-random bit sequence is oriented
towards the theoretical ideally random sequence).
Therefore, in order to avoid general readers wondering
why we started to discuss about 'uniform' while there is
no exact uniformity present, I put out the addendum. Is
that clear to you now?
>
> >> No. You stated a bogus result. What evidence we have
> >> indicates that your it's false.
> >
> >'What' is the bogus result?
>
> "thus rendering the analysis more difficult." There is no
> support for this assertion in the note or in the follow-ups.
The original Wichmann and Hill scheme gives e.g.
R = r1 + r2 + r3 mod 1
The modified one gives
R = c1*r1 + c2*r2 + c3*r3 mod 1
What the opponent has is R. Assuming he had a method
to get the components r1, r2 and r3 from R, he would
have more difficulty to do in the second case, since
the c1, c2 and c3 are unknown to him, isn't it? (He
has somehow to determine these unknowns.) One could
certainly dispute about how much is that 'more'. But
that there is some 'more' should be evident.
>
> >'What' is the evidence?
>
> As stated in the strand. The modification throws away
> important properties of the scheme. The resulting stream
> can come out worse than an individual component stream.
Partly covered above. For the rest: See my follow-up
to Brian Gladman, who claimed essentially the same as
you but in a more concrete way. I have asked him to redo
his chi-square tests and present the results. As said
there, I never exclude the possibilty of my making
blunders, anywhere, anytime. But I want to see concrete
refutations rather than fuzzy categorical claims of
my being wrong without any accompanying supporting
materials. So have patience. Since Brian Gladman needs
only to modify a little bit of his program, I am very
confident that we'll soon be able to clearly know who
is right and who is wrong.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 12:44:43 GMT
On Wed, 18 Apr 2001 18:29:23 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>c. The cryptanalyst could distinguish between truely random sequence and
>non random sequence.
Truly random OTP + any secret message = truly random ciphertext;
hence "c" won't enable one to even guess a single letter of the
plaintext, despite knowing (somehow) the plaintext adjacent to it, if
there is more than one possibility:
truly random ciphertext - any guessed secret message = another truly
random OTP, just as good as the real one
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Thu, 19 Apr 2001 13:25:45 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Tom St Denis wrote:
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> > > An OTP is not possible to break since all messages are equally
> > > probable.
> >
> > No! No wonder the newbie is so confused.
>
> What? All solutions are equal probable since all keys are equal probable.
> That's why the OTP is secure.
I think Doug would (probably) agree with that. But there's a difference
between saying all *keys* are equally probable and saying that all
*messages* are equally probable.
Here are two messages of equal length, unencrypted. Which do you think I
am more likely to send in a private email, or do you think they are
equally probable?
"Hi Dennis, I've had a look at your code and I think I found the bug.
I've uploaded a patch to the server."
"fsu98rsghgy8f48ls3fh4s usfs 9elfulsefu4 sefu4sljrfjdxg89 gh58 94gh589
wgh8sl i8e g5h8gh85 sgh589 wsg438 4"
Not all messages are equally probable.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 12:51:04 GMT
On Thu, 19 Apr 2001 11:06:00 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>While I actually agree with you, the above line of reasoning seems
>to make some assumptions that might not be correct. We know of many
>examples in other fields where a general theory has been easier to
>find than a specific theory.
This is true. Since ciphers can make use of a wide variety of
mathematical constructs as primitives, though, a universal code
breaker that could do something useful against any breakable cipher
would also revolutionize data compression - and mathematics in
general.
Still: the Lempel-Ziv algorithm comes close to a universal data
compression algorithm, although it certainly can't compress an
encrypted file by figuring out how to decrypt it, and then saving the
key, a description of the algorithm, and the compressed plaintext as
the compressed version. Even, therefore, a "universal" cipher breaker
that just works against the sort of things in Gaines might be of
interest, and perhaps something on _that_ level (not simply a library
of specialized breakers for each cipher) would be possible.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 15:00:51 +0200
Volker Hetzer wrote:
>
> newbie wrote:
> >
> > It is hard to break OTP but not impossible.
> > Let me explain my strategy. You think that I do not know what I'm
> > talking about.
> Right.
> Now, here's your chance of getting the nobel prize in maths:
[snip]
He might decline on the ground that there is no Nobel prize
in maths. But I believe that plenty of readers of the group
would be ready to donate some money to form a very
attractive prize for his sensational success of breaking
the OTP.
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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
