Cryptography-Digest Digest #606, Volume #10 Mon, 22 Nov 99 03:13:04 EST
Contents:
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: For all lions --- ("mycroft")
Re: Nova program on cryptanalysis -- also cipher contest (Sundial Services)
Re: Schneier's how to be a cryptanalyst paper (Raphael Phan Chung Wei)
Values in bf_init for Blowfish in 16 & 20 round versions ("Cory C. ALbrecht")
Have more hints. Re: ... also cipher contest (William Rowden)
Re: math (jerome)
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
public-key updating attack ("OTTO")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Sun, 21 Nov 1999 23:32:27 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
: The situation's pretty simple: he knows the error recovery inherent
: in CBC is useful and important, but doesn't want to admit it. To try
: to get me (or anybody else who would reply) to admit to the contrary,
: he picked PGP out and tried to get somebody to show how it would do this.
: PGP uses CFB, which lacks exactly that capability. If somebody
: tried to show how the capability would be used with PGP, they would
: face one of two possibilities: they could either admit that it's not
: there, or else incorrectly try to show how to do it. [...]
Right. Firstly, I know less about CFB than I do about CFB. Please bear
this in mind.
I agree that error recovery is not present in CFB. However it is not
clear to me that this implies that very much diffusion of information
is going on.
If a pass in a single direction is made then no information can flow
backwards from the tail of the file to its head.
Since no information flows backwards, there's nowhere for any information
that flows forwards to go - the remainder of the file can't store the
information required to decrypt it (which it /must/ do) *and* information
about earlier parts of the file as well - since there's not enough space!
This argument suggests to me that once again the information relating to
the plaintext remains localised about the corresponding location in the
cyphertext.
It is /this/ property that is behind David's argument, not error recovery
itself. The lack of an error recovery mechanisms does not invalidate his
argument, it merely deprives him of one of his ways of demonstrating the
existence of the property in question (localisation).
*Perhaps* CFB mode (unlike CBC mode) *does* diffuse information
significantly through the file. However, you have not yet made any
argument that this is the case - so consequently I do not feel inclined to
agree with your argument about David being misleading.
: OTOH, let's look at (more or less) the original question: how would a
: user make use of error-recovery in a system that used CBC? First of
: all, a typical dynamic, stream-oriented compression wouldn't be used.
: You'd either use no compression, a static compression, or else have
: the compressor work in blocks, typically the same size blocks as the
: cipher is going to use.
I agree that /some/ types of compression can retain some error recovery
ability.
I have difficulty in imagining a useful compressor that output in
discrete, non-interacting n-bit chunks, though. If n=128, say, there's
not much scope for compression, it seems to me.
Generally I'd say that effective compression and confinement of errors
were constarints that often pull in different directions - and that
you can't generally have them both at the same time.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
If laws were outlawed, only outlaws would be lawyers.
------------------------------
From: "mycroft" <ask me and I will email it to you>
Crossposted-To: alt.politics.org.nsa,alt.math,alt.security
Subject: Re: For all lions ---
Date: Sun, 21 Nov 1999 21:36:49 -0500
I may not be a lion, but I'm passing
through hiding from a flame
war. My newsgroup is winning.
This is a response to an old post, but
very relevant.
I must comment:
I have seen the content of hacker
newsgroups. To a serious
professional, the concept of the "back
door" is often overlooked.
It is assumed that noone would do such a
thing.
However, their presence is common
practice. Any corporation
would be foolish to use an encryption
scheme that children practice
cracking, because to the child's
particular subculture the backdoor
is common knowledge.
Using any government-endorsed
encryption scheme is likewise
foolish based on multiple evidences and
commonly held beliefs.
www.distributed.net and the like take
great joy in cracking such
endorsed encryption, just to prove it
can be done (in fact, I am
running their client as I type).
Anything can be justified in the
name of National Security.
Expensive and unpopular are the only
viable solutions. With
the rate of change in the computer
industry, even combining them
may not be enough.
Expensive: Corporations must hire
and maintain the employment
of the best cryptographers. If hired
away, or allowed to self-employ,
secrets will always go with the person.
No legal recourse can stop it.
This is a return to employment-for-life.
This, of course, is unpopular, but
won't be as unpopular as each
company having to create and maintain
it's own private encryption
scheme; not available anywhere else.
There is no off-the-shelf solution to
truly secure encryption, and
there is no room for a burocracy.
-mycroft
ps.pgp is not bad because it is free.
it is bad because it is only
Pretty Good Privacy.
-m
Mok-Kong Shen
<[EMAIL PROTECTED]> wrote in
message
news:[EMAIL PROTECTED]...
> Markku J. Saarelainen wrote:
> >
>
> > Some of most popular encryption
applications have backdoors and their
> > development projects have been
supported and influenced by certain
> > specific intelligence-interest
groups. In the future's electronic
> > commerce environment these
encryption methods and technologies
shall
> > become even more important for any
corporation anywhere around the world
> > and it is highly recommended to
avoid using any of the most popular
> > and/or free encryption applications
for any business and commercial
> > purposes."
>
> I am afraid it is not very clear what
you are proposing for use in
> 'applications for business and
commercial purposes'. On superficial
> reading at least, one could deduce
that anything (1) non-popular
> and (2) very costly would qualify in
your opinion. (PGP is free.
> Do you think that it is bad because it
is free?) So I believe you
> should elaborate your points more
concretely to enable better
> comprehension of your article by the
general readers.
>
> M. K. Shen
------------------------------
Date: Sun, 21 Nov 1999 19:55:53 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Nova program on cryptanalysis -- also cipher contest
Sean A. Walberg wrote:
> Define some strings that we know are in the plaintext -- STOP,
> BEWAREICEWEASELS, etc. Substitute in each one in each possible place.
> Right off the hop you can eliminate a lot for breaking rules of
> Playfair, ie plaintext equalling cyphertext, no one to one mapping of
> plain and cyphertext.
Well, BE WA RE IC EW EA SE LS was certainly not chosen by accident as a
clue for this particular cipher. Notice the many combinations of the
letters E, W, and A that occur in this particular phrase. And of course
they flat tell you what the last word in the plaintext -is.-
======================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> High-speed, script-driven, table repair/support for Paradox/BDE...
> ChimneySweep{tm}: "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/cs3web.htm
------------------------------
From: Raphael Phan Chung Wei <[EMAIL PROTECTED]>
Subject: Re: Schneier's how to be a cryptanalyst paper
Date: Mon, 22 Nov 1999 10:58:58 +0800
Yeah, how do we know whether the method we are using or the assumptions that we
make about the amount of information we know, are reasonable?
Adam Durana wrote:
> Heh 2 32bit sub keys to a cipher with a 64bit key size. I don't know what I
> was thinking, possibly I wasn't at all. I would still like to know what
> attack I should be using though.
--
Regards,
Raphael Phan
Faculty of Engineering
Multimedia University
+603-83125314
------------------------------
Date: Sun, 21 Nov 1999 22:47:53 -0500
From: "Cory C. ALbrecht" <[EMAIL PROTECTED]>
Subject: Values in bf_init for Blowfish in 16 & 20 round versions
Hello all,
I was just looking at the code I have for blowfish, which is in 2 files
presently, one for a 16 round version and the other for a 20 round
version, done so becuase the original I based my code on had an #ifdef
in it which added the extra 4 rounds in the appropriate places, as well
as to change the struct for the blowfish key. (I use C/C++, BTW.) Now
the second element in the struct is an array 1024 in length, and as far
as I can tell is always that long. The first element in the struct is
another array that is (rounds + 2) ing length.
typedef struct _BF_KEY {
unsigned long P[16 + 2];
unsigned long S[4 * 256];
} BF_KEY;
Now this is where I get confused - the set key function uses an initial
key which is modified based on the password data given to the function.
In the function there is a for loop, the length of which is (rounds +
2), just like in the struct for the key. The problem is that initial
key's first elemrnt is only 18 long - 16 + 2.
static BF_KEY bf_init= {
{
0x243f6a88L, 0x85a308d3L, 0x13198a2eL, 0x03707344L,
0xa4093822L, 0x299f31d0L, 0x082efa98L, 0xec4e6c89L,
0x452821e6L, 0x38d01377L, 0xbe5466cfL, 0x34e90c6cL,
0xc0ac29b7L, 0xc97c50ddL, 0x3f84d5b5L, 0xb5470917L,
0x9216d5d9L, 0x8979fb1b
},{
0xd1310ba6L, 0x98dfb5acL, 0x2ffd72dbL, 0xd01adfb7L,
// and on and on for 1020 more values
Shouldn't there be 4 more values in there, to make it 20 + 2 for when a
20 round blowfish is chosen? Or are the remaining ones assumed to be set
to 0? Is there a way that I can generate that set of values that is
(rounds + 2) in length myself, or are they set by fiat in the Blowfish
spec? (I'd assume "because those are the best values for the given
purpose")? Can I make blowfish do an arbitrary number of rounds, or must
it be an even number or is there some upper limit?
Thanks in advance.
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Have more hints. Re: ... also cipher contest
Date: Mon, 22 Nov 1999 04:13:37 GMT
I'm making both (long) algorithm and cryptanalysis comments. While I
don't mention a solution, the cryptanalysis comments may spoil your fun.
If so, don't read beyond the small hint warning.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> What I'd like to do is try to build squares out of the guesses, and
> hope that I can break more rules there to eliminate more guesses.
That worked for me.
> The only way I can see it though, is to do every combination.
Yes, but make simplifying assumptions to limit your search space.
> For the rectangular rule, this generates 8 possibilities each digram.
Perhaps you saw a simplification I did not see. For the rectangular
rule in a 5x5 square, the pairs of letters can be separated by zero,
one, two, or three columns (perhaps using wraparound); and zero, one,
two, or three rows. That makes sixteen possibilities.
> For the row and column rules, it adds 15 each.
AFAICS, this is only true if the positioning is unconstrained--a
condition my scripts skip.
One useful observation is that only the *relative* position of the
letters matters (modulo the size of the square, so "negative"
transpositions can be expressed as a least residue); the absolute
position does not. Using underscores to represent unknown letters, the
following squares both encipher/decipher and constrain future
plaintext-ciphertext bigrams identically (pray that DejaNews doesn't
scramble my monospaced examples):
_____ _____ _____
_____ _____ _____
_____ _____ _____
__BL_ ___BL L___B
__FE_ ___FE E___F
__FE_ ___FE etc.
_____ _____
_____ _____
_____ _____
__BL_ ___BL
etc.
Therefore, one may assume--without loss of generality, as a
mathematician would say--the position of *one* letter. (After the first
letter, a further assumption is an assumption about relative position.)
Doing so may make it more difficult to see the mnemonic original key,
but it does not impair recovery of a square that works. Here's an
example:
Suppose you slid "beware ice weasels" along the ciphertext, skipping
locations where l, e, r, or w are enciphered as themselves. There are
reasons to skip a few more, but that's in the small hints at the end.
The position is then as follows:
be wa re ic ew ea se ls
LF NV UH DW AR DL CF FB
Since e occurs five times in the probable plaintext, it makes a nice
"anchor." Arbitrarily assign it to the upper left-hand corner of the
Playfair square, a position I'll call (0,0). As I mentioned above,
there are 16 permutations in which the rectangular rule is valid for the
plaintext-ciphertext bigram. For brevity, I'll write "BLEF" (like the
row rule) for this pair. There are now, however, only two permutations
in which the ERDL row rule is valid for BLEF:
EFBL_ EF_BL
(Follow with four rows of unknown letters.)
Similarly, there are only two permutations in which the EDDU column rule
is valid for BLEF.
> So far, I'm able to pull out about 5 or so possibilities, so I'm
> looking at storing several thousand tries in memory,
No! As shown above, the first plaintext-ciphertext bigrams have
produced only 16 + 2 + 2 = 20 permutations. I stored these in a pipe;
one could write them to disk in the form above.
Practically, one way to approach this, after assuming one letter, is to
realize that the choice of the second plaintext or ciphertext (whichever
the first letter was) letter completely determines the position of the
remaining two. In the example above, E at (0,0) means B can be anywhere
except these positions: (0,0), because E is there; (1,0) and (0,1),
because E would encipher as B; and (4,0) and (0,4), because B would
encipher as E. That leaves 25 - 5 = 20 positions.
If the position being evaluated happens to be the following, there are
only two permutations for the first plaintext-ciphertext bigram BFEB:
BE WA RE IC EW EA SE LS
FB SD EW NP XK IC FT RE
>From this follows the suggestion in the Army manual about bigram pairs
to choose first.
> though I expect a lot to be eliminated each time a new digraph
> is entered.
Yes! In the first example above, after BLEF, skip WNAV, as it has no
"anchor" (if there are any possible squares after EAWR, the "W" will
then serve as an anchor, if you like). Try RUEH with E as an anchor.
There aren't 20 permutations of RUEH for each BLEF, because the "B", "L"
and "F" occupy 3 positions. There are only 17 places that R could go,
and of those, "collisions" with other letters make some impossible,
producing 184 total permutations. By hand, I abbreviate these
permutations into families; by computer, it is easy to list them all.
Adding EAWR reduces the possibilities to 28. (I won't tell you the end
of the sequence because then you'd know whether or not to evaluate it.
:-))
WARNING: From this point onward are *small* hints.
> If, after adding all the suspected digraphs, any squares
> remain, it can be listed as a possibility.
Very few remain.
> Define some strings that we know are in the plaintext -- STOP,
> BEWAREICEWEASELS, etc. Substitute in each one in each possible place.
> Right off the hop you can eliminate a lot for breaking rules of
> Playfair, ie plaintext equalling cyphertext, no one to one mapping of
> plain and cyphertext.
Don't forget "end". If it occurs, as either of the following:
e nd or en dx
UF BG UF BG
it gives one encipherment for "e" (F or U). (No application of the
three Playfair rules could produce XX, so those must be nulls.)
*Wherever* "E" occurs in the square, it can encipher into only five
other letters: using x-y as (column, row), the ciphertext letters can
be (+1,0), (+2,0), (+3,0), (+4,0), and (0,+1); all additions are modulo
5. This limitation is a consequence of the rectangular rule taking the
letter in the same row.
Consequently, *if* you assume that "end" occurs there, no position for
"beware ice weasels" in which "e" enciphers as five different letters
(other than F or U) is valid.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: math
Reply-To: [EMAIL PROTECTED]
Date: Sun, 21 Nov 1999 22:36:51 GMT
On Sun, 21 Nov 1999 14:29:10 GMT, JPG wrote:
>Hello
>
>I'm looking for a crypt system with something interesting for my maths
>studies.
>Could you help me (I'm already aware of RSA) ?
you can look at elliptic curves. www.certicom.com has tutorials.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 07:24:50 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
..
>
>In reality, I suspect he realizes the error in the logic here as well
>as I do. I believe, however, that he was trying to give the illusion
>of winning an argument. The situation's pretty simple: he knows the
>error recovery inherent in CBC is useful and important, but doesn't
>want to admit it. To try to get me (or anybody else who would reply)
I admit few use ther error recvoery feature and that it mostly
helps the NSA
>to admit to the contrary, he picked PGP out and tried to get somebody
>to show how it would do this. PGP uses CFB, which lacks exactly that
>capability. If somebody tried to show how the capability would be
CFB suffers from the same faults as CBC. Namely you
can hex edit the middle of an encrypted file that used CFB and
only a small portion where the editing occurs will be in error.
I know PGP used CFB I have been arguing with John Svard on
this topic for years. But it is impossible to get him to adimt
he is very wrong. If I give you the impression that PGP used CBC
I am sorry. If I typed that it did it was a mistake. BUt ask John this
has been an on going argument with him for years.
>used with PGP, they would face one of two possibilities: they could
>either admit that it's not there, or else incorrectly try to show how
>to do it. Since the capability really IS lacking in CFB, he could
>pounce on either of these as "proof" of all his usual nonsense about
>the "three-letter" chaining modes being worthless, all the AES
>candidates being weak, etc. In reality, he would have proven nothing,
>but from the looks of things that wouldn't have stopped him from
>claiming whatever he wanted and probably even convincing some people
>that he was right.
>
>OTOH, let's look at (more or less) the original question: how would a
>user make use of error-recovery in a system that used CBC? First of
>all, a typical dynamic, stream-oriented compression wouldn't be used.
>You'd either use no compression, a static compression, or else have
>the compressor work in blocks, typically the same size blocks as the
>cipher is going to use.
What are you talking about have the compress work on the same size
blocks as sthe Cipher. But isnt the compressor supose to make the
blocks smaller.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: "OTTO" <[EMAIL PROTECTED]>
Subject: public-key updating attack
Date: Mon, 22 Nov 1999 14:23:43 +0800
Dear all,
what is the "public-key updating attack?
Thanks.
OTTO
------------------------------
** 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
******************************
