Cryptography-Digest Digest #660, Volume #12 Tue, 12 Sep 00 05:13:01 EDT
Contents:
Re: SV: Intel's 1.13 MHZ chip (John Savard)
Re: CAST-Cipher / CAST-Algorithm (John Savard)
Re: RSA public exponent ("Scott Fluhrer")
Re: Camellia, a competitor of AES ? (Hideo Shimizu)
Re: Getting Started, advice needed (FAQs , yes I read them) (Andy C)
Re: Camellia, a competitor of AES ? (Hideo Shimizu)
Re: Getting Started, advice needed (FAQs , yes I read them) (Andy C)
Re: Camellia, a competitor of AES ? (Hideo Shimizu)
Re: Getting Started, advice needed (FAQs , yes I read them) (Andy C)
Re: Getting Started, advice needed (FAQs , yes I read them) (Andy C)
Re: CRC's as MAC's (D. J. Bernstein)
Re: Scottu19 Broken (Johnny Bravo)
Re: RSA public exponent (Thomas Pornin)
Re: nice simple function (Mok-Kong Shen)
Re: Steganography and secret sorting (Mok-Kong Shen)
Re: Camellia, a competitor of AES ? (Mok-Kong Shen)
Re: Camellia, a competitor of AES ? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SV: Intel's 1.13 MHZ chip
Date: Tue, 12 Sep 2000 05:03:49 GMT
On Sun, 10 Sep 2000 01:29:25 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>K - kilo m - milli 1 000
Oops, that should have been small k for kilo.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: CAST-Cipher / CAST-Algorithm
Date: Tue, 12 Sep 2000 05:17:29 GMT
On Mon, 11 Sep 2000 23:33:03 +0100, "Brian Gladman"
<[EMAIL PROTECTED]> wrote, in part:
>> > can anyone of you send or tell me where to get a good description of
>> > the (function of the) CAST-Cypher / CAST-Algorithm (256-bit version
>> > pereferred). It would also be great if you coud send me or tell me
>> > where to get an implementation (C++-source-code preferred) of said
>> > cipher / algorithm.
>I have a C version of the CAST cipher submitted in AES round one on my
>web site at:
> http://www.gladman.uk.net/
>It would be easy to put into C++
Since you (the original poster) are interested in CAST-256, the AES
entrant, my web page has a description of that cipher on it, complete
with a diagram, at:
http://home.ecn.ab.ca/~jsavard/crypto/co040810.htm
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RSA public exponent
Date: Mon, 11 Sep 2000 22:16:24 -0700
Bob Silverman <[EMAIL PROTECTED]> wrote in message
news:8pk2e3$vab$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> <snip>
>
> > Keep in mind that phi(n) and lambda(n) are equivalent for this
> purpose,
> > because phi(n) and lambda(n) factor into the same primes (albeit
> possibly
> > with different exponents). Hence to be relatively prime to one is to
> > be relatively prime to the other.
>
> Not quite. We have (2, lambda(N)) = 1, whereas (2, phi(N)) = 2.
>
Huh? lambda(N) (for N in the form pq, for odd primes p and q) is always
even, and hence (2, lambda(N)) = 2.
For such N, lambda(N) = lcm(p-1, q-1). Since p-1 and q-1 are both even,
then their least common multiple must also be even.
For example, if N=15=3*5, then,
phi(N) = (3-1)*(5-1) = 8
lambda(N) = lcm(3-1, 5-1) = 4
--
poncho
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Tue, 12 Sep 2000 15:49:12 +0900
[EMAIL PROTECTED] wrote:
>
> Hideo Shimizu <[EMAIL PROTECTED]> wrote:
> > 1) ISO entry
> > Now, ISO standarize some cryptographic algorithms (block cipher, stream
> > cipher, public-key cipher). Japanese national body will entry this project.
> > Camellia is one of the five block ciphers.
>
> The ISO has "registered" block ciphers for a while, choosing not to
> standardise any of them. For example, B-CRYPT, IDEA, and LUC are all
> "ISO/IEC 9979 Registered" but none are a standard. Since there are
> absolutely no requirments for registration, execept for it being
> submitted by a national body, I'm not really sure I see the point.
Yes.
But, new project for deciding standard is now progressing.
>
> Personally, I think the ISO should probably follow NIST and declare
> the AES winner a standard.
I hear that U.S. National body entry AES final winner to ISO's new algorithm
standard.
------------------------------
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
From: [EMAIL PROTECTED] (Andy C)
Date: Tue, 12 Sep 2000 06:57:47 GMT
On 11 Sep 2000, [EMAIL PROTECTED] (Douglas A. Gwyn) spake in
<[EMAIL PROTECTED]>:
>Andy C wrote:
>> Hmm - I did the 2's complement and it worked out rather odd.
>> FFFF9A19, ...
>
>However, the system is so easily reversed (as shown in
>other posts) that trying to exploit the properties of
>the addition of FFFF9A19 is not the easiest way to proceed.
Thanks - learning where not to bother to look is pretty
important from what I have seen here.
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Tue, 12 Sep 2000 15:52:08 +0900
Mok-Kong Shen wrote:
>
> Hideo Shimizu wrote:
> >
> [snip]
>
> > I have read this information from Japanese newspaper or magazines.
> > I do not know relationship among above projects. However, I guess
> > more algorithms.
>
> I suggest that you convey, if possible, to your national
> standardization body (which submits the Japanese algorithms
> to ISO) the general users' wish that the algorithms be free
> of patent issues. Thanks.
>
> M. K. Shen
I agree.
Unfortunately, I am not member of national body comittie, so I can't
tell it to them.
------------------------------
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
From: [EMAIL PROTECTED] (Andy C)
Date: Tue, 12 Sep 2000 07:01:15 GMT
On 11 Sep 2000, [EMAIL PROTECTED] (Scott Fluhrer) spake in
<8pjtlg$ncn$[EMAIL PROTECTED]>:
>One obvious thing to ask: if you were doing a brute force attack, how would
>you recognize the plaintext?
Well I looked at that - and it seemed to be compressed. So I checked
out Zlib since thats a common crompression libe due to it being
unencumbered, and thats what was used to compress the data group
before it gets run through this. I was thinking of using the
compression header as known text. After all, other than the tree
at the front, compressed data is supposedly fairly random?
Is that the right way to go about thnking about attacking this?
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Tue, 12 Sep 2000 15:54:49 +0900
Runu Knips wrote:
>
> David A Molnar wrote:
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > NTT and Mitsubishi will propose Camellia in response to
> > > calls for contributions from ISO/IEC JTC 1/SC27 and are
> > > aiming at adoption as a international standard.
> >
> > This is nice, but does it tell us whether Camellia will be released to the
> > public domain ? i.e. does the ISO require standardized algorithms to be
> > unpatented?
>
> I believe I've read recently in Bruce Schneiers Applied Crypto
> that ISO standardization only guarantees that the algorithm
> exist. But I don't have the book at hand and I might of course
> be wrong.
That information is old.
1999 October, new standarization was started.
------------------------------
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
From: [EMAIL PROTECTED] (Andy C)
Date: Tue, 12 Sep 2000 07:07:50 GMT
On 11 Sep 2000, [EMAIL PROTECTED] (Paul Pires) spake in
<yNav5.67776$[EMAIL PROTECTED]>:
>you use this system, you must keep it secret as long as the key is used
>AND for as long as any information protected by that key needs to be
>secret, not just that piece itself.
>
>If you mean that you have a way of securely distributing new keys often
>enough, then you have cable TV and plush carpeting in an outhouse. Your
>encryption quality
>doesn't live up to your key management.
LOL, this is a fair statement. I've started to probe how this thing
distributes the keys. After reding up some more, it seems that with a simple
system like this, recovering the keys from the exchange might be easier than
breaking the algorithm. I'd like to do both if possible in my program.
>>so this may be a "safe" method, if an "automated" way of
>> breaking the keys back is not found.
>
>I just described one. Pancho fixed it. A good programer could write you up
>an app from this. Your key in miliseconds if any plaintext is known. a
>little longer if plaintext needs to be guessed but this is always much
>easier than guessing the key since the plaintext has value, structure and
>meaning probably known in a general way to your adversary. If it was
>random gibberish, Why hide it? If your adversary is oblivious to your
>traffic. why does he worry you? If you want to be safe and assume a worst
>case, go all the way and assume he is very formidable and knowledgable.
>Maybe even sneaky.
[snipped]
>give-aways. If an adversary knows you start out with some predictable
>header information. Date, time, name, ID, settings, then you are well and
>truely hosed.
Good, I was re-reeading your stuff, and the cleanup on it, and I believe
I can write a reverser in C, and the only thing I need to do is work
hard to do is automating the "known plaintext" guessing part. Which
I guess requires more thought of a type that Im not used to doing.
>> Any particular places I should go to read and learn?
>
>Bruce Schneier's book Applied Cryptography is always good general starting
>point. I'm sure you'll get a lot more suggestions from folks in here who
>actually
>know this stuff :-)
Thanks - I went out and got Schnieier's book when I first ran into
this. Its a goldmine, but more along the lines of real cryptosystems,
not the apparently rinky dink one Im trying to work on. The feedback
here is what I need in order to learn apparently. Im just a new boy,
stranger in this town...
------------------------------
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
From: [EMAIL PROTECTED] (Andy C)
Date: Tue, 12 Sep 2000 07:09:22 GMT
On 11 Sep 2000, [EMAIL PROTECTED] (Paul Pires) spake in
<V5bv5.68003$[EMAIL PROTECTED]>:
>
>Andy C <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Is there a way to actually write a "decode" routine - in other words,
>> what I set out to do was creat an "anti-algorithm", one that could be
>> fed a block of unknown ciphertext, and spit out the key. I was thinking
>> that was possible, but maybe a known or chosen plaintext would be
>> needed. What would you think about in terms of doing something like
>> that? Its not really needed, but would be a rather neat thing to try to
>> come up with (and show off).
>
>Sounds like a good first project. Don't cheat. Think, reason it out,
>research, study
>And only ask for help when you are really stuck.
thanks will do - you've certainly given me enough to chew on - Im not quite
so high on the crypto food chain, so this much is plenty for me.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: CRC's as MAC's
Date: 12 Sep 2000 06:06:23 GMT
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> All of the MAC algorithms I've been able to find, HMAC-SHA1,
> HMAC-MD5, HMAC-RIPEMD, UMAC, and hash127 all seem to be optimized for
> 32-bit processors
Don't confuse the hash127 function with the current hash127 software.
The software takes advantage of floating-point arithmetic to compute the
function at extremely high speed on modern processors; but there are
many other ways to compute the same function.
The output of the function is simply
(r^(l+1) + m[0]r^l + m[1]r^(l-1) + ... + m[l-1]r + k) mod (2^127 - 1)
where m[0],m[1],...,m[l-1] are signed 32-bit integers and r,k are
128-bit secrets. Even on a dinky little processor you can split m into
bits and do a 127-bit addition of a precomputed 2^i r^j mod (2^127 - 1)
for each bit equalling 1. The total work is, on average, four 127-bit
additions per byte of m.
---Dan
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Scottu19 Broken
Date: Tue, 12 Sep 2000 03:38:36 -0400
On 10 Sep 2000 14:05:44 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>source of this thread is from the lap dog Tommy. Who thinks the crypto
>goods walk on water even when its not frozen.
Not much of a accomplishment. Well, maybe it seems so to you.
>shots at it when they can. And sorry MR Wagner who seems to stupid
>to follow compilable source code.
Just because it compiles doesn't make it clear. I offer the following example.
#include "stdio.h"
#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))
long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };
main(m1,s) char *s; {
int a,b,c,d,o[k],n=(int)s;
if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
else switch(m1-=h){
case f:
a=(b=(c=(d=g)<<g)<<g)<<g;
return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
case h:
for(a=f;a<j;++a)if(tab1[a]&&!(tab1[a]%((long)l(n))))return(a);
case g:
if(n<h)return(g);
if(n<j){n-=g;c='D';o[f]=h;o[g]=f;}
else{c='\r'-'\b';n-=j-g;o[f]=o[g]=g;}
if((b=n)>=e)for(b=g<<g;b<n;++b)o[b]=o[b-h]+o[b-g]+c;
return(o[b-g]%n+k-h);
default:
if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
for(*s=a=f;a<e;) *s=(*s<<e)|main(h+a++,(char *)m1);
}
}
<snip endless repeated ad hominen attacks>
--
Best Wishes,
Johnny Bravo
BAAWA Knight, EAC - Temporal Adjustments Division
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all its contents." - HP Lovecraft
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: RSA public exponent
Date: 12 Sep 2000 08:34:54 GMT
According to Ed Pugh <[EMAIL PROTECTED]>:
> Again, if I understand what Bill wrote, then this means that any
> RSA key with a "small" public exponent can be broken (i.e. the
> secret exponent can be found?)
There is a misunderstanding: the weak version is with a small *private*
exponent.
Usually, the public exponent is very small (so that encrypting and
signature verification are fast) and specified in the standard; so, when
you choose your key, you calculate the private exponent and you end up
with something about as large as the modulus.
However, it is tempting to choose a small private exponent (for
instance, you want to generate RSA signatures in a smart card, so you
are really short of computing power). Of course, this implies that the
public exponent will be large (as large as the modulus) and different
for each user (so it becomes part of the public key, with the modulus).
But with a private exponent reduced to 1/4 length, the signature
generation is four times faster; the verification is considerably
slowed, but this one is usually performed by a more powerful device.
This is tempting, but this is bad. It has been shown that using a small
private exponent implies attacks (shortly speaking, the fact that the
exponent is small leaks information: you give as part of the public key
the public exponent, which is a large number, that has a short private
counterpart; the attacker could not have guessed it alone).
Therefore, the public exponent can be real small (say, e = 3) with
no real security implication, but the private exponent should not be
"specially" chosen; its value should be derived from a randomly selected
modulus.
As a side note: if an attacker wants to retrieve the private exponent
alone (with the public key only, and without using the legitimate user
as a decryption Oracle), his efforts are equivalent to factoring.
Explanation: given the private and the public exponent, it is easy to
retrieve the factorisation of the modulus (especially if the public
exponent is small). If you want to attack a modulus N, you can choose
whatever public exponent you want, for instance e = 3. It does not
matter whether this is the public exponent of a given user or not; this
e has a private counterpart d, and if you can calculate this d, you can
factorise N and then calculate the private exponent for just any public
exponent.
But factoring the modulus is not the only way to break RSA; knowing the
private exponent is equivalent to factoring, but the power of signing en
deciphering messages is not equivalent to the knowledge of the private
exponent (although knowing this exponent is the most straightforward
way).
--Thomas Pornin
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 11:10:36 +0200
I guess that, while employing different fields/rings may
buy you some complexity, always using linear functions is
much poorer than using non-linear functions. Now you
yourself will have the difficulty of inverting non-linear
functions. However, this is no problem if the functions
are used e.g. in a Feister cipher so that no inversion
is needed.
I might be wrong and experts would like to correct me.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Steganography and secret sorting
Date: Tue, 12 Sep 2000 11:10:25 +0200
Matthew Skala wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >Transposition is one major technique of cryptography. So,
> >if you rearrange your items in some way unknown to the
> >opponent, you gain some security. A simple method is to use
> >a secret seed and a PRNG to do the permutation. The recipient
> >can inverse the permutation and get back the original stuff.
>
> Usually in transposition schemes, the permutation is determined by the key
> and is used to permute the message. My proposal is for steganography
> rather than encryption: the permutation is determined by the message
> instead of the key, and applied to harmless "cover" traffic.
I must admit that I have only superficially read your method
and haven't understood it. How do you sort the stuff back to
the original? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Tue, 12 Sep 2000 11:10:13 +0200
Hideo Shimizu wrote:
>
> Mok-Kong Shen wrote:
> > I suggest that you convey, if possible, to your national
> > standardization body (which submits the Japanese algorithms
> > to ISO) the general users' wish that the algorithms be free
> > of patent issues. Thanks.
> I agree.
>
> Unfortunately, I am not member of national body comittie, so I can't
> tell it to them.
Not very difficult in my humble view. Just write a letter
to the working group (WG) or technical committee (TC) of
your national standardization body that is responsible for
the matter. They accept in general comments from the public
about their work. Another way is to find out whether your
organization has somebody participating in any standardization
work. By chance, he might even be able to arrange for a
personal contact with persons of the WG concerned.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Tue, 12 Sep 2000 11:10:19 +0200
David Hopwood wrote:
>
> In any case, there are patent applications relating to Camellia:
>
> Mitsubishi Electric Corporation (Mitsubishi Electric) and Nippon
> Telegraph and Telephone Corporation (NTT) have filed patent
> applications on the techniques used in Camellia. For more
> information, please contact at [EMAIL PROTECTED] and/or
> [EMAIL PROTECTED]
It is very important to have the patent freed for public
use, if the cipher is ever to be used 'universally'. Further,
whether Camillia itself involves other patents has to be
clarified too.
BTW, does anybody know about further developments of the
issue of Hitachi's patent claims concerning AES? Could
it be that that is delaying the release of AES?
M. K. Shen
------------------------------
** 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
******************************
