Cryptography-Digest Digest #191, Volume #14 Fri, 20 Apr 01 13:13:01 EDT
Contents:
Re: Basic AES question (SCOTT19U.ZIP_GUY)
Re: DSS and patents. ("Christophe Meneboeuf")
Re: Minimal Perfect Hashing (Jim Steuert)
Re: Basic AES question (Volker Hetzer)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: NON SECRET ENCRYPTION (AKA RSA) (Doug Stell)
Re: Reusing A One Time Pad ("Douglas A. Gwyn")
Re: Reusing A One Time Pad ("Douglas A. Gwyn")
Re: Basic AES question ("Tom St Denis")
Re: ANOTHER REASON WHY AES IS BAD ("Tom St Denis")
Re: Basic AES question ("Tom St Denis")
Re: AES poll ("Tom St Denis")
Re: ANOTHER REASON WHY AES IS BAD (Darren New)
Re: ANOTHER REASON WHY AES IS BAD (Darren New)
Lessons learned from current watermarking systems (Lutz Donnerhacke)
Re: A practical idea to reinforce passwords (Niklas Frykholm)
Re: Basic AES question ("Paul Pires")
Re: Basic AES question ("Tom St Denis")
Re: Lessons learned from current watermarking systems ("Tom St Denis")
Re: A practical idea to reinforce passwords ("Tom St Denis")
Re: Distinguisher for RC4 (David Wagner)
Re: First cipher (David Wagner)
Re: newbie: cryptanalysis of pseudo-random OTP? (Leonard R. Budney)
Re: Will this defeat keyloggers ? (Paul Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Basic AES question
Date: 20 Apr 2001 13:57:05 GMT
[EMAIL PROTECTED] (Lou Grinzo) wrote in <MPG.154a10c759e2f9e6989791@typhoon4-
1.nyroc.rr.com>:
>Thanks to Paul and the others for responding.
>
>As best I can tell from the replies, there doesn't seem to
>be a technical reason for limiting keys to those three
>sizes. General crypto theory strongly implies that using
>other key sizes would have the predictable effect on the
>strength of the encryption (longer == stronger), but that
>hasn't been tested and proved to be the case. Correct?
>
Actaully if all else is equal a longer key is stronger.
But the crypto people want people to use short keys and
can point to many long key methods that are weak. I think
the true reasom for short keys limits is so the spooks
can keep tabs on what one encrypts. There is a lot of
hype as to way they want this. I feel so strongly that
the recomendations for a short are pushed very strongly
for one simple reason they can break it.
Wait for the response saying the keys are long enough
that the sun would burn out before one could invidually
do a dumb blind test on them. Well the same is true for
many broken ciphers so what. Why most the idiots allways
resort to the key search argument as if that is every used nowdays.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Christophe Meneboeuf" <[EMAIL PROTECTED]>
Subject: Re: DSS and patents.
Date: Fri, 20 Apr 2001 16:47:49 +0200
Thanks a lot.
> IANAL, but Fipses don't require a license.
> Don't worry about it. Worry instead about what your government has
> to say about you providing a product with DSS.
>
> Greetings!
> Volker
> --
> They laughed at Galileo. They laughed at Copernicus. They laughed at
> Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Minimal Perfect Hashing
Date: Fri, 20 Apr 2001 11:10:58 -0400
The term Minimal Perfect Hashing, as in the algorithm of Czech and Majewski,
(an amazing algorithm which really works) is for hash table lookup
purposes, in which one is hashing a large set of values (say 2^48) into a much
smaller
set of contiguous integer values (say 2^20), with no gaps. Are you trying
to encrypt a 48-bit value, or to create a hash table from a larger set of
values?
Francois St-Arnaud wrote:
> "Anders Thulin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Francois St-Arnaud wrote:
> > >
> > > I'm looking for a simple C algorithm for a function y = f(x) that would
> take
> > > a 48-bit number x and return another 48-bit number y. f should map x to
> y in
> > > a one-to-one fashion. f should be one-way, or at least, it should not be
> > > trivial to calculate x knowing y and the algorithm used.
> >
> > Your subject says *Minimal*, but that requirement is not repeated in
> > the body. Is the minimality criterion important?
>
> Yes. I neglected to repeat this important criterion in the requirements. It
> should be "minimal", meaning that n plaintexts will map to 0..n-1 ciphers
> with no collisions at all. For my application, n = 2^48, x and y in
> [0..2^48-1].
>
> Regards,
>
> Francois St-Arnaud
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 17:33:48 +0200
"SCOTT19U.ZIP_GUY" wrote:
> Actaully if all else is equal a longer key is stronger.
> But the crypto people want people to use short keys and
> can point to many long key methods that are weak. I think
> the true reasom for short keys limits is so the spooks
> can keep tabs on what one encrypts.
IMHO "crypto people" do not want people to use short keys
but want to get the most security out of a given key.
That's different.
An overlong key, i.e. much longer than can realistically be brute
forced in the time I want the secret to say secret may even
be a hint of sloppy design as it burdens the user with unwanted
load.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Fri, 20 Apr 2001 10:20:52 -0500
> Before patenting CryptoSauce, be sure you are not using Dynamic
> Substitution.
And what is this dynamic substitution of which you speak?
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: NON SECRET ENCRYPTION (AKA RSA)
Date: Fri, 20 Apr 2001 15:24:31 GMT
David,
You obviously didn't work in the right sector of the government. The
claim that the Brits invented both RSA and D-H (in that order) is
quite believable. I have also been able to substantiate the claim in
conversations with people who know the real facts.
On 20 Apr 2001 13:46:19 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>[EMAIL PROTECTED] (Tom St Denis) wrote in
><yuVD6.7259$[EMAIL PROTECTED]>:
>
>>
>>"Frank Gerlach" <[EMAIL PROTECTED]> wrote in message
>>news:[EMAIL PROTECTED]...
>>> see www.cesg.gov.uk
>>>
>>
>>No.
>>
>>
>>
>
> Yes I read the article very interesting however.
>Having worked for the government for 26 years. I can
>honestly say it could be pure crap. Only a fool should
>ever belive what is relived about secrets. Its is equally
>likely that either the secret community descovered public
>key encryption in the 50's or maybe they stumbled on it
>after it was out in the public, We will never know the
>truth. The only truth that you can be sure about is they
>we spin a story that makes the black agencyes of governemnt
>look good from a historical perspective. But if the spun
>story has any relationship to truth it is purely accidental.
>
>David A. Scott
>--
>SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
> http://www.jim.com/jamesd/Kong/scott19u.zip
>My website http://members.nbci.com/ecil/index.htm
>My crypto code http://radiusnet.net/crypto/archive/scott/
>MY Compression Page http://members.nbci.com/ecil/compress.htm
>**NOTE FOR EMAIL drop the roman "five" ***
>Disclaimer:I am in no way responsible for any of the statements
> made in the above text. For all I know I might be drugged or
> something..
> No I'm not paranoid. You all think I'm paranoid, don't you!
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Fri, 20 Apr 2001 15:14:11 GMT
Mark G Wolf wrote:
> ... Perhaps in a psych group.
Judging by your posting, that's certainly where you belong.
Or perhaps under a bridge, like a good troll.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Fri, 20 Apr 2001 15:15:48 GMT
Jerry Coffin wrote:
> ... but with careful design and use, there's nothing
> about the basic concept that prevents excellent security.
Nor, without careful design and use, is there anything that
guarantees adequate security.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 16:03:39 GMT
"Lou Grinzo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Thanks to Paul and the others for responding.
>
> As best I can tell from the replies, there doesn't seem to
> be a technical reason for limiting keys to those three
> sizes. General crypto theory strongly implies that using
> other key sizes would have the predictable effect on the
> strength of the encryption (longer == stronger), but that
> hasn't been tested and proved to be the case. Correct?
No whoever tolds you "longer == stronger" is an idiot. Look at designs like
LOKI89 and FEAL as compared to DES and come back to the group :-)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Fri, 20 Apr 2001 16:04:26 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <muVD6.7256$[EMAIL PROTECTED]>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> I don't think I mentioned this. This way but I feel another
> >> reason that the AES method has lead to a poor security solution
> >> is as follows.
> >>
> >> If one looks at the ideas in Kolmogov Complexity thoery
> >> where one tries to determine how random a string is by the
> >> length of shortest "program" that can generate the string.
> >> I think one can apply the same thoery to crypto. Since
> >> the idea is to take a low entropy string and make it appear
> >> to be random. It should take a fairly long program it achive
> >> this. But the goal of AES is to make a short program that can
> >> even be used on smartcards. I believe one measure of the
> >> potential worth of an encrytion program is the length of the
> >> smallest program to do the required encryption.
> >
> >This is just so wrong. Look at an OTP? It's a small program yet can be
as
> >secure as the entropy in the key. Low and behold so can a block cipher.
> >
>
> Actaully Tom as usually your quite wrong. If one looks at an OTP
> you would have to think of the OTP data itself as part of the
> encryption program or the program nesicessary to make the OTP sting.
> So it would be it least the sixe of the data encrypted. Assuming
> your using a random comples string.
Ok hotshot break RC5 then if it's really that bad.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 16:06:38 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Lou Grinzo) wrote in <MPG.154a10c759e2f9e6989791@typhoon4-
> 1.nyroc.rr.com>:
>
> >Thanks to Paul and the others for responding.
> >
> >As best I can tell from the replies, there doesn't seem to
> >be a technical reason for limiting keys to those three
> >sizes. General crypto theory strongly implies that using
> >other key sizes would have the predictable effect on the
> >strength of the encryption (longer == stronger), but that
> >hasn't been tested and proved to be the case. Correct?
> >
>
> Actaully if all else is equal a longer key is stronger.
> But the crypto people want people to use short keys and
> can point to many long key methods that are weak. I think
> the true reasom for short keys limits is so the spooks
> can keep tabs on what one encrypts. There is a lot of
> hype as to way they want this. I feel so strongly that
> the recomendations for a short are pushed very strongly
> for one simple reason they can break it.
Um point me to someone nowadays that will say "sure use a 40-bit key" with
knowledge about crypto and a straight face. Most serious cryptographers say
to use keys that are beyond the range of key searches (i.e 128 bits or
more). Which if you cared to think is why AES specified a key size of at
least 128 bits and upto (but not limited to) 256 bits.
> Wait for the response saying the keys are long enough
> that the sun would burn out before one could invidually
> do a dumb blind test on them. Well the same is true for
> many broken ciphers so what. Why most the idiots allways
> resort to the key search argument as if that is every used nowdays.
Well why not go out and prove yourself by finding the RC5-128 challenge key
before anyone else instead of posting crap here?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: AES poll
Date: Fri, 20 Apr 2001 16:09:26 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Paul Crowley) wrote in
> <[EMAIL PROTECTED]>:
>
> >[EMAIL PROTECTED] (David Wagner) writes:
> >> For what it's worth, the "polls" of the research community showed
> >> a significant leaning towards Rijndael even before it was selected
> >> by NIST. I, for one, think they made a fine choice, and I'm very
> >> pleased with the results of the standards process.
> >
> >...and remember, this is one of the Twofish authors writing. In fact,
> >the extended Twofish team officially endorsed three of the final five
> >(Rijndael, Serpent, Twofish) in their final presentation. They are
> >the people who did the most cryptanalysis of the AES candidates.
>
> Are you attempting to say the endorsement was real and not just the
> poltically correct thing to do. If the TWOFISH team actaully made
> an honest statement saying please pick Rijndael its better than
> TWOFISH I would call that an endorsement any thing short of that
> sounds FISHY.
No the Twofish team was being modest in saying "Sure we want Twofish to win,
but these other ciphers are good picks too.". Obviously you are just a
non-human and don't understand.
> Besides part of the game is to pretend you like some of the competition
> so that you can fake the moral high ground. You pick the one that
> you think your better than so if another product is far better people
> will exculde looking at it. That way your product may only be
> compared by others to the one you sort of liked. People will falsely
> assume the possible far better product was not very good. "Since
> you seem to be fair" since you said one was sort of good so the others
> must not be so good. It really a very clever business trick.
This makes no sense whatsoever. You have to wait till you settle from your
crack-related-high before posting. The AES competition was not a "we're
better than you guys" compo. It was "let's propose ciphers and pick the one
that survives the most cryptanalysis and review".
Tom
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Fri, 20 Apr 2001 16:14:46 GMT
> > If one looks at the ideas in Kolmogov Complexity thoery
> > where one tries to determine how random a string is by the
> > length of shortest "program" that can generate the string.
[...]
> This is just so wrong. Look at an OTP? It's a small program yet can be as
> secure as the entropy in the key. Low and behold so can a block cipher.
A point to note is that the program must be self-contained. I.e., you must
consider the key as a literal inside the program. Hence, the OTP isn't just
the loop with the XOR, but also the array of random bits you're passing to
the XOR.
The same is true of the AES program to decrypt an encrypted message. The
theoretical program you would need to address this with complexity theory
includes the 128-bit (or whatever) key, as well as the algorithm to employ
said key. If you have 2^128 different programs that might decrypt the
cyphertext, and your best way of finding one is guessing, then you have a
good algorithm with a 128-bit key.
You can't just look at AES with no key and decide that's the complexity of
the encypherment.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
schedule.c:7: warning: assignment makes calendar_week
from programmer_week without a cast.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Fri, 20 Apr 2001 16:15:42 GMT
SCOTT19U.ZIP_GUY wrote:
> Actaully Tom as usually your quite wrong. If one looks at an OTP
> you would have to think of the OTP data itself as part of the
> encryption program or the program nesicessary to make the OTP sting.
So why do you think that doesn't apply to the AES cyphers as well?
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
schedule.c:7: warning: assignment makes calendar_week
from programmer_week without a cast.
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Lessons learned from current watermarking systems
Date: Fri, 20 Apr 2001 16:25:49 +0000 (UTC)
A paper about current watermarking systems occured on my desk a few hours ago.
It's really interesting to read:
ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/general/\
Craver,McGregor,Wu,Liu,Stubblefield,Swartzlander,Wallach,Dean,Felten:\
Lessons_from_the_SDMI_Challenge.pdf
^L
If you like to copy it to other servers: Please do.
------------------------------
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: A practical idea to reinforce passwords
Date: Fri, 20 Apr 2001 07:44:19 +0000 (UTC)
In article <T7ID6.54032$[EMAIL PROTECTED]>, Tom St Denis
wrote:
>Why not just use higher entropy passwords or keys instead of making more
>work for legitimate users?
Using higher entropy passwords *means* more work for the legitimate
users. It is harder to remember a higher entropy password. Also, in
most systems, users select their own passwords, which means that we
cannot control the entropy.
Using a key derivation function, on the other hand, only means more work
for the *user's computer*. A desktop PC has plenty of idle time, half a
second's delay during login is hardly noticable.
// Niklas
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 09:35:23 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:v5ZD6.9193$[EMAIL PROTECTED]...
>
> "Lou Grinzo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Thanks to Paul and the others for responding.
> >
> > As best I can tell from the replies, there doesn't seem to
> > be a technical reason for limiting keys to those three
> > sizes. General crypto theory strongly implies that using
> > other key sizes would have the predictable effect on the
> > strength of the encryption (longer == stronger), but that
> > hasn't been tested and proved to be the case. Correct?
>
> No whoever tolds you "longer == stronger" is an idiot. Look at designs like
> LOKI89 and FEAL as compared to DES and come back to the group :-)
If you are going to make comparisons, don't you think they should
be apples to apples? How can you say anything about the effect
of the keysize if you are testing the idea on Algo A versus Algo B??
It is always a good practice to isolate the variable of intrerest and
keep all else the same. Even in mental arguments.
Why not compare the difference between AES at 128 versus AES at 256??
Without an awful lot of work, about the only thing you could say is that one
should be a lot harder to brute force than the other.
Surprisingly, I agree with your point even if I have a problem with how you
got there. To me, the strength of an algorithm means it's ability to withstand
assalt up to its key size and no further. This is what they are designed to do.
Any strength above the failure point is just fudge factor. "Extra" strength may
be there but it has no meaning since it will not be tested. If I can brute force
faster than breaking, why would I put effort into breaking over and above the
brute force level?
If AES is a well designed cipher, 128 and 256 bit modes should be equally
"Strong".
Paul
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 16:45:44 GMT
"Paul Pires" <[EMAIL PROTECTED]> wrote in message
news:UzZD6.16354$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:v5ZD6.9193$[EMAIL PROTECTED]...
> >
> > "Lou Grinzo" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Thanks to Paul and the others for responding.
> > >
> > > As best I can tell from the replies, there doesn't seem to
> > > be a technical reason for limiting keys to those three
> > > sizes. General crypto theory strongly implies that using
> > > other key sizes would have the predictable effect on the
> > > strength of the encryption (longer == stronger), but that
> > > hasn't been tested and proved to be the case. Correct?
> >
> > No whoever tolds you "longer == stronger" is an idiot. Look at designs
like
> > LOKI89 and FEAL as compared to DES and come back to the group :-)
>
> If you are going to make comparisons, don't you think they should
> be apples to apples? How can you say anything about the effect
> of the keysize if you are testing the idea on Algo A versus Algo B??
Because if you followed the argument it was about "does longer keysize
generally mean stronger". I was trying to show (in a futile attempt to use
intelligence) that while LOKI used a longer key than DES (LOKI was suppose
to be a "replacement") it was easier to break...
Anyways.... LALALALALALALALALALALALALALALA
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Lessons learned from current watermarking systems
Date: Fri, 20 Apr 2001 16:46:18 GMT
"Lutz Donnerhacke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> A paper about current watermarking systems occured on my desk a few hours
ago.
> It's really interesting to read:
>
> ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/general/\
> Craver,McGregor,Wu,Liu,Stubblefield,Swartzlander,Wallach,Dean,Felten:\
> Lessons_from_the_SDMI_Challenge.pdf
> ^L
> If you like to copy it to other servers: Please do.
How about a valid url?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Fri, 20 Apr 2001 16:47:42 GMT
"Niklas Frykholm" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <T7ID6.54032$[EMAIL PROTECTED]>, Tom St Denis
> wrote:
>
> >Why not just use higher entropy passwords or keys instead of making more
> >work for legitimate users?
>
> Using higher entropy passwords *means* more work for the legitimate
> users. It is harder to remember a higher entropy password. Also, in
> most systems, users select their own passwords, which means that we
> cannot control the entropy.
Dude this is false.
> Using a key derivation function, on the other hand, only means more work
> for the *user's computer*. A desktop PC has plenty of idle time, half a
> second's delay during login is hardly noticable.
This is stupid. What about smartcard systems? Adding work for them is a
bad idea. Slowing a desktop computer for 10 seconds would be like slowing a
5mhz 6805 for 30 minutes!
Anyways, if you want high entropy passwords issue MagStrip cards. They are
simple to design and use and you can store like 128 bits at least of entropy
on them.
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Distinguisher for RC4
Date: 20 Apr 2001 16:54:11 GMT
David Formosa (aka ? the Platypus) wrote:
>RC4 is a streem cyper/pydorandom number generator, while 3DES is a
>block cyper. You can't replace RC4 with 3DES in most situtations.
Nonsense. You can replace RC4 with 3DES-counter mode or 3DES-OFB mode.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: First cipher
Date: 20 Apr 2001 16:56:12 GMT
>Supposedly, if the S-box is reversible and the number of bits per table
>entry is large, then the probability of a random S-box having one or
>more bits that are linear functions of the address bits is low.
(... if the S-box is large enough, and is selected at random.)
>Ah, but at one time each one of them was a neophyte just like me.
Yes, but designing new ciphers is unlikely to be the best way to
learn how to design new ciphers. (Sounds counter-intuitive, but
it seems to be true.)
------------------------------
From: [EMAIL PROTECTED] (Leonard R. Budney)
Subject: Re: newbie: cryptanalysis of pseudo-random OTP?
Date: 20 Apr 2001 12:58:31 -0400
"Osugi Sakae" <[EMAIL PROTECTED]> writes:
> I meant them (1-5) as a sequence for generating a pseudo-random OTP.
Note that "pseudo-OTP" is a term that newbies constantly make up, thinking
it's an original idea. The term should not be used; it's very deceptive.
A genuine OTP is 100% unbreakable. Anything else is not a OTP, period. So
it's a bad idea to give it a name which suggests security comparable to
a OTP.
What you're doing is generating a pseudo-random sequence, and XOR-ing it
with the original message. This notion already has a name: it's called a
"stream cipher". (No, it's not the only kind of stream cipher. But it is
how most stream ciphers work.)
To build a good stream cipher, you want a PRNG without redundancies or
other leakage which would allow the bits to be guessed with better than
coin-tossing accuracy.
Your analogy with a caeser cipher is a good one, though. If the key
sequence is sufficiently non-random, then you could read a message by
"guessing" the key bits using a similar bias to the cipher. Guesses
can be checked against a dictionary, so the entire crack can be
automated if the PRNG is lousy enough.
Your thinking wasn't bad; it appears you did stumble onto the notion of
a stream cipher. Your idea amounts to inventing a PRNG which uses a book
as its input. And it could almost work: you might indeed find a way to
"bleach" the content of a book into something fairly random-looking.
However, it would not be practical. Having pointed out the notion of a
stream cipher, I bet you can see why. The first problem you've already
addressed: the book must be computer readable--but things like Gutenberg
texts will serve.
The real problem is that the keyspace is far too small. If your cipher
were used by a high-profile target, then it would be easily affordable to
slurp up the entire Gutenberg repository and run it through your process,
storing up a precompiled database of all possible keys. It wouldn't even
take that long.
Expanding the keyspace isn't practical either. A while back some guy
made a similar proposal, where he suggested that the "whole internet"
would be the keyspace. In practice, such a system would be far too
vulnerable to things like traffic analysis--i.e., you can be watched
while you download your key data. And even in principle, it would be
too hard to prove high-quality randomness. The effective keyspace of the
"whole intenet" might be much smaller than you'd imagine, and probably is.
Len.
--
Frugal Tip #15:
Keep whistling the Old Spice Aftershave jingle until people give you
money to stop.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Will this defeat keyloggers ?
Date: 20 Apr 2001 10:00:17 -0700
Anonymous <[EMAIL PROTECTED]> writes:
> Say for arguments sake I create a password/phrase on a stand alone
> machine and save it to a removable disk.
> If I now use an encryption algorithm on another machine and call the
> password/phrase from the removable disk instead of typing it on the
> keyboard, will this method defeat the average keylogger ?.
> Thanks for your time.
I suppose so, but now your passphrase is accessible all the time, which
defeats the purpose somewhat.
Here's an approach I've thought of that would also defeat typical loggers.
Instead of just typing the passphrase, have a program generate a random
permutation of the alphabet and display it in a window or applet, like:
A-W B-H C-A D-X E-J F-Z G-N etc.
(It doesn't actually have to be a total permutation, a simple caesar
cipher (like "rot13" but with a random amount of rotation will also work).
You now look up the first character of your passphrase in the list, and
type in what it permutes to. So if your passphrase starts with D, you'd
enter X. The program now generates a DIFFERENT permutation or rotation
and you use that to transform the second char of your passphrase, etc.
until you've entered the whole passphrase.
The idea is you've encrypted your passphrase with something like a
one-time-pad. A keyboard logger won't be able to figure out what the
real passphrase was, unless it's also logging the contents of the
screen.
Really though, you shouldn't type or display confidential data on a
machine you think someone has been messing with. A scheme like the
above is better than nothing but you're best off using your own
machine (even a handheld) for anything needing security.
------------------------------
** 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
******************************
