Cryptography-Digest Digest #759, Volume #11 Fri, 12 May 00 08:13:01 EDT
Contents:
Re: An argument for multiple AES winners (Mok-Kong Shen)
Re: Cipher contest analysis [several] ("Adam Durana")
Re: AES final comment deadline is May 15 (Mok-Kong Shen)
Re: TLAs (was: Re: Tempest Attacks with EMF Radiation) ([EMAIL PROTECTED])
Re: Prime Generation in C,C++ or Java (Mark Wooding)
Re: zeroknowledge.com and freedom.net - Snake oil?
([EMAIL PROTECTED])
Re: Cipher contest analysis [several] (Runu Knips)
Re: Cipher contest analysis [several] (Tom St Denis)
Re: How does one test an encryption algorithm? (Mark Wooding)
Re: UK issue; How to determine if a file contains encrypted data? (Runu Knips)
Re: AES final comment deadline is May 15 (Runu Knips)
Re: Cipher contest analysis [several] (Mark Wooding)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Date: Fri, 12 May 2000 08:47:26 +0200
DJohn37050 wrote:
> At the LEAST it is free publicity for Hitachi.
I suppose it is even known to the kids that commerical firms
want only one single stuff, MONEY, and certain want money by
all available means, even almost at or beyond the boundary of
legality, e.g. industrial espionage. (Unfortuneately one has the
impression that some academics also have this mentality,
though.) Thus it is very understandable that Hitachi choose an
optimal time point to bring out its patent claims in the present
case. Even if it knows that it wouldn't suceed in enforcing the
patent claim and the issue is for creating only a 'story' (and thus
gaining publicity for free, as you pointed out), why shouldn't
it do that in the viewpoint of its management?
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Cipher contest analysis [several]
Date: Fri, 12 May 2000 02:49:06 -0400
> I found Pikachu rather poorly written, with massive portions that would be
> needed to make it work left out. There are two very good examples, 2PHT is
> specified as the following
> 2PHT(a, b) -> (a', b')
> a' = 2a + b
> b' = a + b
Think of it this way.
2PHT(a, b) -> (x, y)
x = 2a + b
y = a + b
Using a' and b' is common practice. The prime mark (the ') basically means
its a different variable. So a' does not imply a. Perhaps you thought it
meant the compliment?
> Where it is quite unclear whether the a used in the second line is the a
> from the first line. It is also never specifed how the replacement is to
> take place. The second example is his use of <<< which, since I know his
> typical lanuage should be <<, but without more specification it is
entirely
> possible that he meant something else. Without a complete specification it
> is impossible to analyze the result. I also found a description of the key
> schedule conspicuously missing, leaving the only reasonable decision to be
> that the same keys are used for each duoble round, so a slide attack is
> perfectly valid. Even without a full specification if this is in fact the
> case, the cipher is nearly trivial.
Actually I am sure by >>> Tom meant circular shift or bit rotation. >>> is
quite commonly used, look at some papers describing other algorithms. But
you are right, something like that should be defined atleast once in the
paper.
> I also noted that unlike what I was informed of when I submitted my cipher
> (which was in fact the reason my cipher is not listed), of these only LJA1
> seems to supply the decryption, which should have eliminated the others
from
> the contest before I ever saw them.
Actually your submission was not accepted because your source code did not
implement a decryption function. The requirements clearly state that the
reference source code must include a decryption function. If you wrote a
decryption function like I said in an email to you I would gladly put it in
the listing.
- Adam
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Fri, 12 May 2000 10:24:37 +0200
DJohn37050 wrote:
> This is just a reminder that the AES final comment deadline is May 15. See
> http://www.nist.gov/aes for details.
Maybe I am wrong, but I have the impression that AES has
somehow attracted much less attention than it evidently
deserves. I subscribed from the beginning to a mailing
list specific to AES. However, its traffic has been very
extremely low. In a number of other crypto mailing lists,
the situation about posts on AES is not very much better.
As I noted earlier, I first learned of the patent issue
from discussion in this group. Even in our group,
discussions on AES are comparatively infrequent.
(Exceptions could be named. Recently, even I myself
initiated two threads about AES. But that's not the
point.) There were some indication of enthusiasm in this
group at the start of AES project years ago. However,
that ebbed in my humble view. I find the phenomenon here
described to be very remarkable and very difficult to
understand. Isn't AES destined to be T H E encryption
algorithm of the 21st century? Why does the crypto
community pay so little attention to it? Do people
take the standpoint that AES will certainly come out to
be perfect and satisfactory in all respects because the
best of best of academics are doing that job and hence
it is a waste of time to care anything about it?
(Afterall, laymen and even priesters don't attempt to
mix themselves into the business of the popes.) That
attitude could eventually become regretful, should it
turn out, e.g. that users would have to pay substantial
patent license fees for applying that non-plus-ultra
encryption algorithm.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TLAs (was: Re: Tempest Attacks with EMF Radiation)
Date: Fri, 12 May 2000 08:18:36 GMT
In article <8fbk5m$dh7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8fb8bk$4pd$[EMAIL PROTECTED]>, Jonathan Thornburg
([EMAIL PROTECTED]) wrote:
> > In article <8f0pl8$[EMAIL PROTECTED]>,
> > Guy Macon <[EMAIL PROTECTED]> wrote:
> > >What really ticks me off is Asynch Transfer mode. Uh, fellows, the
> > >acronym "ATM" is already taken...
>
> At the Moment?
>
> > Only in some parts of the world. The thing you put a bank card into
> > to get money, which is an "ATM" (Automatic Teller Machine) in Canada
> > and the USA, is a "bankomat" in Europe.
>
> It's an ATM in the UK too.
>
More commonly known as "the hole in the wall" as in "I'm going to get
some money from the hole in the wall" ;)
Neil
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Prime Generation in C,C++ or Java
Date: 12 May 2000 09:26:02 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
[snip]
> an application program can't rely on the 'certainty' parameter
> implying the use of that number of iterations of any specific test.
This is true. In relation to the information I posted previously, I
assert that this is a shining example of broken interface design.
Running 40 Rabin-Millers (or Fermats -- they're about the same speed;
Solovay-Strassen is slower) on a 1024-bit number is a total waste of
time.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: zeroknowledge.com and freedom.net - Snake oil?
Date: Fri, 12 May 2000 10:33:13 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> "Dr. Yongge Wang" wrote:
>
> > Surely I agree with you that is not a practical attack..
> > which is just the same as the key-escrow system or the
> > threshhold cryptosystem... I have just had a rough look at
> > their whitepage (I have to say that I have no time to look
> > at details, so I may wrong some where)..It seems that
> > there is much for the deployment of the Freenet servers.
> > If all the servers are deployed by ZKS, then indeed you
> > have no privacy. You have to trust ZKS (ZKS can easily
> > trace you). Then the problem is why we need a such complicated
> > system instead of choosing a simple anonymizer proxy like
> > www.anonymizer.com ?
>
> Most of the Freedom servers are owned and are run by
> independent servers, and a user can choose which servers
> he wants to use for his route. You can choose servers from
> the US, Canada, Japan, operated by people you thrust. This is
> a big difference from the Anonymizer system.
BUT:
a.) Freedom is only available for Windump 95 & 98
b.) You have to install software
c.) Freedom doesn't work behind firewalls
d.) You have to buy it and therefore reveal your name,
address, email, phone number & your creditcard-number
So ZKS CAN'T be a good choice ...
FREE, for every Operating System, No installation,
works behind Firewalls, ready to use in ZERO seconds:
http://anonymouse.home.pages.de/
GreetingX,
Alex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 12 May 2000 13:11:17 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Cipher contest analysis [several]
ashwood wrote:
> I found Pikachu rather poorly written, with massive portions that would be
> needed to make it work left out. There are two very good examples, 2PHT is
> specified as the following
> 2PHT(a, b) -> (a', b')
> a' = 2a + b
> b' = a + b
> Where it is quite unclear whether the a used in the second line is the a
> from the first line.
Hmm ? That is mathematical notation. a is always a, i.e. no variable is
ever
changed in its value, instead one assigns a'. In the concrete program,
you
would write (C syntax):
b += a; a += b;
or (Pascal):
inc(b,a); inc(a,b);
which has the same effect, because in the program you don't need the old
values of a and b anymore.
> [...]The second example is his use of <<< which, since I know his
> typical lanuage should be <<, but without more specification it is entirely
> possible that he meant something else.
Wrong. '<<' is left shift, while '<<<' is left rotation. Again it is
quite
common to write it this way. Rotation of a 32 bit value, in C, can be
defined as (C syntax):
#define rotl(x,n) (((x) << ((n) & 31)) | ((x) >> (32 - ((n) & 31))))
#define rotr(x,n) (((x) >> ((n) & 31)) | ((x) << (32 - ((n) & 31))))
or (Pascal syntax):
procedure rotl (x: dword; n: byte): dword;
begin n := n mod 32;
rotl := x shl n + x shr (32 - n);
end;
procedure rotl (x: dword; n: byte): dword;
begin n := n mod 32;
rotl := x shr n + x shl (32 - n);
end;
or (Turbo Pascal under x86):
procedure rotl (x: dword; n: byte): dword; assembler;
asm
mov cl,n;
mov eax,x;
rotl eax,cl;
end;
procedure rotr (x: dword; n: byte): dword; assembler;
asm
mov cl,n;
mov eax,x;
rotr eax,cl;
end;
Rotation is a very often used operation in crypto.
> I also found a description of the key schedule conspicuously missing,
> leaving the only reasonable decision to be that the same keys are used
> for each duoble round, so a slide attack is perfectly valid. Even
> without a full specification if this is in fact the case, the cipher
> is nearly trivial.
It would be silly to use the same key in every round.
> MMBooze is also very incomplete, and makes no complaint about it, stating
> that "there can be a zillion varients" I actually stopped reading there,
> because going further would only have wasted time with something that is
> again, not fully specified.
Well have you ever read, for example, the specification of the AES
candidates ?
> LJA1 is subject to a rather interesting attack, based on the fact that it
> has such a small block size, the maximum limit for rounds of the cipher
> contect was placed at 16, making the maximum block size of LSA1 4 bits,
> given that small of a cipher, it is trivial to create a complete reversal,
> by simply storing the permutations, leaving a simple substitution cipher.
>
> I also noted that unlike what I was informed of when I submitted my cipher
> (which was in fact the reason my cipher is not listed), of these only LJA1
> seems to supply the decryption, which should have eliminated the others from
> the contest before I ever saw them.
The decryption is not necessary to be specified as long as it is totally
clear how it should look like.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Cipher contest analysis [several]
Date: Fri, 12 May 2000 11:10:38 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <ugMyKr8u$GA.303@cpmsnbbsa04>,
"ashwood" <[EMAIL PROTECTED]> wrote:
> I had some spare time today, so I decided to begin my analysis of
> the entrants to the cipher contest. SO here we have preliminary
> results against what I reviewed.
>
> I found Pikachu rather poorly written, with massive portions that
> would be needed to make it work left out. There are two very good
> examples, 2PHT is specified as the following
> 2PHT(a, b) -> (a', b')
> a' = 2a + b
> b' = a + b
> Where it is quite unclear whether the a used in the second line
> is the a from the first line. It is also never specifed how the
> replacement is to take place. The second example is his use of <<<
> which, since I know his typical lanuage should be <<, but without
> more specification it is entirely possible that he meant something
> else. Without a complete specification it is impossible to analyze
> the result. I also found a description of the key schedule
> conspicuously missing, leaving the only reasonable decision to be
> that the same keys are used for each duoble round, so a slide
> attack is perfectly valid. Even without a full specification if
> this is in fact the case, the cipher is nearly trivial.
>
> MMBooze is also very incomplete, and makes no complaint about it,
> stating that "there can be a zillion varients" I actually stopped
> reading there, because going further would only have wasted time
> with something that is again, not fully specified.
It was very quickly written, however..
prime notation is normally used when you convert a computer stmt to
algebra. expressions like 'a = 2a + b' are not technically valid, so
I used the prime notation. Yes a' and b' replace their inputs,
sorry.
And <<< is long since understood to mean a cyclic shift left, >>>
cyclic shift right.
The key schedule is too simple to explain, just look at the supplied
source code.
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
Comment: Public Key at http://www.tomstdenis.com
iQCVAwUBORwR1nDaq5QeLg0RAQFKVgP/cGoGm58k31Vy5QwLGyB6IVtubQuNu4z1
/WNjCrBXINKmnJY7afDWVW5ctu76w+3WvXwaRwiNqbL83yysDgek+ylPNn7fk5IV
B2GXv0D1X4Hd06tvEpZsNJcNpgZNxdi7hwNJdpZ17nDbN2iWija88HMWHTvAL19x
ibYsM1zLlOg=
=g7sW
=====END PGP SIGNATURE=====
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: How does one test an encryption algorithm?
Date: 12 May 2000 11:29:20 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > Or use one of those well-tested algorithms already available, such
> > as Blowfish, or Rijndael, Serpent, Twofish, or others.
>
> Yeh yeh yeh, and how much fun is /that/ for a programmer? :-)
Actually, I found both Rijndael and Twofish to be rather interesting to
implement. They took me about a day's work each, from blank source
files to an implementation which passed the AES test vectors, and lots
of the hair-tearing and head-slapping which I find tends to accompany
debugging of crypto primitives.[1]
[1] The problem is that the algorithm will tend to either give you the
right answer, or something utterly unrelated to the right answer
giving you no clue as to what exactly it was that went wrong. And
while this is right and proper for a strong block cipher, it's a bit
of pain when writing the things.
-- [mdw]
------------------------------
Date: Fri, 12 May 2000 13:31:16 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: UK issue; How to determine if a file contains encrypted data?
[EMAIL PROTECTED] wrote:
> This thread seems to neglect the fact that while being too random may
> be cause for suspicion on the part the police, it is not proof that
> the apparently random bits are in fact ciphertext.
Correct, this has been stated by multiple people in this thread,
including my little existence.
> In the absence of access to keys which will prove that it is ciphertext,
> by deciphering it, they cannot prove anything. It is more likely that
> they will rely on circumstantial evidence, such as the number of such
> files, the presence of encryption software on the machine, and traffic
> analysis. All this doesn't necessarily amount to proof however.
But the policemen don't need to search for further proofs. The
only proof you can have that a random sequence is ciphertext is
if you know the cipher and the cipher key, which lead into some
valid plaintext.
In fact, you can give them any key and any cipher, stating that
the data you've enciphered was random data. But I fear nobody
would believe you.
> My guess is that it is a classic example of a law, like alcohol
> prohibition, that will simply force the prohibited activity
> underground, so that the ordinary punter has less access, while the
> seriously bad guys simply invest in more sophisticated set ups that
> will maintain their access and be pretty much unpoliceable.
Which means Steganography might become quite popular in Britain. Or
the thankful crypto filesystem of Linux where you can always hide
additional data without letting people know.
------------------------------
Date: Fri, 12 May 2000 13:42:28 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Mok-Kong Shen wrote:
> Isn't AES destined to be T H E encryption algorithm of the 21st century?
Well, at least of the first quarter of the 21st century. Maybe
even less time. AFAIK Crypto is developing very fast.
> Why does the crypto community pay so little attention to it?
There are still many people which believe XYZ, their well-known
cipher, is more trustable and got more attention than the AES
candidates. I don't think so. No other algorithm got more
(public) interest than these.
> Do people take the standpoint that AES will certainly come out
> to be perfect and satisfactory in all respects because the
> best of best of academics are doing that job and hence it is a
> waste of time to care anything about it?
Hey, I surely think there are far better cryptoanalytics out
there, than me ;-) I've still problems to understand what this
GF(anything) thing really means etc. I've still found no time
to study this mass of papers about AES at home. At least in my
case its just a hobby.
> That attitude could eventually become regretful, should it turn
> out, e.g. that users would have to pay substantial patent license
> fees for applying that non-plus-ultra encryption algorithm.
I don't understand; the AES candidates shouldn't be patented ?
(I know there have been some claims there are patents, but I
don't think they're real and will withstand the pressure of a
worldwide interest to have AES for free).
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Cipher contest analysis [several]
Date: 12 May 2000 11:47:04 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> expressions like 'a = 2a + b' are not technically valid
Yes, they are; they just mean different things from what a C programmer
would expect. The above implies simply that a = -b, which is a
completely reasonable thing to assert, although not what's actually
intended.
> The key schedule is too simple to explain, just look at the supplied
> source code.
You should aim to make your textual description detailed and precise
enough for someone to be able to make a compatible implementation given
no other information. `Look at the source', in my opinion, doesn't cut
it.
-- [mdw]
------------------------------
** 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
******************************
