Cryptography-Digest Digest #688, Volume #9 Thu, 10 Jun 99 13:13:03 EDT
Contents:
Re: Shared secret protocol (David P Jablon)
Re: ATTN: Bruce Schneier - Street Performer Protocol (Jim Felling)
Re: Anonymous comments on Street Performer Protocol (was: ATTN: Bruce...) (Alan
Braggins)
Re: Cracking DES (Patrick Juola)
Cracking DES (Greg Bartels)
FREE HARDCORE TEEN PICS 3223 ([EMAIL PROTECTED])
Re: Looking for a password encryption algorithm (Sundial Services)
Re: DES (Thomas Pornin)
Re: Cracking DES (Gordon Grieder)
Re: being burnt by the NSA ("Renegade")
Re: Key lengths vs cracking time (Sundial Services)
Re: rc4 vs. rand() (Michael J. Fromberger)
Re: One Time Pad (John Savard)
Re: Looking for a password encryption algorithm (David P Jablon)
Re: Key lengths vs cracking time (Bob Silverman)
Re: rc4 vs. rand() (Jim Felling)
Re: Looking for a password encryption algorithm (David P Jablon)
Re: Does scott19u.zip make full use of it's large key size ? ([EMAIL PROTECTED])
Re: One Time Pad (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Shared secret protocol
Date: Thu, 10 Jun 1999 15:28:51 GMT
In article <7jmhnq$[EMAIL PROTECTED]>, Logic <[EMAIL PROTECTED]> wrote:
>
>I am looking for a particular shared secret protocol which I have not seen
>described in any literature I have. I would appreciate any comments,
>pointers or discussion. I describe the basic setup and the requirements,
>followed by a boring solution to serve as a reference.
[... description snipped.]
In general, since you're encouraging users to memorize
the shared secrets, you'll want to consider the susceptibility of
the system to brute-force attack on the database and
on the network.
Incorporating zero-knowledge password proofs will help.
Papers at <www.IntegritySciences.com/links.html>
-- dpj
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ATTN: Bruce Schneier - Street Performer Protocol
Date: Thu, 10 Jun 1999 10:17:14 -0500
What paper is this in reference to? Please provide a citation or URL. Thank
you.
[EMAIL PROTECTED] wrote:
> <snip>
>
> Hey mr. 'Anonymous' if that is your real name, shut up. Although his
> paper is vague and not well read I would not jump up and down on him.
> He has done stuff that you (and I) cannot even comprehend at this stage.
> He is known for breaking half a dozen or so algorithms and has designed
> two very good encryption algorithms.
>
> I think the paper was a flop, but who am I to say so. BTW I think the
> only big solution for the music piracy would be to encrypt each cd alone
> then pass decryption codes in the music insides...
>
> This would be slow but curve the piracy. If you had to register the
> music you buy (good god!) then piracy can be curbed. Unless of course
> you can remove id information from the cd.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: Anonymous comments on Street Performer Protocol (was: ATTN: Bruce...)
Date: 10 Jun 1999 16:06:46 +0100
[EMAIL PROTECTED] (Larry Kilgallen) writes:
> > under a pseudonym. The proposal on the website
> > I just saw is INCREDIBLY NAIVE on your part.
>
> If this was private mail to Bruce, you typed the wrong command.
>
> If this was intended as a public comment, you should indicate
> the web site to which you refer. I found nothing relevant to
> your comments on the page http://www.counterpane.com/ .
http://www.counterpane.com/street_performer.html
"ABSTRACT: We introduce the Street Performer Protocol, an
electronic-commerce mechanism to facilitate the private financing of
public works."
Fits his title. I haven't read the protocol, so I've no idea if
it the comments fit. I can't see an obvious link from the front
page, but the page was the first hit on an AltaVista search for
"Street Performer Protocol". The page says "November 1998", so
it was probably better publicized at the time.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Cracking DES
Date: 10 Jun 1999 11:44:45 -0400
In article <[EMAIL PROTECTED]>, Greg Bartels <[EMAIL PROTECTED]> wrote:
>Since I forgot to bring in the book, I cant remember the
>specifics, but I think a million bucks would build a machine that
>would crack a DES key in an hour or two. multiply the value of the
>key times the length of time you want to run the machine, and you
>can probably easily recover the cost of building the machine.
>
>3DES may be more secure, but it seems to me that the old claims
>of 1DES would take more time to crack than the universe is old
>and then the reality of a million bucks and a couple hours,
>makes me question any claims about 3DES, which just uses
>the exact same algorithm, and just runs it three times.
Well, first, to the best of my knowledge, there have never been any
published claims that single DES would require 'more time to crack
than the universe is old'. In point of fact, the original (Lucifer)
design used a larger key with was actually *reduced* to create the
56-bit key used in DES. This design decision was instantly criticized
because a 56-bit key was believed too small. Elementary math gives us
that there are about 10^19 keys in DES; the universe is approximately
10^17 seconds old, so you could crack 1DES 'within the time the universe
is old' using one of Alan Turing's old Enigma machines. And this
was known (and argued about) in the mid 1970s.
3DES, however, is as much harder to crack that DES itself as DES itself
is harder to crack than simply reading plaintext. 3DES uses a key
twice as long, which means the keyspace isn't just twice as big,
but 2^56 (or 10^19) times as big. Increasing key space increases
search time by a *much* larger factor than simple linearity.
>is there no serious contender for a block algorithm that
>would provide security against the next century or so of cracking
>advances?
There are several -- of which 3DES is one; eighty years of Moore's law
(which no one expects to hold that long) will *only* succeed in making
3DES then as difficult to crack as 1DES is today. But there are also
several others, of which Bruce Scheier's _Applied Crypto_ describes
a few of the leading candidates. To which you are referred. 8-)
-kitten
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: Cracking DES
Date: Thu, 10 Jun 1999 09:35:48 -0400
I remembered to check my bookshelf last night, but then forgot to bring
the
book in this morning. the name of the book is "Cracking DES", not
"Breaking DES", as I had thought. must of been some bit flipping going
on in the brain.
it was published by the Electronic Frontier Foundation.
http://www.eff.org
it contains a foreword by Whitfield Diffie, which says,
"It ("Cracking DES") describes a computer built out of custom
chips. A machine that 'anyone' can build; from the plans it presents
--- a machine that can extract DES keys in days at reasonable prices,
or hours at high prices. With the appearance of this book and the
machine it represents, the game changes forever. It is not a question
of whether DES keys can be extracted by exhaustive search; it is a
question of how cheaply they can be extracted and for what purposes."
Since I forgot to bring in the book, I cant remember the
specifics, but I think a million bucks would build a machine that
would crack a DES key in an hour or two. multiply the value of the
key times the length of time you want to run the machine, and you
can probably easily recover the cost of building the machine.
3DES may be more secure, but it seems to me that the old claims
of 1DES would take more time to crack than the universe is old
and then the reality of a million bucks and a couple hours,
makes me question any claims about 3DES, which just uses
the exact same algorithm, and just runs it three times.
is there no serious contender for a block algorithm that
would provide security against the next century or so of cracking
advances?
is there nothing being worked on to replace DES?
what is this newsgroup for if not that?
Greg
"I'm not a cryptographer (but I play one on TV)"
Greg Bartels wrote:
>
> Patrick Juola wrote:
> >
> > In article <[EMAIL PROTECTED]>, Greg Bartels <[EMAIL PROTECTED]> wrote:
> > >I bought a book, a couple months ago, its title was
> > >"Breaking DES",
> > >
> > >it contains VHDL code (in a scanner/OCR friendly format, no less)
> > >which compiles to build a DES cracking machine.
> > >The claim was that the machine would cost $200,000 to build
> > >and would recover a DES key within 2 weeks.
> > >
> > >really fuzzy on the specifics, going from memory.
> > >exact title, cost claims, and cracking speeds may differ
> > >from actual reality.
> > >
> > >I'll look it up tonight.
> >
> > Ooooh, *BAD* title. Most people don't regard exhaustive enumeration
> > of the DES keyspace as a "break", simply because the keyspace is so
> > obviously small and DES is so obviously being used past its designed
> > lifetime.
> >
> > As it happens, I believe that Linear Cryptanalysis (discussed briefly
> > in Schneier's _Applied Crypto_) constitutes a "break" in the more
> > accurate sense; it's requires less work to break a DES key via
> > LC than via brute force.
> >
> > But, as was pointed out earlier, there's always 3DES...
> >
> > -kitten
>
> 1) I'll double check the title tonight, so that might be
> inaccurate.
>
> AM I THE ONLY PERSON WHO"S HEARD OF THIS BOOK?
> or is the book a load of bull?
>
> 2) $200,000 to get any DES key in 2 weeks, may or may not be
> considered "breaking DES", but if you happened to be in the
> buisness of breaking, say, bank keys, you could probably
> recover you're money within the year.
>
> 3) I think it might have mentioned that further improvements
> would make the system both cheaper and faster.
> they gave specifics, but I cant remember what they were.
> I seem to remember the book saying recovery time could
> be a couple days.
>
> If I remember, I'll look it up tonight.
>
> waiting for iButtons with megabit one time pad storage,
> a 8+ character password to decrypt the OTP, and a USB port to
> upload/download the key. I'll give one to each of my friends.
>
> Greg
------------------------------
From: [EMAIL PROTECTED]
Subject: FREE HARDCORE TEEN PICS 3223
Date: 5 Jun 1999 06:46:47 GMT
FOR THE BEST FREE TEEN SEX PICTURES VISIT:
http://freespace.virgin.net/eric.johnston/freepics.htm
slbbsyfkgrgtzkktwgugowumkgltkbylpy
------------------------------
Date: Thu, 10 Jun 1999 08:42:14 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Looking for a password encryption algorithm
> In <7jo0aj$di6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> : I am looking for a simple password encryption algorithm
> : similar to unix crypt(). I want to implement in my own
> : simple authentication project.
>
> : I dont know where I can get resources / papers ?
It's worth noting that the approach used by "crypt," long-abandoned in
most password systems, has the problem that the password -can- be
recovered.
A far stronger approach is to use a so-called "one way hash function,"
which produces a thoroughly mixed up jumble of bits from which the input
data cannot be deduced. All you can do is take the user's input,
subject it to the same hashing, and see if the result is precisely the
same as what you expect. The answer is either "yes, it is exactly the
same, so the password is valid," or "no, it does not match, so it's not
the right password and I have no way of knowing how close to right it
was."
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: DES
Date: 10 Jun 1999 15:42:29 GMT
According to Paul Koning <[EMAIL PROTECTED]>:
[initial and final permutations in DES]
> Fortunately, there are ways to do it in software that aren't all that
> expensive.
Bitslice comes to mind. Since this is only routing of data, it is free.
However, bitslicing is really efficient for DES only when enciphering a
big block of data in ECB mode, or when programming a password-cracker.
--Thomas Pornin
------------------------------
From: Gordon Grieder <[EMAIL PROTECTED]>
Subject: Re: Cracking DES
Date: Thu, 10 Jun 1999 09:54:51 -0500
Greg Bartels wrote:
>
> I remembered to check my bookshelf last night, but then forgot to bring
> the
> book in this morning. the name of the book is "Cracking DES", not
> "Breaking DES", as I had thought. must of been some bit flipping going
> on in the brain.
>
> it was published by the Electronic Frontier Foundation.
> http://www.eff.org
> it contains a foreword by Whitfield Diffie, which says,
>
> "It ("Cracking DES") describes a computer built out of custom
> chips. A machine that 'anyone' can build; from the plans it presents
> --- a machine that can extract DES keys in days at reasonable prices,
> or hours at high prices. With the appearance of this book and the
> machine it represents, the game changes forever. It is not a question
> of whether DES keys can be extracted by exhaustive search; it is a
> question of how cheaply they can be extracted and for what purposes."
[snip]
There is a scanned version of "Cracking DES" at
http://www.replay.com/mirror/cracking_des/cover.html
(I assume this is in compliance with the "Scan this book" line on the
cover.
------------------------------
From: "Renegade" <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Thu, 10 Jun 1999 10:43:44 -0500
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Renegade wrote:
> > > The total US national foreign intelligence program budget is about
> > > $27 billion, of which about $3.1 billion goes to CIA and about
> > > $3.6 billion goes to NSA. NRO gets about $6.2 billion.
> > What is the source? Are budgets public information now? This looks
> > like a shell game to me, those numbers seem to be way out of whack.
>
> Why do we care how it seems to you?
OK I give up. Why do we care? Obviously you care, or you would not have
responded. Thanks for your kindness.
> The CIA did publish the total NFIP budget for FY97 and FY98.
Yes I knew that. It was the breakdown I was unaware of.
> The breakdown by agency comes from a public watchdog group,
> which you could find for yourself, but it is fairly close
Yes, but that wasn't my question, I was asking if it was public, and since
it was not, I never would have found it. The watchdog group explains why
they are out of whack with reality.
------------------------------
Date: Thu, 10 Jun 1999 08:38:23 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Key lengths vs cracking time
Bob Silverman wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Jan Wessels wrote:
> > > Does anyone has some information relating to encryption algorithms
> > > and key length in relation to the time needed to break the encrypted
> > > data?
> >
> > Yes: There is no simple relationship between these.
>
> It depends on what you mean by simple.
>
> If one assumes the following:
>
> (1) Symmetric key algorithms can only be broken by brute force, direct
> search.
> (2) The best possible attack on RSA is factoring the modulus.
> (3) The best attack on DSA is either an index-calculus attack on the
> entire field or a Pollard Rho/Lambda attack on the subfield.
> (4) The best attack on ECDL is Pollard Rho/Lambda.
>
> Then one can give equivalent key sizes in terms of the TIME needed
> to break different key sizes. However, such an analysis ignores the
> fact that the sieve based factoring and DL algorithms requires
> *massive* SPACE, while symmetric key breaking and Pollard Rho/Lambda
> require small SPACE. For the Number Field Sieve, the SPACE problem
> is far more of an obstacle than the time requirement in the current
> state of computer hardware (and for the foreseeable future).
It also assumes that there is no weakness in the method of choosing the
key, the method of encoding it and so-forth. Sometimes the fatal flaw
in an otherwise-good encryption system is the user.
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: rc4 vs. rand()
Date: 10 Jun 1999 14:32:47 GMT
In <7jo61e$f1a$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>In article <7jng8o$lgv$[EMAIL PROTECTED]>,
> Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
>> A function is a relation which maps each element of the domain to at
>> most one element of the range. A function is one-to-one, or
>> "injective", if no two elements of the domain are mapped to the same
>> element of the range. A function is onto, or "surjective", if every
>> element of the range is the image of at least one element of the
>> domain.
>So the RC4 sbox is injective because all inputs have an unique
>output. It's surjective because the opposite is true (range onto
>domain). It's bijective because both are true.
Depends on what you mean by "the RC4 sbox is injective". Do you mean
the next-state() mapping between the current state (S, i, j) and next
configuration of the cipher? Or do you mean the mapping from the
current state of the cipher to the next output byte? The former is a
bijection (I think). The latter is almost certainly surjective, but
definitely _not_ one-to-one.
You probably need to be more precise about what you're considering the
inputs and outputs of your proposed bijection.
>So would the IDEA sboxes be bijective? They are surjective because
>the input->output is 1:1, it's surjective because the inverse is true
>as well...
The IDEA "S-boxes" are essentially multiplication modulo 65537, which
is a prime field. So if you hold the key constant, you can certainly
run the S-box either forward or backward, since each value has a
unique inverse.
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
fExGN44WPOlh6aMfFCc6QPQLckzlEl47u6ThAUqOX2sIipxEakJDuFyw1L68VeJXXTUVeSNb
Remove clothing if you wish to reply to this message via e-mail.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: One Time Pad
Date: Thu, 10 Jun 1999 14:52:33 GMT
"Ruppert" <[EMAIL PROTECTED]> wrote, in part:
>One Time Pad should not be able to be cracked, i think.
>The weak part is the key, right?
As soon as it has a weak point, it isn't a one-time pad anymore.
>So, what ist the point to start a usefull attack on One Time Pad?
The point at which it stops being a one-time pad.
>What is needed?
>One or more Cyphertext, one ore more parts of Plaintext, maybe a Key?
But to try and be more responsive:
If you have a key, you can read what was enciphered with that key.
If you know the plaintext, then if you can tamper with the ciphertext,
you can modify it to say something else.
If a key is used more than once, by mistake, then with the two
ciphertexts it is possible to begin Kerchoffs superimposition; some
cryptanalysis is possible.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Looking for a password encryption algorithm
Date: Thu, 10 Jun 1999 14:58:26 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
>Ari V�h�-Erkkil� wrote:
>> Simply, I'm looking for a reliable password encryption algorithm.
>
>Try any good crypto hash (MD5, SHA-1, etc.)
Better yet, try a zero-knowledge password proof, like EKE or SPEKE.
>> This is the situation: The passwords are to be stored in a database and
>> the client software will access the database via server programs.
>> Unfortunately the server programs are stateless, therefore a real
>> key-exchange type protocol cannot be implemented.
For a truly stateless server, no request/reply method would work.
and you wouldn't be able to authorize any subsequent transactions.
Is this really what you mean?
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Key lengths vs cracking time
Date: Thu, 10 Jun 1999 13:46:11 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Jan Wessels wrote:
> > Does anyone has some information relating to encryption algorithms
> > and key length in relation to the time needed to break the encrypted
> > data?
>
> Yes: There is no simple relationship between these.
It depends on what you mean by simple.
If one assumes the following:
(1) Symmetric key algorithms can only be broken by brute force, direct
search.
(2) The best possible attack on RSA is factoring the modulus.
(3) The best attack on DSA is either an index-calculus attack on the
entire field or a Pollard Rho/Lambda attack on the subfield.
(4) The best attack on ECDL is Pollard Rho/Lambda.
Then one can give equivalent key sizes in terms of the TIME needed
to break different key sizes. However, such an analysis ignores the
fact that the sieve based factoring and DL algorithms requires
*massive* SPACE, while symmetric key breaking and Pollard Rho/Lambda
require small SPACE. For the Number Field Sieve, the SPACE problem
is far more of an obstacle than the time requirement in the current
state of computer hardware (and for the foreseeable future).
--
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/
Share what you know. Learn what you don't.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Wed, 09 Jun 1999 15:43:38 -0500
[EMAIL PROTECTED] wrote:
> In article <7jmblu$r6u$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Please stop using terms who's meanings you do not know.
> > Given Particle's scheme, the s-box does form a function.
> > For for RC4 to work as intended the the s-box must meet
> > the stronger criterion of forming a permutation of the
> > integers [0..255].
>
> This a function!!! If the table forms a 1:1 mapping of inputs to
> outputs the table is a function.
Yes all permutations are functions. However so is y= C and many others. A
permutation is a bijective map.
which is a special case of functions -- what Brian is saying is that the
criteria is not MERELY that it is a function, but a bijection.
>
>
> > Please stop fabricating results. The RC4 shuffling method
> > is simple and vastly outperforms the Two-deck shuffling
> > technique. But we've no reason to say it's the simplest
> > in general.
>
> I never said twodeck (I made the assumption that it was good so I could
> cover other areas...). RC4 is by far the simplest method I have seen,
> in fact I would be interested in seeing other methods.
Yes, but your claim that it was the simplest offended him. Claiming that it
was a simple and powerful method, or the simplest method that you are aware
of is much more precise.
>
>
> > Sorry if you find this insulting, but all of the noted
> > problems appear often in your huge volume of posts.
>
> No problem. But the sbox does form a function. It can be inverted.
> The contents of the sbox is a permutation of 0..255, but when you use
> it like y = f(x) -> y = sbox[x] is the same idea.
Not all Functions can be inverted. That is what brian is getting at. I
know that many of the corrections you are receiving seem pedantic and small
minded, but in crypto the devil is in the details -- a minor misstatement
in specing an encryption or discussing a result can result in some huge
misunderstandings.
>
>
>
> Tom
> --
> PGP public keys. SPARE key is for daily work, WORK key is for
> published work. The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Looking for a password encryption algorithm
Date: Thu, 10 Jun 1999 15:11:26 GMT
In article <7jo0aj$di6$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I am looking for a simple password encryption algorithm
>similar to unix crypt(). I want to implement in my own
>simple authentication project.
>
>I dont know where I can get resources / papers ?
For networks, you can look at SPEKE. Papers on this and related methods
are at www.IntegritySciences.com/links.html
-- dpj
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Does scott19u.zip make full use of it's large key size ?
Date: Thu, 10 Jun 1999 14:01:53 GMT
In article <[EMAIL PROTECTED]>,
Horst Ossifrage <[EMAIL PROTECTED]> wrote:
> Yes, memory is cheap. Your computer can easily handle it.
Not in smartcards with less then 1KB of ram...
> Only in one pass, after all 25 passes, the bricklaying of
> words makes data dependent changes on adjacent words.
> This avalanches with each pass so 25 adjacent words of
> 19 bits each influence each other.
However what happens if one operation cancels out and the value returns
to what it was suppose to? Then there is no avalanche (you fail to
mention that). In my simple cipher this is less likely as every word in
the block affects the others using the PHT (i.e it's less likely all
words will cancel out).
>
> No , it has 25 passes each pass lets any bit change in the
> file affect any other bit.
This is not proven. It's impossible in fact to prove this.
> > 3. The S-Box is incredibly large. It contains all possible
> > 19bit words.
>
> yes.
Very insightful.
> > 4. The key for the algorithm is only used for generating
> > the S-Box. It is not used anywhere else in the
> > algorithm.
>
> Yes.
Indeed my life has changed for the better.
> Other ciphers may have some their s box entries not used.
> It is just less likely than for Scott's.
No it is not. What if the message is only 8 chars? (4 words)
> If you consider only one pass for all algorithms, you can
> find some with that property and some that have more extensive
> round functions. The simpler round functions may be susceptible to
> a Slide Attack, while less comprehensible roundss are not
> susceptible to that attack. That attack can be blunted by
> making each round different. But the large block size of Scott's
> makes the probability of finding a collision between a plaintext
> and a one round cipher too low for usefulness.
No it is not. Consider a four word message (or any small message). You
people cannot prove that it's immune because the block size is not
fixed. Also it is not immune to a slide attack because the cipher has
no round dependancies (i.e round keys). Same with my simple cipher. In
fact I could mount a chosen plaintext attack faster on your cipher then
my simple one.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: One Time Pad
Date: Thu, 10 Jun 1999 08:38:13 -0700
Ruppert wrote:
> One Time Pad should not be able to be cracked, i think.
Right -- used correctly, the OTP cannot be cracked.
> The weak part is the key, right?
That's the strong part.
> So, what ist the point to start a usefull attack on One Time Pad?
A "useful" attack means we're now in the real world, which means
there may be a fair amount of traffic, OTP suppliers who may not
be trustworthy, and code clerks of varying degrees of skill and
attentiveness. A number of things can go wrong, including:
- The OTP tape can break going through the machine (OK, this is
for an earlier era) and send plaintext or inverted plaintext.
- The code clerk may put one or more keys from the "used" category
back into the "to use" category.
- The OTP key supplier may have doubled their profits by selling
the key to more than one customer.
- The OTP key might not have been randomly generated throughout;
there may be a relationship between pages, for example.
Each of these has happened and has been exploited, according to
declassified publications and presentations. Also possible (though
I haven't seen an example reported) is an inappropriate implementation.
For example, the OTP may be a totally random set of digits used only
once -- but if used to encrypt letters (each letter gets moved from
0 to 9 places), the plaintext can mostly be recovered. There will
be ambiguities in spots, but probably most of the message can be
recovered, and cribs can be easily identified or eliminated.
--
Jim Gillogly
20 Forelithe S.R. 1999, 15:25
12.19.6.4.15, 12 Men 3 Zotz, Fifth Lord of Night
------------------------------
** 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
******************************
