Cryptography-Digest Digest #803, Volume #12 Sat, 30 Sep 00 14:13:00 EDT
Contents:
Re: RSA and Chinese Reminder Theorem (Tom St Denis)
Re: AES annoucement due Monday 2nd October (Tom St Denis)
Re: Question on biases in random-numbers & decompression (Herman Rubin)
The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins .... check out
the developers .... they just want to violate people's freedom of speech rights ...
(Markku J. Saarelainen)
Re: AES annoucement due Monday 2nd October ("Brian Gladman")
Re: CPU's aimed at cryptography (Markku J. Saarelainen)
Re: Microwaves, Electromagnetic Communication and Brain / Mind Control - the first I
thought also becoming crazy, but realized that my logic and reasoning was 100 %
accurate and based on clear facts and observations .... here are some other specifics
... (William A. Nelson)
Re: RSA and Chinese Reminder Theorem (Paul Schlyter)
Re: Deadline for AES... (John Savard)
Re: NIST Statistical Test Suite (Matthias Bruestle)
Choice of public exponent in RSA signatures (Francois Grieu)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA and Chinese Reminder Theorem
Date: Sat, 30 Sep 2000 13:08:41 GMT
In article <8r4jrv$m0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> In article <[EMAIL PROTECTED]>,
> Roger Schlafly <[EMAIL PROTECTED]> wrote:
>
> > Bob Silverman wrote:
> >> I see that I wrote 'e' instead of 'd'. ...careless
> >
> > May I suggest that if you don't have the knowledge to answer the
> > question that you not try to answer???
> >
> > Secondly, I have never heard of using 'e' for a decryption exponent.
> > If you mean the decryption exponent 'd', please refer to it by
> > that name. We need to use common terminology if we are to
> > communicate effectively.
> >
> > See Knuth, Vol 2.
> >
> > If you wish to discuss this subject stick to standard terminology.
> >
> > May I suggest that you go read the literature on this subject?
> > Especially in terms of what can be done and what has been done?
> >
> > You will need to refer to Knuth Vol 2.
> >
> > If *YOU* want to discuss mathematics and computer science,
> > I suggest *YOU* learn the terminology.
> >
> > "You can satirize a man's postings, but you can't make him think"
>
> There is no intrinsic "encryption" or "decryption" exponent in
> RSA. However, there is a public and a private exponent, where the
> public exponent usually is much smaller than the private exponent.
> But either one of them can be used for encryption, and then the
> other for decryption -- your choice depends on your application.
The use of encryption/decryption thus becomes very ambiguous (sp?) thus
we can call them "transform" and "inverse transform" then, which still
has the same problem.
I would refer generally that 'e'='encryption' and 'd'='decryption'
which is most likely why Rivest chose them...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES annoucement due Monday 2nd October
Date: Sat, 30 Sep 2000 13:12:06 GMT
In article <N2kB5.21207$Cl1.493318@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > John Savard wrote:
> > >
> > > I notice what they said now. I'm unaware that they ever previously
> > > hinted that they might choose more than one algorithm, despite
many
> > > suggestions that they do so.
> >
> > So let's hope that there will be multiple algorithms
> > to enable user choice or multiple encryption as sort
> > of 'compensation' for doubts arising from deficiency
> > in documentation completeness (in the current status)
> > and the not too long period of analysis attempts.
>
> Although I have supported more than one winner, I do think this has
its own
> dangers that need to be controlled if this approach were to be adopted
> (these are covered in AES3 papers and public commernts).
>
> In particular it is important in all applications where (a)
interoperability
> is required, and (b) one algorithm is sufficient, that this algorithm
should
> always be the same single algoithm.
>
> Provided that this constrainst is applied, having a second backup
algorithm
> is not a big problem and does, in my view, provide a number of
benefits. In
> fact quite a large number of information security professionsals at
AES3 did
> not object to this.
>
> The large voice of opposition came from equipment suppliers who
feared that
> if the standard contained (say) two algorithms, they would inevitably
face
> considerable pressure from users for both and would end having to put
two
> algorithms in their kit in place of just one. This is a genuine
concern but
> not, in my view, one that should undermine valid information security
> requirements.
>
> But I am expecting a single winner and I don't think that this is a
really
> huge problem provided that the right choice is made.
Well except for hardware, I doubt two ciphers would pose a serious
threat. In the smartcards alot of the groups talked about the .25 cent
smartcards with 512 bytes rom, etc... well in reality getting 8kb of
rom is not hard to get... with 2kb of rom (plus say 128 bytes sram) you
could implement two ciphers with room to spare...
In desktops it's easy to implement two ciphers.... :)
Perhaps NIST will get confused and pick FROG and LOKI97 :-) hehehehe
I seriously hope that Serpent and Twofish win, since they are by far
the coolest ciphers.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Crossposted-To: comp.compression
Subject: Re: Question on biases in random-numbers & decompression
Date: 30 Sep 2000 08:16:01 -0500
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: "D.A.Kopf" wrote:
>:> So the original poster was correct, the inverse of an arithmetic
>:> compresser would be effective. Just "decompress" the random bitstream
>:> into the needed bin size.
>: Could you give a reference to an efficient decompressor
>: that works for arbitrary target range? Thanks.
>He means an ordinary arithmetic decompressor, with a small number of
>symbols set up to occur with equal frequency.
This has been posted before.
A most bit efficient procedure to generate one of n equally
likely options in {0, 1, ..., n-1} is as follows; using
hardware features can improve the speed, but these are likely
to be machine dependent.
m = 1;
k = 0;
loop: while (m < n){
m = m<<1;
k = (k<<1) + RANBIT;
}
if(k >= n){
m = m - n;
k = k - n;
goto loop;
}
return k;
The procedure works because at all times until the exit
k is uniformly distributed in {0, ..., m-1}.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Subject: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins ....
check out the developers .... they just want to violate people's freedom of speech
rights ...
Date: Sat, 30 Sep 2000 14:49:27 GMT
--
Independent Consultant
XCHIQITSH
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES annoucement due Monday 2nd October
Date: Sat, 30 Sep 2000 15:59:05 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8r4or4$pto$[EMAIL PROTECTED]...
> In article <N2kB5.21207$Cl1.493318@stones>,
> "Brian Gladman" <[EMAIL PROTECTED]> wrote:
> > "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > >
> > >
> > > John Savard wrote:
> > > >
> > > > I notice what they said now. I'm unaware that they ever previously
> > > > hinted that they might choose more than one algorithm, despite
> many
> > > > suggestions that they do so.
> > >
> > > So let's hope that there will be multiple algorithms
> > > to enable user choice or multiple encryption as sort
> > > of 'compensation' for doubts arising from deficiency
> > > in documentation completeness (in the current status)
> > > and the not too long period of analysis attempts.
> >
> > Although I have supported more than one winner, I do think this has
> its own
> > dangers that need to be controlled if this approach were to be adopted
> > (these are covered in AES3 papers and public commernts).
> >
> > In particular it is important in all applications where (a)
> interoperability
> > is required, and (b) one algorithm is sufficient, that this algorithm
> should
> > always be the same single algoithm.
> >
> > Provided that this constrainst is applied, having a second backup
> algorithm
> > is not a big problem and does, in my view, provide a number of
> benefits. In
> > fact quite a large number of information security professionsals at
> AES3 did
> > not object to this.
> >
> > The large voice of opposition came from equipment suppliers who
> feared that
> > if the standard contained (say) two algorithms, they would inevitably
> face
> > considerable pressure from users for both and would end having to put
> two
> > algorithms in their kit in place of just one. This is a genuine
> concern but
> > not, in my view, one that should undermine valid information security
> > requirements.
> >
> > But I am expecting a single winner and I don't think that this is a
> really
> > huge problem provided that the right choice is made.
>
> Well except for hardware, I doubt two ciphers would pose a serious
> threat. In the smartcards alot of the groups talked about the .25 cent
> smartcards with 512 bytes rom, etc... well in reality getting 8kb of
> rom is not hard to get... with 2kb of rom (plus say 128 bytes sram) you
> could implement two ciphers with room to spare...
I think the problem here is that there is more than the cipher involved.
For example a hash or a MAC may be needed as well and the protocol between
the card application and its external component. Although it is going to
get easier I don't think that smartcard folk are going to be the first to
implement two ciphers.
> In desktops it's easy to implement two ciphers.... :)
Yes, this is where its generally easy and quite normal to have a choice.
> Perhaps NIST will get confused and pick FROG and LOKI97 :-) hehehehe
>
> I seriously hope that Serpent and Twofish win, since they are by far
> the coolest ciphers.
You don't have long to wait to find out :-)
Brian Gladman
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Subject: Re: CPU's aimed at cryptography
Date: Sat, 30 Sep 2000 14:56:23 GMT
I have always been fascinated with the manipulation of news sources.
Once I read about the chip-set by Intel to be used in Nokia's set-top
boxes for cryptography and encryption, but within few hours the same
article in the same source location was changed to take out the
manufacturer of the encryption chip-set. These are details that are
pulled out by either manufacturers or controlled media people.
--
Independent Consultant
XCHIQITSH
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: William A. Nelson <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,alt.politics.org.cia,soc.culture.usa
Subject: Re: Microwaves, Electromagnetic Communication and Brain / Mind Control - the
first I thought also becoming crazy, but realized that my logic and reasoning was 100
% accurate and based on clear facts and observations .... here are some other
specifics ...
Date: Sat, 30 Sep 2000 15:08:03 GMT
Some entries from my diaries and notebooks ...
http://homestead.virtualjerusalem.com/waeg/files/notes1.htm
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA and Chinese Reminder Theorem
Date: 30 Sep 2000 16:56:41 +0200
In article <8r4okn$pr0$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <8r4jrv$m0$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Paul Schlyter) wrote:
>> In article <[EMAIL PROTECTED]>,
>> Roger Schlafly <[EMAIL PROTECTED]> wrote:
>>
>> > Bob Silverman wrote:
>> >> I see that I wrote 'e' instead of 'd'. ...careless
>> >
>> > May I suggest that if you don't have the knowledge to answer the
>> > question that you not try to answer???
>> >
>> > Secondly, I have never heard of using 'e' for a decryption exponent.
>> > If you mean the decryption exponent 'd', please refer to it by
>> > that name. We need to use common terminology if we are to
>> > communicate effectively.
>> >
>> > See Knuth, Vol 2.
>> >
>> > If you wish to discuss this subject stick to standard terminology.
>> >
>> > May I suggest that you go read the literature on this subject?
>> > Especially in terms of what can be done and what has been done?
>> >
>> > You will need to refer to Knuth Vol 2.
>> >
>> > If *YOU* want to discuss mathematics and computer science,
>> > I suggest *YOU* learn the terminology.
>> >
>> > "You can satirize a man's postings, but you can't make him think"
>>
>> There is no intrinsic "encryption" or "decryption" exponent in
>> RSA. However, there is a public and a private exponent, where the
>> public exponent usually is much smaller than the private exponent.
>> But either one of them can be used for encryption, and then the
>> other for decryption -- your choice depends on your application.
>
>The use of encryption/decryption thus becomes very ambiguous (sp?) thus
>we can call them "transform" and "inverse transform" then, which still
>has the same problem.
The RSA exponents happen to have that property: you can use either one
of them first, and when you use the second one, the plaintext will be
restored.
>I would refer generally that 'e'='encryption' and 'd'='decryption'
>which is most likely why Rivest chose them...
If so, you won't know which key is 'e' and which is 'd' until you've
decided whether you want to encrypt with the public or the private
exponent. And that decision is application dependent.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Deadline for AES...
Date: Sat, 30 Sep 2000 15:33:16 GMT
On Fri, 29 Sep 2000 19:57:33 -0700, "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote, in part:
>Well, since NIST is making up the rules, I suppose they could do anything
>they feel like. In principle, they could go and announce that FROG is the
>winner after all...
FROG did have one good idea, which is worth "stealing", and tweaking
into whichever algorithm is chosen, but of course that won't happen.
In looking at the algorithms in detail, I divided some of them into
categories:
The conventional:
MARS, SAFER+, RC6, LOKI-97, E2
The nearly conventional:
DFC, CAST-256, Rijndael
The almost unconventional:
Serpent, Twofish, Magenta
although this is _very_ subjective. (Isn't DFC as conventional as RC6,
while MARS is a lot less so, for example.)
If I were NIST, I'd be strongly tempted to go with something such as a
block cipher that consisted of four rounds of RC6, alternating with
two rounds of DFC, and so on: 42424 would total to sixteen rounds. Or
even a combination of FROG and LOKI-97! Or MARS with keyed mixing
rounds - the new MARS key schedule even inspired me to a specific
proposal for that.
Among the individual algorithms, ignoring any question of which ones
are more secure, I prefer the more conventional - but I am also
emotionally inclined to favor the entrants who made their entries
non-proprietary from the outset.
Among the finalists, I've felt:
Serpent seems awkward to implement in software. The use of GF(2^8)
operations in Rijndael also seems to handicap a software
implementation unnecessarily in what is otherwise a design well suited
to that. I found Twofish to be difficult to understand.
I lacked any strong feelings about RC6, but it appears to be embroiled
in an IP issue concerning its variable shifts, despite the fact that
RC5 used this without legal problems for years. (I noted inspiration
from several *other* ciphers in my description of Quadibloc VIII: I
see I should almost also credit RC6 for the basic round structure: but
it uses two crossed left halves, while I use an overall direction in
an asymmetric round...)
I liked the mixed structure of MARS, but felt that the avalanche
properties of its cryptographic core were not strong enough - and the
unkeyed nature of the mixing rounds was, to put it bluntly, wasteful.
My preference would have been for a cleaned-up LOKI-97, or for SAFER+
with a fancier key schedule, among the candidate algorithms. But as
can be seen from my designs, I think that FROG, flawed though it was,
included an idea of vital importance. And even if Magenta had
problems, I think it had a design worthy of study as well (it amazes
me, however, that it met the AES speed criterion).
Thus, while I eagerly anticipate Monday's announcement, I admit to
being vaguely discontented. The candidate algorithms contain a
cornucopia of valuable ideas, but no algorithm embraces all of them.
Of the five finalists, I think that I prefer, or see as strong
contenders, Twofish, MARS, and RC6, but the margin is small. (Twofish
also loses points due to its use of Galois multiplication, but at
least it is done within a more complex design in which there may be a
reason for it...)
Given that everyone else seems to think of MARS as weak, and RC6 has
this apparent IP issue, I'm inclined to say the odds favor Twofish.
But I recognize my perceptions are highly subjective, and likely to be
flawed. Perhaps if I were more inclined to read C code, I'd visit
Brian Gladman's page and see that the algorithms I'm tending to
dismiss can be implemented efficiently...i.e., a simple table-driven
way to do Galois multiplication, tricks to do SERPENT quickly similar
to the ones used to get rid of Permutation P in DES, and so on.
What is true is that no one candidate seems to have generated
excitement, but then it isn't that kind of a contest. (It ran longer
than _Survivor_...)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: NIST Statistical Test Suite
Date: Sat, 30 Sep 2000 11:39:09 GMT
Mahlzeit
Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
> "Douglas A. Gwyn" wrote:
> > Mok-Kong Shen wrote:
> > > ... A technical problem
> > > may be however that the stuff is in UNIX tar files.
> >
> > Why is that a problem? WinZip is a readily available
> > program that can unpack tar files; and there are others.
> I was thinking that the software configuration of some
> people may not include a number of licensed packages for
> one reason or another.
There is also a free tar for MS Windows available. Cygwin is a
port of the GNU utilities and GCC to MS Windows.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Die Menschheit hat von der Hoehlenmalerei zur Schrift ettliche
tausend Jahre gebraucht. Jetzt geht sich den gleichen Weg zurueck
in einem einzigen Jahrzehnt mit Hilfe der GUI's.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Choice of public exponent in RSA signatures
Date: Sat, 30 Sep 2000 19:22:30 +0200
It is well known that it might be dangerous to use a
small public exponent e (like 3) in RSA encryption,
because if the same message is available naively
encrypted (i.e. without embedded user id and proper
formatting) using e different known public keys,
the message can be easily recovered.
However I see a tendancy to use e = 2^16+1 even in
signature applications, like signature of downloadable
code using ISO 9796-2 or the like. This, of course,
makes signature verification over 8 times slower than
with e = 3.
Anyone know a rational reason for such a choice ?
Francois Grieu
------------------------------
** 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
******************************
