Cryptography-Digest Digest #610, Volume #10 Tue, 23 Nov 99 02:13:03 EST
Contents:
Re: AES cyphers leak information like sieves (John Savard)
Re: Apparently, Hushmail does work ([EMAIL PROTECTED])
Re: NSA should do a cryptoanalysis of AES (Bruce Schneier)
Postdoctoral positions in cryptography and quantum computing (Alfred John Menezes)
Re: PGP (Steve K)
Re: MP3 to CD?? (Doug MacKay)
getting a public key (MANIK TANEJA)
Re: AES cyphers leak information like sieves ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: technical writing skills required! (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 23:42:49 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
>It appears from David's recent comments that he genuinely thinks that
>error recovery is possible with CFB mode.
He's right.
The term "Error recovery", with respect to block cipher modes, doesn't
mean that the particular block where the error occurred can be
recovered. It means that _succeeding_ blocks aren't all garbled too.
In CBC mode, only two blocks are garbled; the block itself, and the
next one that used the previous ciphertext. (You might be able,
assuming a 1 bit error, to make 64 tries (for DES), and get your
second block fixed.)
In CFB mode, the previous ciphertext block is enciphered via your
block cipher, and the result is XORed to the plaintext, the result of
that XOR being your ciphertext.
So if there's a single-bit error in the data stream, there's a
single-bit error in your current plaintext block - and the following
plaintext block will be garbled completely. Future blocks will make
sense.
If the current plaintext block "makes sense", i.e., isn't super
compressed, you can see which bit is wrong - and fix the error in the
ciphertext, and get the garbled block too.
So error recovery *is* genuinely possible with CFB mode - both the
continuance of communications, and even fix-up of the bad part of a
slightly garbled message, if the plaintext is redundant.
John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Apparently, Hushmail does work
Date: Tue, 23 Nov 1999 00:40:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> A posting in
>
> jyu.ohjelmonti.coderpunks
>
> mentions
>
> http://www.hushmail.com/how_it_works.htm
>
> which seems to indicate that the resident application from Hushmail
> works basically the same way that PGP did; thus, except for the fact
> that its source isn't available, and worries of that nature, there is
> no reason to believe that it doesn't "work".
>
> John Savard (don't snooze, don't snore)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
The source code is available now, though their server was
down when the above was posted.
http://www.hush.ai
has the current source (1.11), and
http://www.cypherpunks.ai/~hush
has archives of previous versions.
Hushmail tech support has given out detailed
instructions about how to compare the source
against the downloaded applet. I posted a copy
to sci.crypt a few months ago.
Their big departure from the way PGP works is to
allow roaming. Since you can log in from any
Web browser they have to store the equivalent
of your secret keyring on their server. Better
have a really good passphrase.
Fred frederw at sign pobox.com
Hushmail customer, no other business connection
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 23 Nov 1999 00:49:58 GMT
On Tue, 16 Nov 1999 17:30:31 -0800, albert <[EMAIL PROTECTED]>
wrote:
> I see that NSA has not entered a candidate for AES. I assume it's
>because they don't want to give away some secrets they have. What
>secrets? My conspiracy theories...
> Suppose the NSA has found a way to break feistel ciphers, and SP
>style ones. So what would that mean? That would mean that their
>algorithm would be based on something totally different, to combat that
>kind of attack, just like before Serpent came out, we all knew that
>Eli's entry would almost certainly be resistant against differential
>attacks. That is why Bruce says good crypto analysists make good cipher
>writers, because they will design ciphers that are resistant to their
>own attacks, so the better the attacker, the more resistant their
>algorithms (generally).
>BUT, they should post a thorough analysis of the AES candidates. We'd
>like to see what our tax-dollar funded crypto-think tanks have come up
>with in terms of attacks and analysis.
>
>Do you think the reason they aren't giving an analysis is because they
>can break all the second round candidates and so they aren't going to
>say anything about it? I personally don't, but it's a thought...
I can only tell you what NIST has said publicly.
The NSA was ready to submit a cipher, but NIST asked them not to.
NIST would rather have the NSA as an impartial analyst than as a
partial combatant. Certainly, any analysis the NSA does will be
classified. I agree that this is annoying, but it's about what I
expected.
The only way this will turn out badly is if public opinion leans
heavily towards one cipher and NSA classified opinion leans toward
another. Then, NIST has a problem.
Personally, I don't believe that the NSA will point to a weakened
cipher design and suggest that NIST choose that one. That kind of
secret just won't stay inside the agency...it will eventually leak.
And the academic community will figure out the NSA's attack, sooner or
later.
I truly believe that everyone's intentions are honorable here. The
only problem I forsee is if the NSA has classified information that
affects NIST's decision.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: Postdoctoral positions in cryptography and quantum computing
Date: 23 Nov 1999 01:25:56 GMT
==========================================================================
POSTDOCTORAL POSITIONS IN CRYPTOGRAPHY AND QUANTUM COMPUTING
Centre for Applied Cryptographic Research
Department of Combinatorics and Optimization
University of Waterloo
Applications are invited for several one-year and two-year
postdoctoral positions in any area of cryptography or quantum
computing. Some of these positions are being funded through
the Applied Cryptography project, which is part of the MITACS
Network of Centres of Excellence.
A Ph.D. and proven ability, or the potential, for excellent
research is required. Responsibilities may include teaching
one undergraduate or graduate course per year. Successful
candidates will be joining a substantial research and training
centre in cryptography at the Centre for Applied Cryptographic
Research (CACR). Information about CACR personnel and activities
can be found at www.cacr.math.uwaterloo.ca
The normal starting date of the appointment is July 1, 2000, however
this can be changed on the applicant's request. A $3,000/year travel
grant will be provided (with the possibility of more travel funds
subject to availability).
Interested individuals should send a curriculum vitae, 2 or 3
selected reprints/preprints, and the names of three references
to: Cryptography PDFs
Department of Combinatorics and Optimization
Faculty of Mathematics
University of Waterloo
Waterloo, Ontario, Canada N2L 3G1
email: [EMAIL PROTECTED]
phone: (519) 888-4566 x3482
fax: (519) 725-5441
http://math.uwaterloo.ca/CandO_Dept/homepage.html
Closing date for receipt of applications is March 15, 2000.
Some applications may be processed as they are received.
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: PGP
Date: Tue, 23 Nov 1999 01:57:12 GMT
On Mon, 22 Nov 1999 20:48:52 GMT, [EMAIL PROTECTED] (CoyoteRed)
wrote:
>Markku J. Saarelainen said...
>
>> personally I would not use pgp, but I would use another method for
>> encrypting my email messages ....
>
>Like..?
>--
>CoyoteRed
>CoyoteRed <at> bigfoot <dot> com
>http://go.to/CoyoteRed
>PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
>
And, why?
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
From: Doug MacKay <[EMAIL PROTECTED]>
Subject: Re: MP3 to CD??
Date: Mon, 22 Nov 1999 21:22:36 -0500
> Is there a way to get MP3 to a CD?
Convert it to wav format and have your burner software write it to disk
as cd audio. (most are able to do this)
btw. This is the wrong newsgroup for this question.
-doug
------------------------------
From: MANIK TANEJA <[EMAIL PROTECTED]>
Subject: getting a public key
Date: Tue, 23 Nov 1999 07:58:52 +0000
how can i get myself a public key from some certified authority / trusted
third party. also can i acquire it programatically. are there any code
samples. please give me a refrence of some kind.
thank you
manik Taneja
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Tue, 23 Nov 1999 03:36:34 GMT
Tim Tyler wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> : No, we discussed this previously. That is what "one-to-one"
> : means, but not what "one-on-one" means. *Any* reversible
> : compression is "one-to-one", but D.Scott has something more
> : specific in mind.
> I *think* you meant to say ``*Any* reversible compression is "one-on-one"''
No! Why don't you try harder to understand what is said,
rather than rewriting it?
> That there's a "one-on-one" relationship between the domain and the range
> of the compressor is taken for granted.
What on earth are you talking about? "One-on-one" as a technical term
was adopted recently by participants in this forum *specifically* to
talk about a particular property that D.Scott thinks is an important
feature of his compression scheme. It surely isn't applicable to all
compression schemes.
"One-to-one" (notice the difference in the spelling!) is a standard
mathematical term, meaning that distinct points in the domain are
mapped to distinct points in the range; this is of course necessary
for any lossless compression, including D.Scott's, but his scheme
has a more special property (which we've been calling "one-on-one").
> there's a bijection between the input and output sets of the compressor.
> He calls compressors with this property "one-on-one".
> In particular I wanted to distinguish such compressors from ones that
> simply spat out plausible-looking decompressed files for every possible
> input. These compressors do not necessarily have David's property.
As stated that makes no sense, but assuming you meant *de*compressors,
then yes, they *do* have the "one-on-one" property. Or rather, they
have a useful property that *ought* to be what is meant by this new
term.
> :> ... readers should note that, in many respects, the *primary*
> :> point of the property is that it hinders any cryptanalytic attacks
> :> based on regularities in the compressed files, ...
> : That has merely been asserted, not demonstrated.
> Systematically adding a bunch of information not present in the plaintext
> seems likely to assist attackers to me - unless that information was
> generated with some kind of "real" source of entropy.
> So yes, I make the assertion.
What relevance does that have to hindering *any* attacks based on (any)
regularities? Even D.Scott's scheme has regularities.
If you think that the main merit of D.Scott's "one-on-one" compression
is merely that it doesn't inject an obvious header into the output,
you've missed what is so special about it.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Tue, 23 Nov 1999 04:52:15 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Actually it's right, and it's nothing new.
> CBC mode isn't p=D(c) xor IV, it's:
> p =D(c) xor c-1, where c-1 is the previous ciphertext block.
Actually no he isn't. The IV is always the previous block. And he
stated his attack can take any block from anywhere in a CBC message
regardless of knowledge of the IV. This is not true.
> While each ciphertext block does depend on the IV, you only need one
> previous ciphertext block to decrypt. This isn't a weakness of CBC
> mode, it's designed so that two different messages don't encrypt to
> the same ciphertext, and they won't. It also reduces patterning, in
> that identical blocks within the plaintext will encrypt to different
> values.
If there is a transmission error, two blocks will be affected. If you
don't know the IV, only one will.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Tue, 23 Nov 1999 04:55:25 GMT
In article <81bhk8$29no$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Look that is the party line. How can you say that it is not a
weakness
Whatever messiah. [sorry if anyone is offended but the analogy holds
true].
> But it is designed to do that with the property that if there
> is an error in a byte in the middle of the file that error will
> not effect all the trailing blocks. Think about it. When one
> crates a block cipher they try to make avalanche and diffusion
> of the information through out the whole block. And they try
> to make block size larger to spread this effect out. Then
> thye use chaining to prevent the spread through the rest
> of the file..
So again I ask, what part of 'cryptanalysis' don't you understand? If
you have yet to break the underlying cipher, CBC mode is pretty much as
good as you need. ECB mode is ok, only if replay attacks need not
apply. In CBC mode all the info [minus the key] is present to
decrypt. So the diffusion 'among blocks' is completely moot. It's
withing each block that matters here.
> >So the main strength of CBC is to thwart the use of multiple
> >ciphertext messages to assist in breaking messages encrypted with the
> >same key, and it does this.
> >
> I disagree!!
The main use of CBC is to avoid frequency and replay attacks. That is
all.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Tue, 23 Nov 1999 04:57:16 GMT
In article <81bh7h$29no$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Tom why do you act so stupid. Just try the dam example.
> Encrypt several blocks in a file using an IV of your choice.
> Then decrypt with a different IV and look at the files in hex.
> I get tired of telling you this. Since you seem to stuipd to
> even test it out. Yeah stupid the first block is wrong when
> you decrypt but look at the whole file asshole.
Ok so what is this test?
1. Create random K
2. Encrypt M with K [C = Ek(M)]
3. Ditch K
4. Modify byte of C
5. Decrypt C with what K?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Tue, 23 Nov 1999 05:01:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> It is your argument which is flawed.
>
> The "IV" in common parlance refers to the "initial value".
Actually IV normally refers to [in CBCs case] of the ciphertext at
zero. Since this cannot exist, you make one up. However for argument
sake the IV can be anywhere in the message.
> Your equation presents the "IV" as being the cyphertext of the
> preceeding block.
And this is flawed?
> *Obviously*, if they have a chunk of cyphertext, for each block of
> cyphertext except the first one they have, the preceeding block
> of cyphertext will be available to them.
>
> They use this as what you are calling the "IV". It is /known/ to
them.
>
> They don't need the "IV" the first block of the file was encrypted
with
> initially to figure it out. That value is irrelevant for the
decryption
> of all but the very first block of the file.
Yak yak yak.
IV's are never really considered private. Since for N blocks, N-1 of
them will be known anyways. Still you guys miss the point, if you
don't know the value of the key, you won't decrypt A SINGLE BLOCK. So
it matters not if the bits are 'smeared' through out the file.
Your argument is like saying driving 60 kph is so much more then
55kph. They will both get you somewhere, one's just a tad faster.
Can you still get there at 55kph? Yes. Are CBC blocks still secure
[when all is well], Yes.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: technical writing skills required!
Date: Tue, 23 Nov 1999 05:02:36 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > > I think that's a good idea. Posting short sections in a single
thread
> > > would make comments easy to find, and edits easy to suggest using
the
> > > Usenet quote-response convention.
> >
> > Would it be more usefull just to divide the paper into small text
> > files, then just post urls? I don't want to flood the group.
Assuming
> > I can muster enough time todo this [which I want to]. I could then
> > edit it into one document when it nears completion...
>
> Depends on how big the files are. If it's just a couple of pages,
> posting it is easier to reply to. If it's longer than that, posting
URL's
> is fine.
>
> Each section ought to be small anyway, so posting only a couple of
> pages a day can't hurt. given the amount of noise already here, you
> won't be flooding, you'll be increasing the signal level :-)
What is the current S/N ratio anyways? :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
