Cryptography-Digest Digest #204, Volume #14 Sun, 22 Apr 01 04:13:00 EDT
Contents:
Re: ANOTHER REASON WHY AES IS BAD (JPeschel)
Re: The Extended Euclidian Algorithm (The original, not modular!) ("Alexis Machado")
Re: ANOTHER REASON WHY AES IS BAD (SCOTT19U.ZIP_GUY)
Re: Cryptanalysis Question: Determing The Algorithm? ("Dramar Ankalle")
Re: Delta patching of encrypted data (Benjamin Goldberg)
Re: ANOTHER REASON WHY AES IS BAD ("Tom St Denis")
ATT to introduce WW2 technologies into their smell-based communication (F-104G Data
Fighter)
YEAH TRIAL AND ERROR (F-104G Data Fighter)
Re: A practical idea to reinforce passwords (Paul Crowley)
Re: what crypt algo is the smallest to code? (Paul Crowley)
Mix of Firefighters and Orwellian Mist ? (F-104G Data Fighter)
Haunted by Tobagonian 007s (F-104G Data Fighter)
A SHITPILE OF ICE CROPPING UP BEHIND barbed wire (F-104G Data Fighter)
Re: ANOTHER REASON WHY AES IS BAD (wtshaw)
Re: ANOTHER REASON WHY AES IS BAD (wtshaw)
Re: Cryptanalysis Question: Determing The Algorithm? (wtshaw)
Re: Better block cipher pre/post whiten step ("Scott Fluhrer")
Re: Diffie-Hellman signatures now described (John Savard)
Re: OTP breaking strategy ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 22 Apr 2001 03:13:27 GMT
Subject: Re: ANOTHER REASON WHY AES IS BAD
[EMAIL PROTECTED] (wtshaw) writes:
>In article <t1iE6.16969$[EMAIL PROTECTED]>, "Tom St Denis"
><[EMAIL PROTECTED]> wrote:
>
>>
>> Why is a 256-bit key too short?
>>
>You don't outrun a forest fire by stopping when the heat seems tolerable.
On the other hand, if you're in a forest fire in Colorado, you needn't
run to North Sioux City, SD to escape the flames.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto,sci.math
Subject: Re: The Extended Euclidian Algorithm (The original, not modular!)
Date: Sun, 22 Apr 2001 00:38:14 -0300
Reply-To: "Alexis Machado" <[EMAIL PROTECTED]>
"Alexis Machado" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
...
> The result
>
> R[0] * a = 1 mod b
> R[1] * b = 1 mod a
> R[2] = GCD (a, b)
>
Sorry, a little mistake. The result is
R[0] = x
R[1] = y
R[2] = GCD (a, b)
Note:
When GCD(a, b) = 1
xa + yb = 1 => xa = 1 (mod b) and yb = 1 (mod a)
i.e., "x" and "y" are multiplicative inverses.
Alexis
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: 22 Apr 2001 03:28:42 GMT
[EMAIL PROTECTED] (JPeschel) wrote in
<[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (wtshaw) writes:
>
>>In article <t1iE6.16969$[EMAIL PROTECTED]>, "Tom St
>>Denis"
>><[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Why is a 256-bit key too short?
>>>
>>You don't outrun a forest fire by stopping when the heat seems
>>tolerable.
>
>On the other hand, if you're in a forest fire in Colorado, you needn't
>run to North Sioux City, SD to escape the flames.
>
What your missing is two things we know alot more about how far a
forest fire will spread and have an idea of the damage. Plus going
to SD may be out of the way. With encryption most people using it
would never know if it was using a 40 bit key or a 400000 bit key.
But I think a most would notice the diffence dirving a car a few
miles or a thousang miles.
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: "Dramar Ankalle" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sun, 22 Apr 2001 00:22:05 -0400
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (JPeschel) wrote:
>
> > [EMAIL PROTECTED] writes:
> >
> > >The NSA no doubt has a bestiary of bad ciphers, including all hand
> > >ciphers, where the effort of breaking is so trivial that they could
> > >simply run a random message through all of them by brute-force, and
> > >they probably succeed most of the time.
> >
> > Why would the NSA, or, for that matter, any serious cryptanalyst,
> > brute-force hand ciphers?
> >
> > Joe
>
> They don't have to work at is with a brute in the box that loves being
> fed. As can be said with a mix of low level stuff and an awaiting
> machine, " Et yet Brute buss?"
>
> As far informing what a cipher is, best to make it look like what is
> isn't. I remind those of my periodic posts regarding a demonstration that
> allows a simple conversion of any ciphertext to have the profile of
> another ciphertext. It's all childs play as you treat all why want to
> sing on simple keys a line of BS....they seem to thrive on it.
>
> We have a new generation of children who don't like losing the big game
Why would children be in some big game?
> and try to redefine logic, the constitution, public opinion, and common
Children are doing this?
Send them to school, and dont take their money away if they get in trouble
> sense because they thing that they can. Well...surprise, that dog will
> bite you, and it surely won't hunt either.
Dogs that bite children get put down.
Capiche?
> --
> Bash a rash hash dashed for cash. Stash in casche mashed clash.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Delta patching of encrypted data
Date: Sun, 22 Apr 2001 04:27:06 GMT
David Wagner wrote:
>
> Benjamin Goldberg wrote:
> >ct[-8..-1] = IV
> >ct[i] = pt[i] ^ F(k, pt[i-8..i-1]) (for i>0)
>
> FYI, this is sometimes known as plaintext feedback mode (PFB),
> and it has the weakness you mention (repeated plaintext blocks
> leak information about the text that follows them).
>
> >What I can suggest, however, is double-encryption of some sort.
> >Encrypt with the above, and then encrypt with a second, more secure
> >type of cipher chaining mode (Perhaps IAPM, with AES as the cipher)
> >-- the program calling patch will have the key to the outer cipher,
> >but not the inner one.
>
> This doesn't work, because whenever you change a small part of
> the document, you have to change almost all of the following
> ciphertext to avoid errors due to the outer chaining mode.
Let's call the encryption operations PFB() and CBC() (just cause cbc is
more well known than iapm).
file = CBC(k2, IV, PFB(k1, pt)) == what is stored on disk.
x = CBC^-1(k2, file)
x' = applypatch(x, patch)
IV' = new unique random string.
file' = CBC(k2, IV', x') == what is stored on disk.
Done this way, the machine which file resides on (and is patched on)
need not ever know what k1 is, only k2. There is some slight risk in
that k2 might be gotten by a clever hacker (since I don't know what kind
of security there is on the patching machine), and there is also some
slight risk that a clever hacker might get x (for similar reasons) after
file has been decrypted and before x and x' are erased after
reencryption (securely erasing files is tricky) -- but there is no way
to ever gain either k1 or pt directly from the patching machine, because
k1 is never stored there, nor is x ever decrypted to p1 there. So if
the system gets "partially broken" he still has to somehow break the PFB
encryption.
Oh, and *any* patch, even a noop, should cause file' to look completely
different from file, since the IV is changed.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Sun, 22 Apr 2001 04:48:51 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (JPeschel) wrote in
> <[EMAIL PROTECTED]>:
>
> > [EMAIL PROTECTED] (wtshaw) writes:
> >
> >>In article <t1iE6.16969$[EMAIL PROTECTED]>, "Tom St
> >>Denis"
> >><[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>> Why is a 256-bit key too short?
> >>>
> >>You don't outrun a forest fire by stopping when the heat seems
> >>tolerable.
> >
> >On the other hand, if you're in a forest fire in Colorado, you needn't
> >run to North Sioux City, SD to escape the flames.
> >
>
>
> What your missing is two things we know alot more about how far a
> forest fire will spread and have an idea of the damage. Plus going
> to SD may be out of the way. With encryption most people using it
> would never know if it was using a 40 bit key or a 400000 bit key.
> But I think a most would notice the diffence dirving a car a few
> miles or a thousang miles.
Ahh to use your annoying analogies. Will the driver notice the difference
between 10000000 miles and 1000000000000000000000000000000 miles?
Tom
------------------------------
From: F-104G Data Fighter <[EMAIL PROTECTED]>
Subject: ATT to introduce WW2 technologies into their smell-based communication
Date: Sun, 22 Apr 2001 07:22:28 +0200
My sourcxes say this is an impoverishment of the Fox Schnueffelpanzer
X111. Martin Weiber, the CEO of Saustall technologies just confirmed
this in an Interview with JDR (JuliA R�vers Defense Review). GOTCHA. ILL
SHIT ON YOU
------------------------------
From: F-104G Data Fighter <[EMAIL PROTECTED]>
Subject: YEAH TRIAL AND ERROR
Date: Sun, 22 Apr 2001 07:26:43 +0200
Tom St Denis wrote:
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:9bt2ec$6j3$[EMAIL PROTECTED]...
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:FxmE6.20603$[EMAIL PROTECTED]...
> > >
> > > "Leonard R. Budney" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > > >
> > > > > "newbie" <[EMAIL PROTECTED]> wrote in message
> > > > > news:[EMAIL PROTECTED]...
> > > > > >
> > > > > > E(i) = P(i) Xor k(i)
> > > > > > E'(i)= P'(i) Xor k(i)
> > > > > >
> > > > > > How could I solve this trivial problem.
> > > > >
> > > > > You guess k(i) values and see if for all known E values if the key
> > makes
> > > > > sense.
> > > >
> > > > Nope. There's a simpler way. Just XOR E(i) and E'(i). Since 1 XOR 1
> > > > equals 0, and 0 XOR anything is itself, and XOR is both associative
> and
> > > > commutative, we have:
> > > >
> > > > E(i) Xor E'(i) = (P(i) Xor k(i)) Xor (P'(i) Xor k(i))
> > > > = P(i) Xor k(i) Xor P'(i) Xor k(i)
> > > > = P(i) Xor P'(i) Xor k(i) Xor k(i)
> > > > = P(i) Xor P'(i) Xor 0
> > > > = P(i) Xor P'(i)
> > > >
> > > > So now we have the XOR of two plaintext messages. This is extremely
> easy
> > > > to separate into the original two messages, and as a freebie you can
> > then
> > > > compute k(i) in case it gets used again.
> > >
> > > That's another way, but if I give you
> > >
> > > 1d 4f 1f 45 16 05 53 42 07 0a 19 16 00 00
> > >
> > > Which is the xor of two 8-bit null terminated ASCII messages. Can you
> > give
> > > me the original plaintexts?
> >
> > "Tom was here"
> > "I read books"
> >
> > Does this answer the argument?
>
> Keen, how did you do that? Just trial and error?
>
> Tom
------------------------------
Subject: Re: A practical idea to reinforce passwords
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 22 Apr 2001 05:33:43 GMT
Shai Halevi <[EMAIL PROTECTED]> writes:
> This is known as "password stretching". See, for example, a TR by Abadi
> et al., available from
> http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/abstracts/src-tn-1997-033.html
Strictly speaking, this is "strengthening"; Kelsey et al's technique
of repeated hashing is "stretching".
Stretching is vastly preferable when used with strong password
protocols like SRP; I am unconvinced that strengthening is ever
preferable.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: what crypt algo is the smallest to code?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 22 Apr 2001 05:33:43 GMT
[EMAIL PROTECTED] (Rob Warnock) writes:
> If you're also interested in very small symmetric-key algorithms
[mentions TEA and ARCFOUR]
Note that ARCFOUR is very insecure if the same key is used twice. The
world's simplest complete cryptosystem, CipherSaber, adds a 10 byte
nonce ("IV") to the ARCFOUR key so that keys can securely be used
multiple times. Here's CipherSaber in Perl:
#!/usr/bin/perl -0777i_MUNITION,see_http://ciphersaber.gurus.com
(pop)?read STDIN,$p,10:print$p= ~time;sub S{@s[$x,$y]=@s[$y,$x]}sub
Q{$s[($_[0]+=$_[1])%=@s]}@k=unpack'C*',(pop).$p;for$x(@t=@s=0..255){S
Q$y,$k[$x%@k]+Q$x}$x=$y=0;print map{chr($_^Q S Q$y,Q$x,1)}unpack'C*',<>
due to myself and Jeff Allen.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: F-104G Data Fighter <[EMAIL PROTECTED]>
Subject: Mix of Firefighters and Orwellian Mist ?
Date: Sun, 22 Apr 2001 07:38:21 +0200
It is so extremely foggy down here in CENTCOM :-)
------------------------------
From: F-104G Data Fighter <[EMAIL PROTECTED]>
Subject: Haunted by Tobagonian 007s
Date: Sun, 22 Apr 2001 07:25:17 +0200
Since my last visit to the Island of Tobago, my feets became black like
as if they genetically mixed it up. THAT IS THE POFFER OF PERCEPTION
MANAGEMENT.
------------------------------
From: F-104G Data Fighter <[EMAIL PROTECTED]>
Subject: A SHITPILE OF ICE CROPPING UP BEHIND barbed wire
Date: Sun, 22 Apr 2001 07:36:48 +0200
After some sneak-in attacks onto the HQ of GAF, I conclude that their
POWER IS IN WOOD. Unrelated to that german KSK forces are being melded
with a Special Air Service Regiment somewhere in the Novosibrisk region.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Sat, 21 Apr 2001 23:52:02 -0600
In article <pNrE6.23502$[EMAIL PROTECTED]>, "Tom St Denis"
<[EMAIL PROTECTED]> wrote:
> "wtshaw" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > In article <t1iE6.16969$[EMAIL PROTECTED]>, "Tom St Denis"
> > <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Why is a 256-bit key too short?
> > >
> > You don't outrun a forest fire by stopping when the heat seems tolerable.
> > With a few bits, brute force means processing those few bits in several
> > blocks to check the viability of a key. With a bigger set of bites to
> > test, even a hungrey attacker's doesn't dare try his jaws.
>
> Ok rephrase this in terms of real life crypto.
>
> What is with the amount of crap here... honestly can't anyone discuss
> serious crypto in this group?
>
> Tom
Sorry about the numerous typos above, but I was rushed and my hand was not
cooperating.
It's serious enough to mark the big difference between getting at real
strength vs. cat and mouse crypto.
If you have bought into running with the bulls, you might get hurt running
into a Bush or being Gored. However, if you have difficulty with
allegory, try Bush's half baked beans instead.
You may not get the message, but it just goes to prove Barnum was right.
--
Nafta, etc.? No way Jose.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: ANOTHER REASON WHY AES IS BAD
Date: Sat, 21 Apr 2001 23:57:04 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> [EMAIL PROTECTED] (wtshaw) writes:
>
> >In article <t1iE6.16969$[EMAIL PROTECTED]>, "Tom St Denis"
> ><[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Why is a 256-bit key too short?
> >>
> >You don't outrun a forest fire by stopping when the heat seems tolerable.
>
> On the other hand, if you're in a forest fire in Colorado, you needn't
> run to North Sioux City, SD to escape the flames.
>
You need to hear the story about the herd of cows and the relevant
discussion from between an old and a young bull.
--
Nafta, etc.? No way Jose.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Date: Sat, 21 Apr 2001 23:38:06 -0600
In article <9btm4j$49q$[EMAIL PROTECTED]>, "Dramar Ankalle"
<[EMAIL PROTECTED]> wrote:
> > We have a new generation of children who don't like losing the big game
>
> Why would children be in some big game?
>
> Children are doing this?
> Send them to school, and dont take their money away if they get in trouble
>
> Dogs that bite children get put down.
>
I'm not speaking of kids but of spoiled brats, many of who seek public
office for serving themselves rather than the public. And, they should
have their allowances cut.
--
Nafta, etc.? No way Jose.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Better block cipher pre/post whiten step
Date: Sat, 21 Apr 2001 22:55:57 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:e8gE6.15919$[EMAIL PROTECTED]...
> Here's a neat idea. Instead of just xor-ing a key against the block
> before/after the main core of the cipher (as in most modern ciphers) why
not
> use a pair-wise decorrelated function? Unlike COCONUT98 where the
function
> was put in the middle of the cipher you put it at the ends i.e
Like most proposed ideas along the lines of "if we make this operation more
expensive, the cipher looks stronger", it presumes the wrong question. The
question isn't "how can we make a cipher that is as strong as possible",
because essentially we already know how to do that -- as Rivest put it, 1000
rounds of just about anything is usually pretty secure. Instead, the
interesting question is "how can we make a cipher that is as cheap as
possible, and still be secure" (where cheap is defined by the usage --
possibly the number of cycles per byte encrypted, or the memory footprint,
or the complexity of the software, or the number of transistors used in a
hardware implementation, or hardware throughput or the key agility, to give
a partial list). This is the interesting question because if we do not
insist on "cheap", we already know the answer.
Hence, the question to answer really is "does this operation allow us to
remove enough rounds from the core block cipher so that we have an overall
gain in at least some area". Now, that would obviously depend greatly on
the exact construction of the core block cipher. However, it doesn't look
good (unless the round function uses GF/2 multiplications internally, where
the below really doesn't apply):
- In terms of memory footprint, going GF/2 multiplications cost memory,
especially if we go after large table driven approaches (which also chew up
cache space).
- In terms of complexity of software, doing GF/2 multiplications are
considerably more complex than increasing an iteration counter, or
duplicating some lines if the iterations are unrolled.
- In terms of transistors, well, if you're doing a low-transistor version
that have just one round hardware, putting in GF/2 multiplications is
obviously increases the minimal transistor count.
In contrast, traditional pre- and post-whitening are almost free (just an
xor), and often give you the effect of an additional round or so -- that's
why the idea is so popular.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Diffie-Hellman signatures now described
Date: Sun, 22 Apr 2001 08:01:48 GMT
On Fri, 20 Apr 2001 00:40:13 GMT, "Tom St Denis"
<[EMAIL PROTECTED]> wrote, in part:
>DH afaik describes a key exchange protocol involving the DLP.
But everything using the DLP cryptographically is derived from DH,
since DH represents the realization that the DLP could be used in this
manner.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Sun, 22 Apr 2001 08:05:46 GMT
newbie wrote:
> I said OTP could be broken practically.
> In theory, I KNOW that is unbreakable, but If you combine the context
> factor and other extra-information you can break it.
No! You don't get anything more out of it than you put into it.
------------------------------
** 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
******************************
