Cryptography-Digest Digest #584, Volume #10 Wed, 17 Nov 99 21:13:03 EST
Contents:
Realistic view of AES (Tom St Denis)
Re: "Compressible Encryption" - Is it an oxymoron? (fungus)
Re: AES cyphers leak information like sieves (wtshaw)
Re: AES cyphers leak information like sieves (wtshaw)
Re: Scientific Progress and the NSA (Scott Nelson)
Re: What part of 'You need the key to know' don't you people get? ("Gary")
Re: International crypto restrictions (Paul Koning)
Re: weak ciphers and their usage ("Douglas T. Yoest")
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (JPeschel)
Re: AES cyphers leak information like sieves (James Felling)
Re: weak ciphers and their usage (Johnny Bravo)
Re:SCOTT16U SOLUTION ON THE WEB (Tom St Denis)
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: AES cyphers leak information like sieves (Jerry Coffin)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Realistic view of AES
Date: Wed, 17 Nov 1999 21:31:12 GMT
First off this is a rant post, so if you are not in rant mode please
ignore.
Ok people have been bashing and praising AES for a bit now. Let's
think of some realistic facts about AES
1) It's being designed openly by people around the world. Not the
NSA. Despite popular believe open academic cryptanalysis *is* fairly
advanced including attacks against ciphers like IDEA/Blowfish/RC5
[which admitedly do not threaten the security thereof]. Also
skipjack ... hehe
2) In five years the top five AES ciphers will most likely be in 90%
of all cryptography related systems. So you might as well get used to
it.
3) The AES ciphers are not revolutionarly superior too anything else
that has been brought out. There are already known 'academic flaws'
against pretty much all of them. These attacks range from known
differentials to poor key diffusion, etc.. They may not threaten the
cipher but are attacks none-the-less.
4) The AES ciphers are probably best characterized as improvements of
other ciphers. Most notably RC6, SAFER+ and Twofish.
5) Despite not being in the last round, most other ciphers [like
SAFER+ which is pretty cool as far as I am concerned] are still
strong. They just aren't the top as speed/size related issues go.
6) Whether you like it or not, AES ciphers will be used and are being
used [my program for example]. So you might as well like it.
That was my 2 cents, my invoice is in the mail :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: "Compressible Encryption" - Is it an oxymoron?
Date: Wed, 17 Nov 1999 14:56:27 +0100
Paul Mullen wrote:
>
> As you are probably aware, the default setting for Microsoft Outlook
> personal folder files is "Compressible Encyption", with alternatives of
> better encyption and no encryption.
Pfffttttt!
<Caffeinated beverage hits the screen...>
Does it *really* say that?????
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 16:01:10 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
...
>
> I would be interested in *one* example of a well-respected block
> cipher that *does* provide error recovery.
So many have worked so hard to define as respectable those ciphers which
do not provide error recovery within themselves, while down playing those
that might. The discussion highlights that normal respectable designs
are, in essence, insufficent in themselves.
It does me good to see so many beginning to define vital problems, even as
I have already solved them. And, if my solutions have fallen on deaf ears
because they sound strange, better start giving a listen, as they are
sound answers to the types of difficulties under discussion.
--
The circus elephant has lost its way.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 16:19:35 -0600
In article <80tgev$tg6$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Then by your on words. What fucking good is it to have this
> featured forced on one self. Error recover means that you get
> a few garbled blocks but that the rest of message is ago.
> But even in things like PGP this errory recovery is of no use.
> So the option to dump it shoulf be there.
>
In communications, there is signal, and there is noise. And, efforts to
distinguish the two are also subject to the same problems again. The
solution comes down to one key idea, redundancy, which demands that more
information is involved than the original input.
Efficiency and success require that redundancy to be only adequate,
sufficient to guarantee results while not adding exorbitant waste.
As long your communications are pristine, there is no reason for worrying
about errors or recovery. But, the real world guarantees that this is not
always the case.
The *leaking* as specified in many block ciphers is telling, and the need
for external patches are telling as well; ciphers which are insufficient
to the role they are to play are easily seen to be inadequate.
If the definition of a block cipher is so restrictive to preclude solving
these problems, and the better alternative is too foreign to share the
same classification, then block ciphers in themselves as true security
devices are obsolete.
--
The circus elephant has lost its way.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Scientific Progress and the NSA
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 21:53:38 GMT
On Wed, 17 Nov 1999 20:27:46 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>
>: The theory that they're all a bunch of con men
>: is nether more nor less plausible than the idea
>: that they're all super competent, or decades ahead
>: of the public [physics|cryptographic|computer]
>: research community.
>
>The theory that they're all a bunch of con men is certainly extremely
>implausible.
>
Never denied it.
What I'm claiming is that it's _just as likely_ that their
all a bunch of con men as that their ultra-bright researchers
that are ten (or more) years ahead of the public physics
community.
>Since nobody is claiming that they're "decades ahead of the public
>[physics|cryptographic|computer]" community, the comparison is
>not very realistic.
>
Huh? That's not the impression I got from previous
posts in this thread. Wasn't there a post which said
"How do you know the intelligence community didn't
invent quantum computers a long time ago?"
If they did, that would mean they are at least
as many years ahead of the public physics community
as <long time ago> + <years until the public has one>
>Certainly intelligence agencies have a history of developing things before
>the open community behind closed doors.
>
>To doubt that the stories revealed thirty years down the line are
>true is a little unreasonable - after 30 years there've very little
>reason left to lie.
>
They've got Billions of dollars worth of reasons.
Anything they can lay claim to is a further
justification of their usefulness to congress.
Don't get me wrong, I'm not saying that they're
lying just to claim credit, I'm just saying that
there are still reasons why someone would lie,
even 30 years after the fact. If I had to bet,
I'd bet that the NSA did know about differential
cryptography before IBM re-invented it. But I
wouldn't bet my life savings on it, only about
7/8 of my life savings.
>: The NSA isn't likely to be decades ahead, or
>: even years ahead, of the computer industry -
>: Thanks to Mores law, there's no percentage in
>: investing in computers, so any advantage they
>: have would have be lost every few years. They
>: probably know that, and don't waste a lot of
>: money buying computers.
>
>Moore's law exists partly due to technology shrinking - it's
>about transistor density as much as speed.
>
>The computers under discussion are mainly quantum computers.
>
>If feasible, they will be likely cause a blip in the performance
>aspect of Moore's law.
>
>: Basic research is more iffy, but there's _a lot_
>: more people who don't work for the NSA, than there
>: are working for it.
>
>The NSA has access to their research data. The reverse is not true.
>
>The NSA is like a Zenner diode - information flows into it from
>one direction, but few people see anything come out again ;-)
>
>: Assuming that the NSA has quantum computing because they
>: would keep it a secret is silly.
>
>That would be a reversal of causality. The NSA may *well* have
>a quantum computer, though.
>
>: The only place the NSA is going to have that kind of lead is
>: the places where the NSA is the only one doing the research.
>
>Like - um - cryptography?
>
>Where *do* you get such ideas?
>
Probably the same place you get the idea that they
may have a quantum computer.
Sure, they _might_ have one, and they certainly want one,
but what evidence is there to support the idea that they
already have one? More to the point, why are they so much
better at building them then the rest of the world, combined?
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 17 Nov 1999 22:02:30 -0000
I think he's trying to say that an attacker need only work with twice the
cipher block length in the 3 letter modes.
Whereas in a wrapped mode he needs to work on the whole ciphertext.
This means a lot of more memory and time in a parallel attack.
However with an undisclosed IV and large key size the 3 letter modes seem
very secure to me.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: International crypto restrictions
Date: Wed, 17 Nov 1999 17:33:14 -0500
"Trevor Jackson, III" wrote:
>
> Bill Unruh wrote:
> ...
> > >Is it correct to say that the use of blowfish - limited to say 40bit
> > >keys - built within an application (for encrypting data files) outside
> > >of the USA and "written" by a non-us citizen is still subject to the US
> > >export laws ?. Does blowfish not fit within the definition of 56BIT DES
> >
> > If exported from the USA then yes. If not exported from the USA then no.
> > US law has no say in other countries than the USA.
>
> The sentiment is correct, but that ignores a detail. U.S. law applies
> to U.S. citizens everywhere in the
> Universe. Neither physical location nor legal residence matter.
Well, the sentiment is logically sensible but legally INcorrect, for
the reason you mentioned.
Also, another case covered is re-export, i.e., transfer from one party
outside the US to another outside the US, of stuff originating in the US
or created with US help.
> There used to be laws in France against use.
Still are, I believe, but the numbers have changed.
paul
------------------------------
Date: Wed, 17 Nov 1999 18:15:40 -0800
From: "Douglas T. Yoest" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: weak ciphers and their usage
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<p>Tim Tyler wrote:
<blockquote TYPE=CITE>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
<p>[snip Initial Value implications]
<p>: But it does no change the fact that the information of the plaintext
is
<br>: not spread through out the whole file. And this can clearly
be seen by
<br>: just takeing a portion of the encrypted file and using the wromg
IV and
<br>: a different starting block and start the decryption with the correct
key
<br>: and after a start up the rest of fragment gets decrypted to the correct
<br>: plain text.
<p>I completely agree with your conclusion - that the plaintext is not
<br>distributed through the file.
<p>Reversing the explanation John Savard gave me recently, the use of
<br>block chaining means that each cyphertext block depends on the
<br>preceeding cyphertext block and the current plaintext block.</blockquote>
which, by the way, means that the current CT block depends on all previous
CT blocks! ( each preceding block depends on the block preceding it) which
means that each CT block depends on all preceding PT blocks including the
IV (if you bothered to use one)! This provides protection for messages
that are similar, small changes to the PT are expected to propagate throughout
all the remaining CT (please allow for degenerate cases).
<blockquote TYPE=CITE>
<p>It therefore follows (from "rearranging" the above "equation") that
each
<br>plaintext block depends only on the current cyphertext block and the
<br>preceeding cyphertext block. This is surely good news for the
analyst.</blockquote>
It is excellent news for the analyst if the underlying block code is weak.
Thats why you decide if the block code you're using supplies the number
of bits of security you require before you incorporate it in the system.
All the three letter stuff is there to fix the problems of using in codebook
mode (ECB), while accomodating the *other* security requirements imposed
on the *entire* communications channel.
<blockquote TYPE=CITE>
<p>Again - from what I understand - the IV is irrelevant as far as the
<br>decryption mechanism goes. Decryption, simply involves working
<br>backwards through the file, undoing the block encypherment, and
<br>EORing with the cyphertext block to the left to reveal the plaintext.
<br>--</blockquote>
Tell you what, encrypt the same file with the same *good* key, but different
*good* random IVs, and compare the resulting CT. Then ask what good
IVs do.
<blockquote TYPE=CITE>
<br>__________
<br> |im |yler The Mandala Centre <a
href="http://www.mandala.co.uk/">http://www.mandala.co.uk/</a>
[EMAIL PROTECTED]
<p>True rejection is when your imaginary friends won't talk to you.</blockquote>
</html>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 18 Nov 1999 00:15:53 GMT
In article <80v8ru$jv9$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]>
wrote:
>I think he's trying to say that an attacker need only work with twice the
>cipher block length in the 3 letter modes.
>Whereas in a wrapped mode he needs to work on the whole ciphertext.
>This means a lot of more memory and time in a parallel attack.
>
>However with an undisclosed IV and large key size the 3 letter modes seem
>very secure to me.
Yes and the Germans where convinced there Engima was safe due to its
large key size. Much larger than the AES key sizes found in the weak AES
ciphers. See articles on just how large this actually key size was in some
versions of the ENigma it would surprise you. Yet without modern computers
they were broken. It is foolish to assume your safe just because you think
it is. THe enemy may think different than you.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Thu, 18 Nov 1999 00:11:13 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
I thought HTML is not a way to post my news reader does not like it dougy
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 Nov 1999 23:15:02 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
:> If you want to sign a message, include a message digest, or otherwise
:> verify the message is as-sent, you should virtually never include a hash
:> in the plaintext.
:>
:> Simply, this allows an attacker to reject invalid keys.
: If you're using a MAC, the attacker can use it to reject invalid keys
: if and only if you use the same key for both the encryption and the
: MAC. [...]
I wasn't intending to refer to such a case.
My comments apply to keyed hashes where the validation-key is public, and
/anybody/ can verify that the sender of the message is authentic and that
the contents of the message have not been tampered with.
If (for example) the key to the hash is only known to the prospective
recipient(s) of the message, there is no problem.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A paperless office has about as much chance as the paperless bathroom.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: 17 Nov 1999 23:31:51 GMT
fungus [EMAIL PROTECTED] writes:
>Message(S) - plural isn't "only one"
>
>The attack relys on having more than one encrypted file
>available. If you can't understand the implications of
>the weakness then you need to do some more reading.
>
No, you're wrong. You can do a ciphertext-only attack with
many ciphertexts, some of which may be unrelated, or
you can attack succesfully, in many cases, with only one
ciphertext. Perhaps that is why you were confused by
the change in number, or did you think you were correcting
my grammar?
It's always good to do more reading, and I shall, in the
meantime, you'll find of plenty of examples of attacks
that require only one ciphertext.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 17:34:53 -0600
Anton Stiglic wrote:
> Tim Tyler wrote:
> >
> > After reading the recent contributions to the "SCOTT16U SOLUTION ON THE
> > WEB" thread in this forum, I was disturbed to find that a number of
> > sci.crypt subscribers were /still/ towing the party line that the AES
> > block cyphers might have some security value - *despite* the efforts of
> > David Scott to explain exactly why they should be considered insecure.
> >
> > The problem is simple: the AES cyphers are fixed 128-bit block cyphers.
> > The encode identical blocks in the same way. For certain types of
> > message, this is a complete security disaster.
>
> Duhhh!! This is why they have invented chainging modes of encryption.
>
> I'm begining to think that Tim Tyler is in fact SCOOT16U, just using
> an e-mail adress with a different name....
>
> Anton
I am fairly certian that he is not, and is actually a reasonablly rational
person.
The way the two of them write is very different.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: weak ciphers and their usage
Date: Wed, 17 Nov 1999 18:45:08 GMT
On Wed, 17 Nov 1999 02:24:12 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Nonsense Dave just as you lack the ability to understand the complexites
>of my code. You seem to lack a basic understand of what common chaining does.
>Here is something you can do with a crappy AES type of encryption with your
>secret IV. Take a long file and encrypt it. Cut off the front third and last
>third of the file. Know if a good cryptographer like me or better in case
>your not good enough to handle it. Is given the middle thrid of file with the
>cipher and key but not the IV the center third of file can be recovered easily
This is the attack you have been ranting about all this time? If
your attacker has your key and IV and only the middle third of the
file you are vulnerable?
Well hell, under your system if your attacker has the key and IV the
first third of your file you are vulnerable. Under your own criteria
scottXXu is a weak cipher whose only security lies in the chance that
your attacker doesn't get the first part of your encrypted
transmission, glad to see you finally admit your tinkertoy cipher
isn't worth the electrons it was coded with.
Johnny Bravo
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Thu, 18 Nov 1999 00:12:30 GMT
In article <80ufas$d60$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> No this is not ture. It prevents certain types of plain text
attackes.
> Also forcing the attacker to look at the whole file rather than
allowing
> the attacker to concentrate his attack on the portion of the file
that he
> wants. If this was not ture you might as well argure for 8 bit blocks
> instead of 128 bits. The thing is longer block sizes offer more
security
> and using the whole file as a block is the best one can do.
No actually it is true. If I have a 1024 bit message I want to brute
force I have todo (1024/128 * wraps) decryptions versus just two or so
decryptions for normal CBC. So if you encode forwards and backwards a
TOTAL 25 times, I have to decrypt 200 blocks instead of 2. If I add
another block I get 225 [this is the linear part] [y = wx, where w is
the number of actual encryptions applied, and x is the number of
blocks]. This is completely linear.
I could simply add a bit to the key for every doubling of w. This
seems much easier to me.
Of course I wouldn't not attack this way, but it illustrates my point.
> What is your porblem Tom yes my "wrapped PCBC" is for block
> ciphers. But you don't understand how to use it. And yes for certain
> types of attack which may not be reasonable to carry out in the first
> place it would add complications in a LINEAR fashion. That does not
> mean that all attacks of various forms would add LINEARLTY so you
> don't understand crypto.
If I had a differential that applied to 16 rounds of cipher_x for
example, then 32 rounds either gets linearly harder or exponentially as
the rounds increase. It depends on the attack.
> While it is not meant for everything. You seem to be under the
illusion
> that if it is not good for every case then it is not good. Yet when I
show
> cases where the other is bad you but blinders on. Nothing is good for
> everything so don't use the CBC or 3 letter crap for everything
either.
Stop calling it crap, and I may just go out and respect your opinion.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 Nov 1999 00:11:16 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
:>: [After trying bi-directional CBC] what I found out was that when one
:>: does either of the 2 methods and you hex edit the encrypted file only
:>: a few blocks of plain text are messed up. So that the information is
:>: not really spread throught the file.
[snip disclaimer]
:>It is true that editing a bit in a file encrypted using this method
:>will change three blocks. Two blocks will be changed completely,
:>and one partially.
:>
:>However, this does not mean that information relating to the encrypted
:>text is not spread throughot the file.
[snip criticism]
: To me the concept is pretty strainght forward. If a portion of the data
: can be recovered from a portion of the file then all the information for
: reconstructing that info is there. What could be easier to understand.
Yes, sorry. My post was confusing. I agree that the information about
the plaintext gets localised in a corresponding region of the cyphertext.
With the system specified, changes to a single bit of plaintext does
cause the surrounding *data* (in both directions) to change; but the
*information* about the plaintext remains localised over the three blocks
immediately around the change - as you originally said.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
You may be a redneck if you own more than two tractors.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 17 Nov 1999 17:21:32 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
>
> : Those who really believe that simply re-transmitting a message is
> : reasonable if it doesn't come through intact should read _Between Silk
> : and Cyanide_ continuously until they learn better.
>
> What are you talking about? Retransmitting a cyphertext presents
> practically no security risk at all.
I'm not talking about a risk of security due to the message being
intercepted. I'm talking about a risk (in some cases quite extreme
risk) of the person sending it being found and killed, for one
example.
Assume I'm spying on a terrorist organization and I find that they've
planted a nuclear device in New York City. As a dutiful spy, I want
to send a warning back home trying to get it dealt with before it
kills several million people. If they're good, there's a pretty fair
chance that they're doing their best to both jam and track down my
radio transmissions. The jamming gives a high probability that only
part of the message will arrive intact. The tracking gives a high
probability that re-transmitting too often will get me killed. Not
getting the message through at all gives a high probability that 10
million (or so) people get killed.
In this situation, my choice would be to use CBC for its error-
recovery capabilities. If it comes down to it, I'd rather transmit in
plain text than take a chance on the message never getting through at
all...
> Keeping compression separate is a good idea. However, a "chaining mode"
> is not a necessary component of a cypher. For one thing it necessarily
> introduces a serial component to encyphering. If you have a parallel
> machine available, introducing something like this may kill performance.
> My code is mainly targetted at FPGAs. In such domains, "chaining modes"
> are not really on the menu.
I think I pointed out that ECB can be useful in this sort of
situation. I'll also point out, however, that ECB is NOT the only
solution. Another possibility would be for each device to use CBC,
and simply have a number of interleaved streams, each encrypted by one
device. Each device (and therefore each stream) uses a separate IV.
Unless you're using such massive parallelism that you expect each
device to encrypt only a very small number of blocks, this makes
little difference to much of anything and preserves the overall
performance of the design -- about all it really does is require a
_little_ extra transmission bandwidth to transmit the larger number of
IVs. If you're working with so much bandwidth that you need multiple
devices to handle the throughput, a few extra IVs being transmitted
isn't likely to cause a problem.
> This is a virtue of using error-correction technology. No matter /how/
> noisy a channel you are faced with you can still get a 99.99% chance of
> successful transmission if you throw bandwidth at the problem.
Yes, if you have sufficient bandwidth to spare you can overcome almost
any amount of noise. Sometimes you just don't have that kind of
bandwidth though...
> Under the *insanely*-infrequent conditions where you have limited
> bandwidth, high error rates, no chance of resending a failed message, and
> you /must/ get some fragments of your message across, this can /still/ be
> done by splitting the message up. This reduces it to a cookbook-mode
> block cypher. You can /still/ apply block chaining to consecutive
> messages if you /really/ want.
IOW, with enough kludges, you can overcome the inherent shortcomings
of the particular chaining mode you're advocating...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
