Cryptography-Digest Digest #880, Volume #12 Mon, 9 Oct 00 15:13:00 EDT
Contents:
SDMI - Answers to Major Questions ([EMAIL PROTECTED])
Re: Choice of public exponent in RSA signatures (DJohn37050)
Re: Can anyone point me to info on this privacy code ? Big sample (John Myre)
What is "freeware"? (was: Re: Any products using Rijndael?) (Paul Schlyter)
Re: FTL Computation ([EMAIL PROTECTED])
Re: FTL Computation ([EMAIL PROTECTED])
Re: Error-correcting code ? ([EMAIL PROTECTED])
Re: WEP (Ichinin)
Re: Looking Closely at Rijndael, the new AES (John Savard)
Re: Rijndael test vectors (John Savard)
Re: A new paper claiming P=NP (Rajarshi Ray)
Re: Rijndael test vectors (John Savard)
Re: FTL Computation ("Paul Lutus")
Re: On block encryption processing with intermediate permutations (Bryan Olson)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: The talk of R. Moris (Jim Gillogly)
Re: securely returning password info to a server from a client ("William A. McKee")
MITM attack ("William A. McKee")
Re: Looking Closely at Rijndael, the new AES (John Myre)
Re: xor algorithm ("William A. McKee")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: SDMI - Answers to Major Questions
Date: Mon, 09 Oct 2000 17:03:35 GMT
Hi folks - having read a number of Internet articles and posts from
concerned and/or irate MP3 fans about the possible future of MP3s
in an SDMI-oriented world, I was lucky enough to get SDMI
executive director Leonardo Chiariglioni on the phone to ask him
some of these questions directly -- some of his answers are pretty
interesting. Check out the interview at
http://www.neato.com/default.asp?goto=Articles/neatonicks.asp
Topics we covered, among others:
- will SDMI-compatible players ALWAYS play unencoded MP3s
- will SDMI watermarking affect audio quality
- the possibility of re-encoding SDMI files as regular MP3s from an
analog signal
- the success of "Hack SDMI"
-- Nick Appleby
NEATO-nicks at NEATO.com
http://www.neato.com/default.asp?goto=Articles/neatonicks.asp
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Choice of public exponent in RSA signatures
Date: 09 Oct 2000 17:20:02 GMT
I think that in this case the signature includes the message.
Don Johnson
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Can anyone point me to info on this privacy code ? Big sample
Date: Mon, 09 Oct 2000 11:12:54 -0600
Jim Gillogly wrote:
<snip>
> Actually, that'd be a good way to do stego.
<snip>
Yeah, well, it *was* a good way...
JM
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: What is "freeware"? (was: Re: Any products using Rijndael?)
Date: 9 Oct 2000 18:37:11 +0200
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Besides the fact that I believe Blowfish is very
> hard to break (as described above), the two
> *fish ciphers are also free, while using IDEA
> legally is only possible in (a) freeware or
> (b) for a IMHO really expensive license.
What do youi consider "freeeware" ? Any software which can be
legally used for free? Well, that's what I though, until I
encountered someone in another NG who by "freeware" meant
"copyrighted freeware" -- according to that person, "public domain"
was a class of its own, distinct from "freeware". And most other
participants in the NG seemed to agree.
So I'd like to ask the participants in this NG: how do you
define "freeware"? And in particular: is "public domain" one
class of "freeware", or is it distinct from "freeware"?
--
================================================================
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
------------------------------
Date: Mon, 09 Oct 2000 13:18:44 -0700
From: [EMAIL PROTECTED]
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
ca314159 wrote:
>
> If the projection of a spot of light can virtually move FTL
> then so too can the projected images of a slide rule's slides.
> The computation 'in effect', takes place FTL.
>
But the time between when you move the slide and you see
the projection is still the round trip light travel time
to the thing you're projecting the slide onto.
The real limitation is how fast you can transmit information.
John Anderson
------------------------------
Date: Mon, 09 Oct 2000 13:35:02 -0700
From: [EMAIL PROTECTED]
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Paul Lutus wrote:
>
> ca314159 <[EMAIL PROTECTED]> wrote in message
> news:8rpohl$t7q$[EMAIL PROTECTED]...
>
> > If the projection of a spot of light can virtually move FTL
> > then so too can the projected images of a slide rule's slides.
> > The computation 'in effect', takes place FTL.
>
> Not "in effect," not at all. The projection of the light does not move at
> FTL, not virtually, not really, not at all.
It does move FTL. But you can't transmit information
FTL using that result. Say the beam hits some point
and then another one a distance x from the first at time
t later. x/t can be greater than c. But any information
received at the first point via the beam can't be
synthesized with information received at the second
point until you have time to send a signal between
the first and second points.
John Anderson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Error-correcting code ?
Date: Mon, 09 Oct 2000 17:41:50 GMT
Marc <[EMAIL PROTECTED]> wrote:
:>Does anyone know an algorithm, simple or well-documented (like, source
:>code) enough that an idiot like me can implement it, for
:>error-correcting short strings of digits ?
:>So that if someone writes down "123454321" and someone reads it back as
:>"123454327" or "lZ34S43Zl" that I can recover the original number.
: In your example, of 88 bits 12 are damaged (>13%, and not in bursts). This
: is heavy duty for an error correcting code. I know of no simple algorithm
: that can be explained in few lines, that is able to reliably correct this.
: The simple to understand algorithms are good for burst errors (serial channel
: communications) or single bit errors (storage). Is your example exaggerated
: or do you in fact face such a high rate of bit errors?
Yes, it's exaggerated.
Most likely a transpositions of e.g. "O","0", "1","l" would be handled first.
I would be happy to recover from 1, maybe 2 wrong digits or 1 missing
digit (probably the first or last).
(thanks guys for the suggestions; haven't had time to follow them all up yet)
--
Andrew Daviel
PGP id 0xC7624B49
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: WEP
Date: Mon, 09 Oct 2000 07:38:33 +0200
Hi.
Nono, i mean "RC4 PRNO" algorithm. I know what RC4 is.
Anyone know what "RC4 PRNO" is ?
madcow wrote:
> RC4 is a proprietory algorithm developed by RSA
> http://www.rsasecurity.com/ ), but you should be able to get the source
> code of a reverse engineered version of it called "arcfour" on the web.
> Some
> companies will claim that no encryption is required, since they are using
> spread-spectrum communications.
IMHO, The Frequence hopping methods are just there to reduce the overall
ethernet colission rate, even further so by running all hardware in PSP
mode. I know everything about the limited states of the sequence number
generators, i know how to exclude up to 16% of the possible values and
i know that the number of frequencies used are very limited, Frequency
hopping is a minor nuissance for an intruder - i'd love to go into
detail, but i have this paper *caugh* that say i cannot talk about
certain
things and i better check what it is before i talk about the subject :oP
Anyway, that's my point - Buy an additional security toolkit from us :o)
> Info on wireless networks:
> http://www.wlana.com/
> And on breaking RC4 40 in 8 days:
> http://www8.zdnet.com/pcmag/issues/1508/pcmg0074.htm
> and
> http://catless.ncl.ac.uk/Risks/17.65.html
Thanks.
Glenn
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Mon, 09 Oct 2000 17:46:09 GMT
On Mon, 09 Oct 2000 09:48:00 -0600, John Myre <[EMAIL PROTECTED]>
wrote, in part:
>Brian Gladman wrote:
>> Perhaps
>> worse, I think IBM has patented them and this might cause problems if they
>> were adopted.
>Yuck.
I think I know which patent is being discussed here. It's mentioned on
my web page - just look up "Red Thread Resistance" in the cryptography
index, or use the frames with the index running down the left side. I
first heard about it in the thread entitled "Double Encryption is
PATENTED" that turned up quite some time ago: upon reading the patent,
I found that no, it wasn't claimed that double encryption was covered,
but the patent seemed to cover an idea I had for improving programs
like PGP.
It relates somewhat to OAEP, but the particular patent, with Mihir
Bellare as the inventor, appears to go beyond what is included in
OAEP. It was claimed that Secure File System used the same idea before
IBM, but I couldn't find anything like that in the documentation.
The scheme proposed by IBM involved a double encryption in CBC mode,
with one pass going forwards over the message, and one pass backwards.
The key for the forwards pass is constant: the last block of the
message after that pass is then XORed with the first block of the
message, and the result is used as the key for a backwards pass that
stops short of the first block.
Then the first block is encrypted by itself (i.e. ECB mode) with a
key-exchange-key.
So, for decryption: decrypt the first block with the KEK. Use the
result to decrypt the rest of the message (for the backwards pass).
XOR the last block of that with the first block to continue decrypting
it. Now, decrypt the message for the forwards pass.
My idea used a hash function and RSA - the patent, I think, also
mentioned RSA, but its claims *may* not include an unkeyed hash
function, but I'm not expert enough to be anywhere near sure of that -
but it is essentially the same principle as used in the IBM patent.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael test vectors
Date: Mon, 09 Oct 2000 17:49:03 GMT
On Mon, 09 Oct 2000 10:03:42 -0600, John Myre <[EMAIL PROTECTED]>
wrote, in part:
>While I'd agree that the NIST spec should probably have
>explicit help for the poor implementer, I don't think
>the nature of the submission discouraged anyone whose
>cryptanalysis would be worth anything.
You may well be right: but here, I'm thinking of busy people with 14
other algorithms to look at, not just people without the requisite
mathematical background - or at least the means of reading up on the
subject.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Rajarshi Ray <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: Mon, 09 Oct 2000 17:50:48 GMT
"David C. Ullrich" wrote:
>
> In article <[EMAIL PROTECTED]>,
> Rajarshi Ray <[EMAIL PROTECTED]> wrote:
> > "David C. Ullrich" wrote:
> > >
> > > On Mon, 09 Oct 2000 04:47:22 GMT, Rajarshi Ray
> <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > [...]
> > > >Is it not possible to implement the presented algorithm and try it
> out
> > > >on examples to see the growth rate, just as a preliminary check?
> > >
> > > No. Suppose that a(n) is a sequence of integers and
> > > a(n) = 2^(2^(^n)) for all n less than 10^(10^10). Does a(n)
> > > have polynomial growth?
> >
> > Well, I suppose it could be polynomially growing after 10^(10^10). Do
> > you mean to say that empirical testing wouldn't reveal its polynomial
> > behavior for n->oo, which is what we really mean by polynomial growth?
>
> Yes. (And it's not just a theoretical thing: It happens all the
> time that an algorithm that takes time O(n^2) is actually much
> faster than one that takes time O(n).)
Yes, I've noticed that Big-Oh bounds are often not reliable estimates of
complexity in practice. But I didn't think this was because of the kind
of anomaly you mentioned, i.e. it behaves badly for practically large
values while behaving well in the limit. I thought the problem with
Big-Oh estimates in practice was due to unaccounted issues of
implementation details. Is that not the problem, in most cases anyway?
- Rajarshi
--
"The most incomprehensible thing about the universe is
that it is comprehensible."
- Albert Einstein
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael test vectors
Date: Mon, 09 Oct 2000 17:53:15 GMT
On Mon, 9 Oct 2000 11:50:04 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
part:
>John Savard <[EMAIL PROTECTED]> wrote:
>: If they let "people like _that_" program computers [...]
>;-)
>Degrees are still in use in some places:
>Java's "Graphics2D" class uses radians for it's rotate() method, and
>degrees for it's drawArc() method. Go figure ;-)
Oh, degrees are still very useful and appropriate for many purposes.
That a computer programmer didn't know what radians *were*, however,
surprised me, although had he been programming in COBOL or RPG, of
course, he would have had no _need_ to be burdened with such matters.
I suppose there are ways to take a programming course without having
to take a calculus course first...just choose the right type of
educational institution. :)
In fact, I doubt degrees will *ever* become obsolete. It's one thing
for an atlas to give distances in kilometers instead of miles. But the
day they start giving latitude and longitude in radians is the day
I'll figure the world has gone crazy!
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Mon, 09 Oct 2000 18:02:40 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > > If the projection of a spot of light can virtually move FTL
> > > then so too can the projected images of a slide rule's slides.
> > > The computation 'in effect', takes place FTL.
> >
> > Not "in effect," not at all. The projection of the light does not move
at
> > FTL, not virtually, not really, not at all.
>
> It does move FTL.
Now we have to imitate Bill Clinton and say exactly what we mean by "it."
I argued that it was the hypothetical path of the light, not the projection
of photons along that path, that changed superluminally. The light itself
never exceeds c as it travels along the new path. The changed angle of the
light's path, if extrapolated out into space, has moved superluminally, but
the actual light can only catch up with this change at c, no more.
Like water leaving a hose. You can rotate the hose spigot faster than the
water's velocity, but the water doesn't instantaneously change direction all
along its path.
The remainder of your argument makes sense, but it is indistinguishable from
an example that uses two light beams taking off in different directions. I
believe this is not what the OP had in mind, but as you point out, it also
does not violate normal rules of causality.
--
Paul Lutus
www.arachnoid.com
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Mon, 09 Oct 2000 18:04:31 GMT
Mok-Kong Shen wrote:
> David Hopwood wrote:
> > This argument is quite obviously wrong. Brian Olson is claiming
> > that the scheme can be broken with high probability (and given
> > reasonable parameter choices) when the permutation is random.
> > That does not imply that it can be broken if you choose a
> > specific permutation. In order to be secure, a scheme has to
> > be unbreakable in all cases except with negligable probability;
> > it's certainly not sufficient for it to be secure in one case.
>
> He never mentioned in his posts in this sense. He said
> he could somehow adapt to the permutation, which means
> getting that information from trials (chosen plaintext)
> and which seems indeed feasible if 'sufficient' (how
> large is another matter) materials can be obtained.
False. We went over this about two weeks ago.
Shen:
| | Now one of the permutation is the identity. If that
| | happens to take places, is the original cipher also
| | that easy to attack?
Olson:
| You specified a pseudo-random permutation. I wrote that a
| block with the properties that support the attack probably
| exists among about a thousand blocks. If the identity is
| one of the inter-round permutations, such a block will not
| exist.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Mon, 09 Oct 2000 20:34:32 +0200
Bryan Olson schrieb:
>
> Mok-Kong Shen wrote:
> > David Hopwood wrote:
>
> > > This argument is quite obviously wrong. Brian Olson is claiming
> > > that the scheme can be broken with high probability (and given
> > > reasonable parameter choices) when the permutation is random.
> > > That does not imply that it can be broken if you choose a
> > > specific permutation. In order to be secure, a scheme has to
> > > be unbreakable in all cases except with negligable probability;
> > > it's certainly not sufficient for it to be secure in one case.
> >
> > He never mentioned in his posts in this sense. He said
> > he could somehow adapt to the permutation, which means
> > getting that information from trials (chosen plaintext)
> > and which seems indeed feasible if 'sufficient' (how
> > large is another matter) materials can be obtained.
>
> False. We went over this about two weeks ago.
>
> Shen:
> | | Now one of the permutation is the identity. If that
> | | happens to take places, is the original cipher also
> | | that easy to attack?
>
> Olson:
> | You specified a pseudo-random permutation. I wrote that a
> | block with the properties that support the attack probably
> | exists among about a thousand blocks. If the identity is
> | one of the inter-round permutations, such a block will not
> | exist.
So does that imply that there is a factor of the order of
1000 in comparison with cracking the original block cipher?
If not, why?
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: The talk of R. Moris
Date: Mon, 09 Oct 2000 18:29:31 +0000
Ross Anderson wrote:
>
> Mykhailo Lyubich <[EMAIL PROTECTED]> writes:
> >does somebody know, where I can obtain a stenography of
> >R. Morris talk on Cambridge Protocol Workshop in 1994.
> I'm afraid the proceedings didn't get published. The talk was taped
> and the tape sent off for transcription, but the workshop chair left
> the laboratory to work for a bank and the book just never appeared
I took fairly careful notes on the invited talk by Robert H. Morris
at Crypto '95. It sounds like some of the same topics were addressed.
Perhaps some who were at the Cambridge Workshop could check my writeup
at
http://chacs.nrl.navy.mil/ieee/cipher/old-conf-rep/conf-rep-Crypto95.html
and see whether it rings any bells. Morris reviewed my writeup and
agreed that it matched what he'd intended to say.
--
Jim Gillogly
Trewesday, 18 Winterfilth S.R. 2000, 18:26
12.19.7.11.2, 5 Ik 5 Yax, Sixth Lord of Night
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: Mon, 09 Oct 2000 18:32:58 GMT
Is there a royalty free library for SSL available? Does it encrypt both
from the client to the server and the server to the client?
TIA,
Will.
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
Arnold Shore <[EMAIL PROTECTED]> wrote in message
news:8rs9sj$2h8$[EMAIL PROTECTED]...
> Won't the encryption provided by an SSL session do what's needed? A
> server-side certificate is all that it takes - price somewhere between
cheap
> and free.
>
> Arnold Shore
> Annapolis, MD USA
>
>
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: MITM attack
Date: Mon, 09 Oct 2000 18:38:21 GMT
How likely is a MITM attack on an internet connection from an ISP like BELL
(ADSL from server to BELL) to a client anywhere in the world? I would think
that because the packets can be routed just about anywhere and everywhere,
MITM would be very difficult. I could be wrong.
TIA,
Will McKee.
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Mon, 09 Oct 2000 12:41:53 -0600
John Savard wrote:
>
> On Mon, 09 Oct 2000 09:48:00 -0600, John Myre <[EMAIL PROTECTED]>
> wrote, in part:
> >Brian Gladman wrote:
>
> >> Perhaps
> >> worse, I think IBM has patented them and this might cause problems if they
> >> were adopted.
>
> >Yuck.
>
> I think I know which patent is being discussed here.
<snip>
> The scheme proposed by IBM involved a double encryption in CBC mode,
> with one pass going forwards over the message, and one pass backwards.
<snip>
That doesn't sound very much like the techniques in the
paper. Are you sure about this?
JM
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: xor algorithm
Date: Mon, 09 Oct 2000 18:45:31 GMT
Antonio Merlo <[EMAIL PROTECTED]> wrote in message
news:8rs4sr$mm7$[EMAIL PROTECTED]...
> How strong will be an encryption method based on a xor operation with a
pass
> phrase (or password) an a buffer to encrypt? (suppossed a very strong
> password of, let's say 16 letters, combining uppercase, lowercases and
> digits)
> How will you cryptoanalise that algoritm?
>
>
If you use your password to seed a pseudo random number generator (PRNG)
like ISAAC, WAKE, etc. and xor the buffer with the PRNG output, I think it
can be quite secure. I may be wrong. I'm such a newbie :)
Cheers,
Will.
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
------------------------------
** 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
******************************
