Cryptography-Digest Digest #235, Volume #9 Mon, 15 Mar 99 09:13:02 EST
Contents:
Re: (in)Secure Socket Layer? (Gurripato (x=nospam))
RC4 and keysizes ([EMAIL PROTECTED])
msg digest (Alex)
Cipher for chat program (David)
Re: msg digest (Thomas Pornin)
Re: msg digest ([EMAIL PROTECTED])
pRNG that is "predictable to the left"? (Christoph Haenle)
Re: ElGamal vs RSA (Andrew Haley)
Re: CD Cipher (Paul Onions)
Re: SHA algorithm (Patrick Juola)
Re: Limitations of testing / filtering hardware RNG's (Patrick Juola)
Re: Quantum Computation and Cryptography (Henry Lewsal)
Re: Quantum Computation and Cryptography (Patrick Juola)
Re: Hard problems? (Patrick Juola)
Re: Testing Algorithms [moving off-topic] (Patrick Juola)
Re: Is TEA Algorithm safe???? (dan)
SCIENCE & BUSINESS ([EMAIL PROTECTED])
Re: Factoring large numbers: MPQS algorithm. ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mok-Kong Shen)
Re: Is TEA Algorithm safe???? (Mark Carroll)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: (in)Secure Socket Layer?
Date: Mon, 15 Mar 1999 08:39:42 GMT
On Sat, 13 Mar 1999 19:36:42 +0100, Roy Sigurd Karlsbakk
<[EMAIL PROTECTED]> wrote:
>Hi all
>
>After the DES-III contest
>(http://www.rsa.com/pressbox/html/990119-1.html), I thought about this
>so-called non-domestic SSL. Using 40 bit encryption (128 bit RC-4 with a
>40 bit encryption key - the rest of the bits padded with zeros) seems to
>me quite a little effort to crack. I just asked myself the following
>questions:
>
>DES-56 was brute-forced in 22 hours and 15 minutes = 80100 seconds.
>40-bit whatever algorithm is 16 bit less hard to brute force
>16 bit = 65535
>40-bit encryption could be broken in a matter of seconds (80100 / 65535
>= 1,22) using the same computer power as in the DES-III contest.
>
>1. Is this bull? Or am I right? I know far to little about cryptography
>to know
Basically correct. Now do you understand why Uncle Sam is so
nice as to allow export of 40-bit encryption software? Try the same
maths on a 128-bit key!
>2. Are there any software around that could help me try to brute-force
>this so-called "SSL"?
Bruce Schneier, for example, made a RC2 cracker that worked as
a screensaver. Check his homepage at www.counterpane.com
------------------------------
From: [EMAIL PROTECTED]
Subject: RC4 and keysizes
Date: Tue, 09 Mar 1999 11:37:51 GMT
I would like to know the number of combinations for the session key in RC4.
RC4 works like this:
Pretend there are 256 playing cards, each one unique. How many combinations
of decks are possible? I think it's 256*255*254... or 256! is that right?
(I want to know what the limit on keysizes is, and what would be feasible...)
Thanks in advance,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Alex <[EMAIL PROTECTED]>
Subject: msg digest
Date: Mon, 15 Mar 1999 20:14:56 +1000
hi,
i am looking for a good message digest algorithm i have heard that MD5
and SHA-1 is supposed to be good. what i want is something that
generates a number (preferably 32bit) from a variable length source
message. i know MD5 returns a 128bit number and i have to dig more into
that if i want to use it to decide which bits are more significant.
thanks for your help
alex
------------------------------
From: [EMAIL PROTECTED] (David)
Subject: Cipher for chat program
Date: Mon, 15 Mar 1999 06:37:16 GMT
I'm looking for recommendations for a cipher for a chat
program that I plan to write as a programming experiment. I've
noticed that the theme for the group seems to be specificity, so I'll
try to give you as much information about what I need as possible.
1. the cipher should be free for me to use for any purpose --
including commercial applications, if I choose to release the program
as shareware, etc..
2. The cipher should be 'secure' enough that a colleague, boss, or
system administrator will find it hard to break, even if they save
packets and test keys over a long period of time. (If it also
protects data from the NSA, so much the better! :) )
3. I'm going to be encrypting small packets of data (10-100
characters) repeatedly -- each private session, and each individual
room will have a separate key. (This key may be changed periodically
- say every 10 minutes.) A server for several rooms/channels might
need to encrypt packets many times over, so it should be reasonably
fast. (Of course, chatting bandwidth is pretty low, so it doesn't
have to set any records.)
People here have mentioned RC4 as a good stream cipher, but
I'm just beginning to look into this as a project -- any advice would
be appreciated. (Incidentally, each time a client connects to another
client, or to a server, it will exchange public keys, which will be
used to encrypt randomly generated keys for the stream/block cipher.)
Thanks,
David
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: msg digest
Date: 15 Mar 1999 11:15:06 GMT
According to Alex <[EMAIL PROTECTED]>:
> I know MD5 returns a 128bit number and I have to dig more into that if
> I want to use it to decide which bits are more significant.
If some bits were more significant than others, it would be a serious
flaw in MD5. No such flaw is publicly known for the moment. So you may
choose whatever 32 bits you prefer.
Same comment on SHA-1.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: msg digest
Date: Mon, 15 Mar 1999 11:40:38 GMT
> i am looking for a good message digest algorithm i have heard that MD5
> and SHA-1 is supposed to be good. what i want is something that
> generates a number (preferably 32bit) from a variable length source
> message. i know MD5 returns a 128bit number and i have to dig more into
> that if i want to use it to decide which bits are more significant.
> thanks for your help
I invite you to examine my hash. It can produce 64 or 128 bit outputs. It's
at:
http://members.tripod.com/~tomstdenis/shc.c
All the bits in mine are active, so you can use any 32-bits if you need.
It includes pseudo-code too.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Christoph Haenle <[EMAIL PROTECTED]>
Subject: pRNG that is "predictable to the left"?
Date: Mon, 15 Mar 99 12:31:59
Hi,
I'm looking for a pseudorandom number generator that _is_ predictable
to the left, but unpredictable to the right. Intuitively, if the
random number generator produces values x_1, x_2, etc. I want someone
who knows x_n to be able to recover all previous values, but not the
next ones. Also, given x_n, any x_i, i<n should be _easily_ computable
(that is, no backwards-iteration through x_{n-1}, x{n-2}, should be
needed).
How could I go about? Would the following RSA-based scheme work?
x_1 = {seed}^d mod n
x_2 = {seed}^(2d) mod n
x_3 = {seed}^(3d) mod n
...
(seed is public, the x_i are e.g. 1024 bit numbers). Effectively, to
generate a new value, the generator signs the previous value.
To recover n_i, i<n, one would have to compute {x_n}^(e*(n-i)) mod n.
Is there a vulnerability introduced when signing repeatedly the same
value? How would the padding have to look like? Since I guess there's
already a lot of research done in this area, could someone point out
references please?
TX a lot,
-Chris.
------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: ElGamal vs RSA
Date: 15 Mar 1999 12:57:34 GMT
[EMAIL PROTECTED] wrote:
: In article <7cd013$[EMAIL PROTECTED]>,
: "Roger Schlafly" <[EMAIL PROTECTED]> wrote:
: >
: > [EMAIL PROTECTED] wrote in message <7ccn0j$ltm$[EMAIL PROTECTED]>...
: > > [usual ad hominem attack snipped]
: Asserting that someone does not have the technical background to
: provide an opinion on some subject is not an ad hominem attack.
Certainly not.
However, if you argue against some assertion by attacking the person
who made the assertion, then you have committed the abusive form of
argumentum ad hominem. A personal attack isn't a valid argument,
because the truth of an assertion doesn't depend on the virtues of the
person asserting it.
Andrew.
[Lifted from mathew's alt.atheism FAQ]
------------------------------
From: [EMAIL PROTECTED] (Paul Onions)
Subject: Re: CD Cipher
Date: Mon, 15 Mar 1999 13:06:13 GMT
On Fri, 12 Mar 1999 21:04:57 GMT, [EMAIL PROTECTED] (R. Knauer)
wrote:
>
[...]
>
>The authors go on to discuss the security of the system, which they
>rate as very strong. Later they discuss the two block system I alluded
>to earlier.
I hope they note that the PRNG part needs (at least) to be randomly
salted for each message, otherwise the PRNG and block cipher parts can
be easily attacked seperately with chosen/known plaintext.
(i.e. get the encipherment of a message consisting of identical
repeated blocks - this will (almost) give you the PRNG sequence)
>+++++
>It is important that the two block ciphers should have many
>similarities, just like "twins". This indicates that using only a
>two-key cooperation within one well-designed algorithm seems better,
>but in this approach one has to guarantee that the two keys do not
>specify the same encryption transformation; otherwise there is no
>cooperation within the system.
>+++++
What?!?
Do they detail any rigorous proofs (reductions) for the security of
this, or any other, system?
I only ask because I have just ordered this book myself from Amazon
(thought it looked very interesting from its description at Elsevier),
but now I'm a little concerned (it is VERY expensive).
Paul(o)
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: SHA algorithm
Date: 15 Mar 1999 08:22:16 -0500
In article <[EMAIL PROTECTED]>,
iLLusIOn <Use-Author-Address-Header@[127.1]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hi,
>
> in the book Applied Cryptography, Bruce Schneier describes the SHA
> algorithm like that:
>
> "First the message is padded to make it a multiple of 512 bits long.
> Padding is exactly the same as in MD5: First append a one, then as
> many zeros as necessary to make it 64 bits short of a multiple of
> 512, and finally a 64 bit representation of the length of the message
> before padding."
>
> what I don't understand is what I should do if the message is 488 bits
> for example. The space left (512 - 488 bits) is not enough to store the
> 64 bits which represent the original message length.
> How do messages with such a size get padded to 512 bits?
It doesn't. It gets padded to a *multiple* of 512 bits -- it will
end up being 1024 bits long, most of that in padding.
-kitten
>
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 15 Mar 1999 08:26:29 -0500
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>Jim Gillogly wrote:
>
>> > > > R. Knauer wrote:
>> > > > > If you filter the output as you suggest, then the TRNG is no longer
>> > > > > proveably secure in principle.
>>
>> > > Trevor Jackson, III wrote:
>> > > > Show me the leak. Otherwise stop repeating this nonsense.
>>
>> > Jim Gillogly wrote:
>> > > OK. Just to be definite, let's assume that [you filter the TRNG
>> > > stream so that] there will never be a run of 8 0-bits in a row.
>> > >
>> > > We now have a message coming in. The ciphertext starts "YNAQJ BFPGD".
>> > > ... I can tell with certainty that this message did not
>> > > start with "YES" or "INREP LYTOY".
>>
>> Trevor Jackson, III wrote:
>> > In principle (theory) you are correct. However, in practice it is
>> > meaningless. Consider the 10 character message that you used as an example.
>> > A perfect OTP would allow any plsible decruption of those 10 characters or
>> > N^10 possible decryptions where N is 64 or 256 depending on your alphabet.
>> > Let's say N=64 to give you the maximum benefit of the doubt.
>>
>> I don't care what N is. Let's call it 26 for the purpose of exposition.
>> The point of a OTP is that it leaks no information. As soon as you let
>> it leak even one bit ("this letter is not a Y"), you lose all the theorems
>> and you must start being careful. Let's make my example even more pointed.
>>
>> You are the chairman of the Federal Reserve of the Duchy of Florin, and
>> each day you send a message to all 100 branches of the Federal Reserve
>> bank, each of which has its own OTP to talk to you. The message is
>> one of "UPXX", "DOWN", or "EVEN". I have tapped your outgoing line. If
>> I can tell which way you're moving the interest rate before it reaches
>> the Florinese bourse, I get rich.
>>
>> If you're using a true OTP with each of the branches, I'm out of luck. I
>> can see that you've sent 100 4-letter messages, and that's all. If one of
>> the messages says "DOWN", I shrug, since I know it was by chance. If you're
>> filtering as hypothesized above, I win almost every day with a simple
>> positional frequency count, because the 100 messages will have at most 25
>> letters in each of the four positions. It's a near certainty that one of
>> the letters of the other messages will appear in one or more positions of
>> the ciphertext, and I'll be able to eliminate those messages.
>
>There are several issues here. Let's try to separate them. The first
>consideration of the FRDF example is that all unsalted ciphers are
>vulnerable to similar analysis. On the first three days the tapper
>collects ciphertexts, labeling each with the behavior of the FRDF. On
>or before the fourth day the tapper is going to receive a ciphertext
>whose meaning is known.
No; the original poster specified an OTP as the encoding system used.
In a "correct" OTP, the messages sent from day to day will have no
correlation with each other, and in fact, you might receive the
same message "ZZZZ" on three different occasions whose meaning is
different each time.
-kitten
------------------------------
From: Henry Lewsal <[EMAIL PROTECTED]>
Subject: Re: Quantum Computation and Cryptography
Date: Mon, 15 Mar 1999 05:30:17 -1000
wtshaw wrote:
>
> In article <7ccen1$vog$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> wrote:
>
> > [EMAIL PROTECTED] (Bill Unruh) writes:
> > >In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (R.
> Knauer) writes:
> > >>>I have heard plenty of
> > >>>statements that such NAND gates are possible, that equations have
> > >
> > >Nand gates cannot be reversible. You can create a gate with two output
> > >channels which is reversible.
>
> > >But nothing which takes two inputs and
> > >produces one output can ever be reversible.
>
> Sorry to be difficult, but, and I hate to do this you get an F today in
> digital logic, especially since a basic XOR gate has two inputs and one
> output. As you surely should know, reversible in binary logic means
> knowing the states of two of the three leads, knowing the operative table
> referencing the two inputs and one output, and predicting the unspecified
> state of the remaining lead.
> > >
> > >With a nand gate, you have three input states which go to the same
> > >output. Thus you would need the second output to have three possible
> > >states-- it could not be a binary output.
>
> Three inputs or three states? Neither is descriptive of a NAND gate,
> which is two inputs and two possible states for each input. Considering
> two inputs, there are four total combinations, two bits. Yes each of the
> wires can have a state, one of two per wire. Perhaps you did not realize
> what you wrote, or levet out critical words, as it make no sense.
>
> You can correctly correct any simple logic element and some more
> complicated ones with nothing but NAND gates, 7400's or equivalent chips,
> most often four gates per chip. In design, to efficiently use chips, you
> must sometimes use resident elements to create other gates rather than
> adding chips with excessive sections that might not be used at all.
> Examples would be 1) to use a NAND gate for an inverter, or 2) two NAND
> gates for a bistable flipflop, or 3) a NAND chased by an inverter or NAND
> gate to make an AND gate.
It is important to note that you cannot make a NAND gate with any
number of XOR gates using only their truth tables. You cannot make
a general purpose computer with XOR gates only. You can with NAND gates
only. (You can make a NAND gate with real XOR CMOS XOR gates, a trick
I would like to demonstrate, if you are interested).
NAND alone is not logically reversible because knowing the output
and one input will not uniquely determine the other input :
ab NAND reverse a-out
00 1 ?
01 1 ?
10 1
11 0
XOR is logically reversible :
cd XOR reverse c out
00 0 0
01 1 1
10 1 0
11 0 1
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Quantum Computation and Cryptography
Date: 15 Mar 1999 08:42:09 -0500
In article <[EMAIL PROTECTED]>, Henry Lewsal <[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
>>
>> On 12 Mar 1999 23:44:57 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>>
>> >Nand gates cannot be reversible. You can create a gate with two output
>> >channels which is reversible. But nothing which takes two inputs and
>> >produces one output can ever be reversible.
>>
>> >With a nand gate, you have three input states which go to the same
>> >output. Thus you would need the second output to have three possible
>> >states-- it could not be a binary output.
>>
>> What about a Freidken gate?
>>
>> Bob Knauer
>
>What material is that gate made from? Wishes? Dreams? Hopes?
PVC tubing, billiard balls, and water, if you're willing to accept
a slow enough computer.
What material is an AND gate made from?
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Hard problems?
Date: 15 Mar 1999 08:41:03 -0500
In article <7cfhoi$ti4$[EMAIL PROTECTED]>,
Doggmatic <[EMAIL PROTECTED]> wrote:
>I've seen NP-complete problems, but what's an analogy which describes PSPACE,
>PSPACE-complete, or EXPTIME problems? Assume I know little to nothing about
>number theory, information theory or complexity theory, other than those
>terms.
PSPACE is the set of problems that can be solved on a deterministic
machine without the memory requirements blowing up on you (just as P
is the set of problems that can be solved on a deterministic machine
without the time requirements blowing up on you). A PSPACE-complete
problem is, of course, a problem in PSPACE to which any other problem
in PSPACE can be reduced as a special case.
EXPTIME is the set of problems with time complexity bounded by
an exponential; basically, it's a set of problems so ugly as to
be provably intractable.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Testing Algorithms [moving off-topic]
Date: 15 Mar 1999 08:33:22 -0500
In article <7cfo5j$261$[EMAIL PROTECTED]>,
Doggmatic <[EMAIL PROTECTED]> wrote:
> I thought we established above that "reversible computing" is an ideal that
>can never be achieved. That's when we got into the thing about "closer to
>zero" and "equal to zero." Apparently, (and I could be wrong,) reversible
>computing requires friction equal to zero. You've proponed for many days now
>that engineers will achieve near-zero friction, but I thought we finally
>killed the thing about the feasibility of frictionless surfaces when you
>decided to veer off into an energy argument. I think I'll make my final
>assertions here.
"Fully" reversible compution requires parasitic losses of zero.
This is an ideal and there's no physical reason to believe this
limit cannot be approximated to any desired closeness.
> 1) In the lifetime of this solar syatem, having physically-existant
>computers count to 2^256 is impossible without reversible computing. 2)
>Frictionless surfaces are impossible. 3) Any technology that requires a
>frictionless surface is impossible. 4) (You implied) reversible computing
>requires a frictionless surface. 5) Reversible computing is impossible. 6)
>Since reversible computing is impossible, so is having physically-existant
>computers count to 2^256 within the lifetime of this solar system.
Your first statement is incorrect. Counting to 2^256 will only require
*NEARLY* reversible computing. This, in turn, will require *NEAR*-zero
parasitic losses.
> Hopefully, there aren't any arguments left for you without introducing new
>physical-law-breaking theories. If you must continue the discussion, then
>please, point out the assertion (by number) that you disagree with. Wait.
>Let me go ahead an make sure this discussion is dead.
It's not. Reach a good calculus book sometime about the theory of limits
and get back to me when you understand the idea of asymptotic approximation.
-kitten
------------------------------
From: dan <[EMAIL PROTECTED]>
Subject: Re: Is TEA Algorithm safe????
Date: Mon, 15 Mar 1999 13:41:08 GMT
In article <[EMAIL PROTECTED]>,
"melih" <[EMAIL PROTECTED]> wrote:
> Can anyone tell me if TEA algorithm is safe (I am told it is not safe
> however the reason as to why is what I am after).
>
> If not, does TEA Extensions solve the problems that made the TEA unsafe?
There's a paper by Kelsey, Schneier & Wagner on related key cryptanalysis that
breaks TEA in 2^32 effort, 2^23 chosen plaintexts, and one related key query:
http://www.cs.berkeley.edu/~daw/papers/keysched-icics97.ps
Of the two extensions, Saarinen broke block TEA shortly after it was released:
http://www.jyu.fi/~mjos/break_btea.txt
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: SCIENCE & BUSINESS
Date: Monday, 15 Mar 1999 14:55:52 -0600
New journal: SCIENZA & BUSINESS: Articles, Sponsors, etc.
Reference webpage: http://cam70.sta.uniroma1.it/S&B/home.htm
SCIENZA & BUSINESS aims to provide an actual link between commercial enterprises
needs and academical research .
SCIENZA & BUSINESS publishes papers by writers in Industry, University and in any kind
of business
which has connections to technological innnovation.
The journal is analogous to "American Scientific" with the difference that it focuses
mainly on technology
and business issues. It also features a real link to Academical world, since it is
produced within the University of Rome "La Sapienza".
Some of the topics that are of interest to the journal are the following:
Software Engineering, Telecommunications, Marketing, Market Segmentation,
Data Warehouse, Neural networks, Information Technology, Data Mining,
Computer Programming, applied research, Industry technology, Medicine
Bioengineering, Bioinformatics, Trade and electronic money, Business Intelligence,
Information Delivery, Customer Relationship Managment,
Risk Managment, Credit Scoring, Optimization, etc.
The scientific board of the journal is mainly formed by professors and researchers
both in University
and private companies. Applications for inclusion in the scientific board are
examined.
Papers can be now submitted. Language accepted are Italian and English.
There will we a very strong selection on English papers. Papers must be accompanied
by copious visual material (slides, photos) .
We also welcome sponsors. Some of our sponsors or partners are: SAS Institute,
Minolta, EDS, etc.
Sponsors joining now will be given special privileges.
For information:
mailto:[EMAIL PROTECTED]
http://cam70.sta.uniroma1.it/S&B/home.htm
Send material for possible publication to:
Dott. Tommaso Gastaldi
Dip. Statistica, Probabilit� e Stat. Appl.
Universit� degli Studi di Roma "La Sapienza"
P.le Aldo Moro, 5
00185 Roma
Tel. 39- 06 49910494
Tel. 39 - 06 4073618
Fax. 39 - 06 4959241
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Factoring large numbers: MPQS algorithm.
Date: Mon, 15 Mar 1999 13:53:52 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi everyone,
>
> I am actually doing a study on the factoring algorithms but I still
> have some trouble with the MPQS. I perfectly understand how the basic
> quadratic Sieve works but I don't get the multipolynomial stuff.
>
> If someone knows anything or any site which can tell me more about
> this algorithm (complexity proof - working process in detail), I'll
> apreciate it very much.
See:
R. Silverman
The Multiple Polynomial Quadratic Sieve
Mathematics Of Computation Jan 1987
It tells you everything you need to know.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 15 Mar 1999 09:02:37 +0100
R. Knauer wrote:
>
> What do you mean by "fails"? Statistical tests are only useful as
> diagnostic warnings, not as means of characterizing the proper
> operation of a properly designed TRNG.
The FIPS tests specify intervals where the results should be. If
not the tests fail.
>
> Once alerted to a potential problem, the TRNG must be tested
> internally, like any piece of scientific equipment.
>
> > Are you suggesting stop using the generator
> >or using the sequence nonetheless?
>
> Of course, you would have to stop the TRNG if you were going to run
> internal diagnostic tests on its subsystem. But you can buffer the
> suspect output for subsequent use if it happens that the TRNG was not
> malfunctioning.
>
> What is so wrong about a run? As long as it is not too long, what harm
> can it have? I am assuming that the stream cipher is constructed by
> some kind of strong mixing algorithm that prevents plaintext attacks -
> the Simple OTP is not suitable since its additive mixing algorithm
> (the XOR operation) exposes plaintext with a null key, and exposes the
> key itself if the plaintext is known. If the OTP is created from a
> stong mixing algorithm, how is the cryptanalyst ever going to know
> that there was a run in the key?
The problem is that any good system may malfunction, e.g. due to
hardware problems. That's why, I suppose, you want to have diagnostic
warnings. If you obtain your dignostic warnings, my question was what
would you precisely do, i.e. stop using the generator for the moment
and investigate to see if there are troubles (which may take much
time and hence halts the application) or ignore the warnings and use
the sequence nevertheless. You didn't seem to have focused your
answer to that. And a more fundamental question is how can you
ensure that there are indeed no troubles and prove that the
warnings are merely false alarms.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Carroll)
Subject: Re: Is TEA Algorithm safe????
Date: 15 Mar 1999 14:06:41 +0000 (GMT)
In article <[EMAIL PROTECTED]>, melih <[EMAIL PROTECTED]> wrote:
>Can anyone tell me if TEA algorithm is safe (I am told it is not safe
>however the reason as to why is what I am after).
>
>If not, does TEA Extensions solve the problems that made the TEA unsafe?
I can't remember what the breaks are but the papers seem fairly
well-known. Nothing too damning, but enough.
I'm not aware of any serious problems with XTEA, though. Is anyone else?
-- Mark
------------------------------
** 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
******************************
