Cryptography-Digest Digest #833, Volume #12 Wed, 4 Oct 00 01:13:00 EDT
Contents:
Re: Advanced Encryption Standard - winner is Rijndael ("Rick Braddam")
Counterpane Funny Stuff (Tom St Denis)
Problem with Twofish Round Function (Tom St Denis)
Re: Requirements of AES (Tom St Denis)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Jacques Therrien)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Rich Wales)
Re: Choice of public exponent in RSA signatures ("John A. Malley")
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (jungle)
NTRU inversion (Benjamin Goldberg)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Jeremy Bishop)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 3 Oct 2000 20:21:31 -0500
Reply-To: "Rick Braddam" <[EMAIL PROTECTED]>
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> jungle wrote:
> >
> > read again my press note, it is there ...
> >
> > additionally it is in Published in the January 2, 1997 issue of the
Federal
> > Register: DEPARTMENT OF COMMERCE National Institute of Standards and
Technology
> > [Docket No. 960924272-6272-01] RIN 0693-ZA13 document ...
> >
> > "It is intended that the AES ... algorithm capable of protecting
sensitive
> > government information ..."
>
> I see no evidence that the U.S. government ever reached the conclusion
> that Rijndael is not suitable for protecting classified information.
>
> Again, can you produce any evidence for this claim?
>
> DS
>From the same press release, here's a hint:
When approved, the AES will be a public algorithm designed to protect
sensitive government information well into the 21st century. It will
replace the aging Data Encryption Standard, which NIST adopted in 1977 as
a Federal Information Processing Standard used by federal agencies to
protect sensitive, unclassified information.
>From the AES questions and answers page:
1. What is the Advanced Encryption Standard (AES)?
The Advanced Encryption Standard (AES) will be a new Federal Information
Processing Standard (FIPS) Publication that will specify a cryptographic
algorithm for use by U.S. Government organizations to protect sensitive
(unclassified) information. NIST also anticipates that the AES will be
widely used on a voluntary basis by organizations, institutions, and
individuals outside of the U.S. Government - and outside of the United
States - in some cases.
19. Who will be required to implement and use the AES?
When the AES is published as a FIPS, the algorithm will officially be
identified as an approved encryption algorithm that can be used by U.S.
Government organizations to protect sensitive (unclassified) information.
As is currently the case, those Government organizations will be able to
use other FIPS-approved algorithms in addition to, or in lieu of, the AES.
Commercial and other non-U.S. Government organizations are invited - but
not required - to adopt and implement the AES and NIST's other
cryptographic standards.
The reference to "protect sensitive (unclassified) information" is
repeated in several other documents available at the NIST web site or
through its links.
Good enough?
(Uncle won't specify "unclassified" unless that's exactly what he means)
Rick
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Counterpane Funny Stuff
Date: Wed, 04 Oct 2000 02:16:37 GMT
at http://www.counterpane.com/pr-funding.html
They have the quote "Counterpane is the right company at the right
time. They offer the first scalable security business model that
broadly leverages unparalleled security expertise to all businesses. I
can't think of a better team to solve the problem of securing e-
business."
What the hec k is a "scalable security business model that broadly
leverages unparalelled security expertise...." sounds like the output
of a buzzword generator...
Hehhee
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Problem with Twofish Round Function
Date: Wed, 04 Oct 2000 02:22:51 GMT
I just realized that the output of the round function is merely...
T1 = 2a + b
T2 = a + b
Where the difference is in the 'a' term. What if I sent a differential
into the that function without a difference in 'a' (i.e the first g
function). Obviously in the next round it would affect the other side
but you get a round for quasi free.
Also that doesn't look like the best way to distribute the entropy
in 'a' and 'b' (pretend a is the output of the first g function, and b
the output of the second).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Wed, 04 Oct 2000 02:24:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> Tom St Denis [EMAIL PROTECTED] writes, in part:
>
> >In article <[EMAIL PROTECTED]>,
> > Jim Gillogly <[EMAIL PROTECTED]> wrote:
> >> Tom St Denis wrote:
> >> > Perhaps I should rewrite the question in a form you can
understand.
> >>
> >> Your snide attitude isn't helping. You really aren't all that
> >> far ahead of the rest of us in the class.
> >
> >Sorry but I had to say it that way.
> >
> >> > Why wasn't Serpent or Twofish picked?
> >>
> >> I think you need to get the NIST report. It's really quite
thorough.
> >> Here are some of the points from section 6, Summary Assessments of
the
> >> Finalists. They noted that although IP was reviewed, they felt
that
> >> no algorithm had an advantage over the others in this regard, so
this
> >> didn't enter into the evaluation as a distinguishing
characteristic.
> >
> >I read their papers. They said why Rijndael was picked, not why
> >Serpent or Twofish "were not" picked.
> >
> >> First, they observed that there are no known security attacks on
any
> >> of the finalists, and all five appear to have adequate security for
> >> the AES. They mention criticism of Rijndael for its mathematical
> >> structure and Twofish for its key separation property, but say that
> >> neither of these observations leads to an attack. This, in their
> >> view, indicates that the algorithms are all secure enough, though
> >> they say that MARS, Serpent and Twofish appear to have higher
> >> security margins.
> >
> >Hmm security = most important goal.
> >
> >> Second, RC6 and Rijndael are on top for en/decryption speed in s/w.
> >> MARS is average, Twofish is mixed across platforms but generally
> >> average, and Serpent is slowest. Rijndael has the fastest key
> >> setup, MARS, RC6 and Serpent are average, and Twofish is slowest.
> >
> >That is bs...<snipped>
> >> Third, in restricted RAM/ROM apps Rijndael is the clear favorite,
> >> Serpent is good, Twofish is "suitable", RC6 has a high RAM reqt
> >> for decryption, and MARS is not well suited.
> >
> >Again which version of Twofish did you compare?
> >
> >> Fourth, Serpent and Rijndael have the best hardware throughput,
> >> RC6 and Twofish have average throughput, and MARS is below average.
> >
> >Again ...
> >
> >> Fifth, Rijndael and Serpent use operations that are easier to
> >> defend against power and timing attacks. Twofish's addition op
> >> is harder to defend against those attacks, and RC6 and MARS are
> >> difficult to defend because of mults, variable rots, and addition.
> >
> >That's bs to. Twofish can be done with xors, ors and look ups. Same
> >with Rijndael.
>
> Jim is summarizing the report, a report you should re-read.
Read the twofish teams "last notice for AES" before they picked. The
Twofish team said that unfair comparaisons were made because people
used the wrong implementations of Twofish.
Did they lie?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Wed, 04 Oct 2000 02:44:04 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> > Mok-Kong Shen wrote:
> > > Bryan Olson wrote:
> > > >
> > > > Mok-Kong Shen wrote:
> > > > > Each session uses a (different) secret seed for the PRNG.
> > > > > (I use effectively more key material, as said in a previous
> > > > > follow-up.)
> > > >
> > > > Does your method requires a separate secure channel for
> > > > transporting the per-message keys? How do the sender
> > > > and receiver know which key to use?
> > >
> > > They get the material with the same channel at the
> > > same time. Send some longer material, one part for the
> > > encryption key, the other part for the seed. That
> > > seed is for the whole session, which may consist of
> > > a number of messages.
> >
> > So the scheme is only appropriate when a new key will be transported
> > for each session? Note that a conventional block cipher and
> > chaining mode can support arbitrarily many sessions and messages
> > with a single key.
>
> Then you send the secret seed with that 'single' key.
> I don't understand what is the problem that you see here?
O.K. that's clear. Now the attacker just repeats the same
encrypted seed so the chosen plaintext attack can use the
same permutation in multiple messages, just as before.
> > > > [...]
> > > > > > Hard to sell exposing the key as a good thing.
> > > > >
> > > > > Sorry, the above sentence is difficult for me (foreigner)
> > > > > to understand.
> > > >
> > > > Hard to take that seriously.
> > >
> > > Does that constitute a concrete answer that I requested
> > > (see the part you snipped)?? (A yes/no is anyway needed.
> > > And some explanations.)
> >
> > What is needed is a serious attempt to understand the material.
>
> But you don't answer my question whether introduction
> of permustaion reduces or enhances the strength, i.e.
> produces a negative or positive effect. If your attack
> is good then you should be able to firmly answer that it
> reduces the strength.
No need to take my word for anything. Check it out.
> But you seem so far to avoid that question.
Nonsense. I avoid spoon-feeding the answer.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jacques Therrien <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Wed, 04 Oct 2000 03:02:53 GMT
In article <tTrC5.13342$[EMAIL PROTECTED]>, Tom McCune
<[EMAIL PROTECTED]> wrote:
> In article <8rd7ef$5e1$[EMAIL PROTECTED]>, Simon Johnson
> <[EMAIL PROTECTED]> wrote:
> <snip>
> >Having said this though, I think i agree with you though, using keys
> >bigger than 1024-bit is equal in stupidity to iterating DES 128 times.
> >It reduces performance so much, its not worth using.
>
> On a modern computer, it takes no additionally noticeable time to encrypt
> or decrypt to a 4096 bit RSA key, than it does to a 1024 bit RSA key. So
> although it isn't really necessary to use the maximum potential of PGP by
> using a key larger than 3000 bits, there isn't really harm in doing so
> (except for backwards compatibility). I'm surprised that this
> performance myth continues.
Tom,
There are however incompatibilities with 4096-bit RSA keys. For instance
in PGP 6.x., those RSA keys cannot be used for encryption.
I am not sure what would happen if one tried to verify a message signed
with such an RSA key -- I would assume that would not work either.
Someone with a 4096-bit RSA key, send a signed message to this newsgroup.
We will find out.
Those keys can be imported on the keyring, however if one cannot do
anything with them, that is pretty useless.
--
Cheers,
Jacques
[ Key ID: 0xE15C6C21 <http://www.keyserver.net> ]
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: 4 Oct 2000 03:21:18 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Jacques Therrien wrote:
> Someone with a 4096-bit RSA key, send a signed message
> to this newsgroup. We will find out.
OK, try this message. I've signed it with a 4096-bit RSA key which
I created using a modified PGP 2.6.3ia. You can find the key at:
http://www.webcom.com/richw/pgp/rich4096.asc
PLEASE NOTE: This is a strictly experimental key. Please don't use
it to encrypt any really important stuff.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3ia
Charset: noconv
Comment: Rich Wales's public keys at http://www.webcom.com/richw/pgp/
iQIVAwUBOdqh4D9CT0OqggAFAQEwNQ/+PVSg+DIi6tMmI/yX248Q9phNV3m7iF/y
Pp3rIpZBe3zecD3jW45TdnL9t4OPKaL4PdrbIOz51Kskmznupa+lkqlsQIDIRhZ+
wDCN0lLrfroG8Fk15mq/NXZEYIIggS0B9240WEJaCpZmNK5t8Y69k6hIOx/XfQ8m
QGmgrKIdZOC5ftq1+3h0cHrlGMUrCXRhYVDRTn+3wHOXqKQmFCrrPLRwCrjVNDUD
njzXoG/bPyFqRVUxsHcw6Rwmm2fLQ2BsAwtR/1+xxpPnUw5oQ4c+8qFrjgh6PrMm
RoFtY51UTs8Q3iZUb0Nj9W9qSoXVWCKP7+jbeWzJQcqZaO7rNi7biD0oUFzBpn5c
zp6HonD/NA5xODDfgpOcYgPrBcESvwE6KcbD3wTGbfbgBXGJ2dtAPd/bxX7BqKZD
S4R8Id8+Wtydp5tu4u1tGYcGsEffe2dvhSeRU46GNNnQoFw+8i7ZfWFupEE8G/AM
zOl1E9fvMUaGNKJw9HstjrRgYSh3F9OwSygLEOsJ4pXSiv0Cr81d30J+fHoLMV4C
zlPkhTooGfBQsJMrp7RZvDiLHbq5UURTER4tUQIZuBhJbnwfnkno9NoOi1agd34e
0jlvtEhikwVlNmcXpdYyyFSQhhs33yG2b0O5WNjalJeCnkRLeLVLppz2JL5DqZc6
GcqOiZWNFhw=
=J38a
=====END PGP SIGNATURE=====
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Tue, 03 Oct 2000 20:38:42 -0700
"John A. Malley" wrote:
>
>
> Is there a "must-read" paper or a set of "must-read" papers on OAEP you
> recommend?
>
Thanks for the pointers to info on OAEP everybody. (BTW I contacted
Prof. Bellare and he fixed the availability of his paper on his web
site.)
I got only a fifteen minute window at lunch at work today to read over
Mihir Bellare and Phillip Rogaway 's "Optimal asymmetric encryption -
How to encrypt with RSA" - but enough sunk in that understand Prof.
Wagner's argument that
with OAEP the attacks previously mentioned in the thread do not apply
and thus don't provide a reason to prefer an e > 3. (There's still a
good deal more to digest.)
OAEP is more than simple padding (as addressed in those previously
mentioned attacks.) It's an interesting encoding of the plaintext prior
to encryption - almost (but not exactly) encrypting the message twice.
A one-way function takes a random seed and makes a random mask (PRN)
that's exored with the message. And then the masked message is fed into
a one way function to make another PRN that's exored with the original
seed, and the masked seed is appended to the masked message. The
concatenated "encrypted" message and "encrypted" key is then RSA
encrypted.
As long as the assumptions behind the security of OAEP hold I would
agree that using OAEP negates the reasons touted for e > 3. If I didn't
use OAEP with RSA encryption I'd use e = 65537.
John A. Malley
[EMAIL PROTECTED]
P.S. This evening my thoughts turned to the assumption that the hash
function behaves randomly (as described in the RSA Bulletin.) I thought
it might be fun to explore some toy problems where the one-way function
is not cryptographically secure (say it's a predictable PRNG) and see
how easy it is to crack - and if the choice of e affects this.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 21:02:40 -0700
Rick Braddam wrote:
> > I see no evidence that the U.S. government ever reached the conclusion
> > that Rijndael is not suitable for protecting classified information.
> >
> > Again, can you produce any evidence for this claim?
> >
> > DS
>
> From the same press release, here's a hint:
>
> When approved, the AES will be a public algorithm designed to protect
> sensitive government information well into the 21st century. It will
> replace the aging Data Encryption Standard, which NIST adopted in 1977 as
> a Federal Information Processing Standard used by federal agencies to
> protect sensitive, unclassified information.
This doesn't say that the U.S. has decided that Rijndael is unsuitable
for protecting classified information. In fact, at the time this was
written, it wasn't even known that the AES was Rijndael.
> From the AES questions and answers page:
>
> 1. What is the Advanced Encryption Standard (AES)?
>
> The Advanced Encryption Standard (AES) will be a new Federal Information
> Processing Standard (FIPS) Publication that will specify a cryptographic
> algorithm for use by U.S. Government organizations to protect sensitive
> (unclassified) information. NIST also anticipates that the AES will be
> widely used on a voluntary basis by organizations, institutions, and
> individuals outside of the U.S. Government - and outside of the United
> States - in some cases.
This doesn't say or imply that the U.S. has decided that Rijndael is
unsuitable for protecting classified information.
> 19. Who will be required to implement and use the AES?
>
> When the AES is published as a FIPS, the algorithm will officially be
> identified as an approved encryption algorithm that can be used by U.S.
> Government organizations to protect sensitive (unclassified) information.
> As is currently the case, those Government organizations will be able to
> use other FIPS-approved algorithms in addition to, or in lieu of, the AES.
This doesn't say or imply that the U.S. has decided that Rijndael is
unsuitable for protecting classified information.
> Commercial and other non-U.S. Government organizations are invited - but
> not required - to adopt and implement the AES and NIST's other
> cryptographic standards.
>
> The reference to "protect sensitive (unclassified) information" is
> repeated in several other documents available at the NIST web site or
> through its links.
>
> Good enough?
> (Uncle won't specify "unclassified" unless that's exactly what he means)
No, not good enough. I'm sure whatever the government uses to protect
it's most classified data is also suitable for protecting unclassified
but sensitive data.
For the third time, I ask you if you have any evidence to support your
claim that the U.S. government does not consider Rijndael suitable for
protecting classified data. I'm become more and more confident that you
don't.
DS
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Wed, 04 Oct 2000 00:14:29 -0400
message sig is BAD under v651 ...
do you need any future tests ?
Rich Wales wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Jacques Therrien wrote:
>
> > Someone with a 4096-bit RSA key, send a signed message
> > to this newsgroup. We will find out.
>
> OK, try this message. I've signed it with a 4096-bit RSA key which
> I created using a modified PGP 2.6.3ia. You can find the key at:
>
> http://www.webcom.com/richw/pgp/rich4096.asc
>
> PLEASE NOTE: This is a strictly experimental key. Please don't use
> it to encrypt any really important stuff.
>
> Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
> PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
> RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: NTRU inversion
Date: Wed, 04 Oct 2000 04:16:48 GMT
I've written some C code for doing NTRU inverses, by translating the
psuedocode in NTRUTech001.ps.gz (from the ntru web site), but there are
some parts I don't understand. Lines that I couldn't convert to C code
are marked with @@, with the particulars surrounded by @? and ?@.
Security parameters (particularly N) are in the .h file, part of which
I'll include here. Would someone please help?
#define N 191
typedef struct NTRU_trp_s { // truncated-ring-poly
int value[N];
} NTRU_trp;
static int NTRU_inversepoly( NTRU_trp * bb, NTRU_trp a, int P, int r ) {
@@ NTRU_trp b = @? X**N-1 ?@;
NTRU_trp d = a, u = {{1,0}} , v_1 = {{0}}, v_3 = b, c;
int P_r, Q, i, tmp;
while( NTRU_degree( v_3 ) >= 0 ) {
NTRU_trp t_1, t_3;
@@ @? write d = v_3 * q + t_3 (mod P)
@@ with deg(t_3) < deg(v_3) ?@
// This is long division of polynomials in (Z/PZ)[X].
for( i = N; i--; )
t_1.value[i] =
@@ u.value[i] - @? q ?@ * v_1.value[i];
u = v_1; d = v_3; v_1 = t_1; v_3 = t_3;
}
if( NTRU_degree(d) > 0 )
return 0;
for( i = 0, tmp = mulinv( d.value[0], P ); i < N; ++i )
c.value[i] = tmp * u.value[i] % P;
for( P_r = P; r > 1; --r ) P_r *= P;
Q = P;
while( Q < P_r ) {
NTRU_trp cprime;
cprime = NTRU_starmultiply( c, c, P_r );
cprime = NTRU_starmultiply( a, cprime, P_r );
for( i = 0; i < N; ++i )
c.value[i] = (2*c.value[i] -
cprime.value[i]) % P_r;
Q = Q*Q;
}
*bb = c;
return 1;
}
notes:
1) I have C code for *everything* else in NTRUTech001.ps.gz; the only
thing not done completely is the above function.
2) The q in the 4th problem line seems to come out of nowhere... I think
it's a typo.
3) After the assignment of b to v_3, b is no longer used. Is this a
mistake? Why not assign to v_3 in the first place, and save space?
4) v_2 and t_2 don't appear anywhere. What's up with that? Did they
exist in a prior version?
notes not relevent to this, but to other parts of the psuedocode:
5) f and g (in key generation) are supposed to be generated in a manner
similar to how phi (in encryption) is generated, according to the HTML
description of the system. The psuedocode gives a different way of
generating them. Why?
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Jeremy Bishop <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Tue, 03 Oct 2000 21:32:51 -0700
Rich Wales wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Jacques Therrien wrote:
>
> > Someone with a 4096-bit RSA key, send a signed message
> > to this newsgroup. We will find out.
>
> OK, try this message. I've signed it with a 4096-bit RSA key which
> I created using a modified PGP 2.6.3ia. You can find the key at:
GnuPG 1.0.3 reports the signature as good. My PGP 6.5.8 won't allow
encrypting to it and will not check the signature. I'm too lazy to
reboot and try my ckt build. Someone else?
--
In 1984, in an off-air radio voice check, President Reagan
joked, "My fellow Americans, I'm pleased to tell you today that
I've signed legislation that will outlaw Russia forever. We
begin bombing in five minutes." The Kremlin was not amused.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Wed, 04 Oct 2000 07:08:05 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> > > Mok-Kong Shen wrote:
> > > > Bryan Olson wrote:
> > > > >
> > > > > Mok-Kong Shen wrote:
> > > > > > Each session uses a (different) secret seed for the PRNG.
> > > > > > (I use effectively more key material, as said in a previous
> > > > > > follow-up.)
> > > > >
> > > > > Does your method requires a separate secure channel for
> > > > > transporting the per-message keys? How do the sender
> > > > > and receiver know which key to use?
> > > >
> > > > They get the material with the same channel at the
> > > > same time. Send some longer material, one part for the
> > > > encryption key, the other part for the seed. That
> > > > seed is for the whole session, which may consist of
> > > > a number of messages.
> > >
> > > So the scheme is only appropriate when a new key will be transported
> > > for each session? Note that a conventional block cipher and
> > > chaining mode can support arbitrarily many sessions and messages
> > > with a single key.
> >
> > Then you send the secret seed with that 'single' key.
> > I don't understand what is the problem that you see here?
>
> O.K. that's clear. Now the attacker just repeats the same
> encrypted seed so the chosen plaintext attack can use the
> same permutation in multiple messages, just as before.
The seed of PRNG is of course not to be reset, as I
mentioned previously several times. Basically it is
a combination of stream and block features. In a
stream cipher doesn't reset and use the same stream
a second time.
>
> > > > > [...]
> > > > > > > Hard to sell exposing the key as a good thing.
> > > > > >
> > > > > > Sorry, the above sentence is difficult for me (foreigner)
> > > > > > to understand.
> > > > >
> > > > > Hard to take that seriously.
> > > >
> > > > Does that constitute a concrete answer that I requested
> > > > (see the part you snipped)?? (A yes/no is anyway needed.
> > > > And some explanations.)
> > >
> > > What is needed is a serious attempt to understand the material.
> >
> > But you don't answer my question whether introduction
> > of permustaion reduces or enhances the strength, i.e.
> > produces a negative or positive effect. If your attack
> > is good then you should be able to firmly answer that it
> > reduces the strength.
>
> No need to take my word for anything. Check it out.
>
> > But you seem so far to avoid that question.
>
> Nonsense. I avoid spoon-feeding the answer.
You can't either answer yes or no. That is the point.
I challenge you to do that!
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
******************************
