Cryptography-Digest Digest #621, Volume #14 Fri, 15 Jun 01 21:13:00 EDT
Contents:
Re: IV ("Tom St Denis")
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Is ECB truly more secure than CBC? ("Joseph Ashwood")
Re: integration question (Fat Phil)
Re: Is ECB truly more secure than CBC? ("Joseph Ashwood")
Re: Is ECB truly more secure than CBC? ("Joseph Ashwood")
Re: Simple Crypto II, the public key... (Fat Phil)
Re: Is ECB truly more secure than CBC? (those who know me have no need of my name)
Re: Simple Crypto II, the public key... ("Tom St Denis")
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Bow before your new master (Jschutkeker)
Re: Is ECB truly more secure than CBC? ("Boyd Roberts")
Re: Is ECB truly more secure than CBC? ("Paul Pires")
Re: Simple Crypto II, the public key... ("Boyd Roberts")
Re: Is ECB truly more secure than CBC? ("Boyd Roberts")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: IV
Date: Fri, 15 Jun 2001 23:51:45 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (David Wagner) wrote in
> <9ge3vo$osg$[EMAIL PROTECTED]>:
>
> >Mark Currie wrote:
> >>how does CTR compare with CBC from a security perspective ?
> >
> >They're both secure for secrecy, if the underlying block cipher is
secure.
> >(Maybe I didn't understand the question.)
>
> Actaully since no one can really say for sure if the underlying
> cipher is secure. Its kind of an oxyymoron to say if the underlying
> block cipher is secure. In reality one must assume weakness in the
> underlying cipher and start the evaluation from there. From that
> point of view it should be clear that CTR mode is far more likely
> to be weaker than CBC mode. But again one needs a full model to
> compare. Since CTR mode is in theory made for any length file while
> CBC is made for files of specail sizes. If one writes proper code
> such as in BICOM which uses CBC mode you can encrypt any size files.
> If one looks at it then I would say CBC is safer. However they are
> both differnt and one could think up cases where one is better.
"Actually since no one can really say for sure if the underlying cipher is
secure. Its kind of an oxyymoron to say if the underlying block cipher is
secure." [sic].
Then you go onto say how BICOM is more secure. Do you see the conflict
here? How can you unequivocably state that CBC or CTR mode is insecure then
proclaim that BICOM is better?
> I feel a good model would be to pretend the key is changed each
> time and then compare the plaintext cipher text outputs. In the
> CTR mode the plaintext length would track the cipher text length.
Hmm? In CTR mode like CBC you typically don't start with the same IV if the
key is fixed.
> And as descussed in a long thread. Thats not as safe if the input
> length can be more obsure. SO no CTR not as safe. Also from
How can you say this? If the length is not a secret then what is the
problem with CTR?
Saying something is "not as safe" means there is a problem that is worse.
What problem are you noting? [other than the length?]
> a Shannon point of view, Cipher that have higher error propagation
> by there very nature are more secure then those that don't have
Actually error propagation is not a part of perfect secrecy. Note that a
OTP over an infinite sized message has zero error propagation (or 1/oo which
is the same as zero) and is still perfectly secure.
> any like CTR mode. But not sure Wagner is familar with Shannon
> since he didn't comment in those longer threads about "perfect
> secrity" where he could have helped assuming he knew anything
> about the subject.
Again he probably did not comment because he won't talk to you. I don't
know the real reason though...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 23:53:12 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Joseph Ashwood) wrote in <udZ63ge9AHA.185@cpmsnbbsa07>:
>
> >Ok since there's some confusion. XML encryption is for encryption of
> >arbitary documents. The expected primary usage will be for XML formatted
> >data, which tend to look a little bit like:
> ><xml>
> ><tag1>Something</tag1>
> ><tag2><tag3>WHatever</tag3><tag4>blah</tag4>
> ></tag2>
> ><tag3/>
> ></xml>
> >
> >As a result the data may be of any size, or may be a stream. The
> >required algorithms to implement are 3DES and AES (128 and 256-bit
> >required, 192 is optional).
> >There is currently no compression involved (although a compression layer
> >can be added with little difficulty to the parsing, at least once it's
> >defined. If compression was involved then the characteristic I exploited
> >for this would hopefully not have existed. As to whether or not there's
> >any authentication, there may be, but it's commonly restricted to XML
>
> If this is for documents sent over the web. It would be foolish
> to consider encryption without compression. Since the <xml> is always
> front and </xml> is the back. You make to big mistakes not making
> compression part of encryption. Mistake one is you will be wasting
> bandwidth over the net. Since at various stages compression might
> be attempted. If you encrypt no compression can take place later.
> THe other big mistake is your leaking to much information at front
> and back of file. One should use a compressor tuned to XML files.
> Hopefully a bijective one just before you encrypt and send.
I agree compression is better, but not for the reason you state.
Lets say you know P and C but not K. Lets say you use AES in CTR mode.
Tell me how you will find the correct key in less than a brute force search.
[assume the size of the message is under 2^64 blocks].
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 16:49:07 -0700
I could easily argue that the simple fact that no key recovery attack exists
on ECB mode (outside of brute force) makes for a very powerful argument in
the situations where the key is more valuable than the information. It is
also easily arguable that collisions in the 2^64 space represent unknown
quantities until encryption is performed, and that given enough of these
collisions it is not an overly difficult matter (compared to ECB) to begin
the non-key-recovery analysis anyway.
I personally believe that with the (admittedly omitted) consideration that
the key be considered more valuable than the message, the comparison of
availability versus lack of availability of key-recovery attacks on CBC vs
ECB, means that in some situations ECB is actually the stronger of the two
options (other options may be stronger than either, but that is not
considered).
And which attacks on ECB mode for 3DES do you consider "extremely serious"?
I will agree that in general it is wiser to use CBC, but there are
situations where each option is the best, including ECB.
Joe
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9ge4ol$osg$[EMAIL PROTECTED]...
> lcs Mixmaster Remailer wrote:
> >Someone named Joseph Ashwood is posting to the XML Encryption list,
> >presenting himself as a cryptography expert. In his most recent posting
> >he offers an argument as to why ECB mode should be supported in addition
> >to CBC! Will any respected cryptographers speak up to say that this is
> >a credible argument?
>
> No, the argument is nonsense. ECB is far less secure than CBC mode,
> and in his scenario he forgot to consider that there are non-key-recovery
> attacks on ECB mode that are extremely serious. This invalidates the
> claim.
>
> In my opinion, it would be absurd to use ECB mode. CBC mode is just fine.
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: integration question
Date: Sat, 16 Jun 2001 02:58:54 +0300
Tom St Denis wrote:
> > > > We are required to prove that in any set of horses, all will be the
> same
> > > > colour.
> > > >
> > > > 2) The induction step - Let us assume that for arbitrary n, any set
> of
> > > > n horses contains only horses of the same colour. Take a set of n+1
> > > > horses. Remove any horse, and by our assumtion they will all be the
> same
> > > > colour. However, we could have removed any horse, so any one that we
> > > > remove will be in the set of n horses that are of the same colour if
> we
> > > > were to have removed a different horse. And therefore all n+1 horses
> are
> > > > the same colour.
> > >
> > > There is no constraint that the set of n+1 must have the same colour.
> >
> > Come again?
> > That's what we're trying to prove.
> > Given any set of n horses, which we know are all the same colour from
> > the premise, add the n+1-th horse, and remove a different horse. Again
> > we have a set of n horses, and so by the premise they are all the same
> > colour. Add back the horse you removed, and you have a set of n+1 horses
> > all of which are all the same colour.
> > Quod erat demonstrandum.
>
> I don't get this? just because your set has n elements doesn't mean its a
> proper subset of single coloured horses.
Either your comprehension is lacking or my explanation is lacking, but I
really have presented the argument in its canonical word. It does appear
that you have misinterpreted 'horses having the same colour' as meaning
'horses, each individually being single-coloured'.
It's a good job that all us sci.crypt readers live in the same time zone
so that we can have these swift exchanges.
I don't live in 2 time zones, do you?
Bizarre, eh?
Phil
Phil
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 16:55:07 -0700
Since it seems reasonable to assume that most people from XML Encryption do
not read sci.crypt, I am asking for anyone who wants their comments
forwarded directly to XML Encryption to direct them to me (or sign up and
send it yourself). You have my word that any responses (that are not
obscene) will be forwarded, regardless of which side is chosen. (please see
my second response to David Wagner for reference).
Joe
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:#OpzPae9AHA.277@cpmsnbbsa07...
> I will openly acknowledge that this is one and the same Joseph Ashwood.
> Although I would have rather that the anonymous didn't post my work e-mail
> address, I'd rather keep that account fairly clean of outside influence.
>
> Now I will address the OP subject question. No ECB is not more secure than
> CBC, nor is CBC more secure than ECB. The difference in security comes
from
> what type of attack is being protected against. For the post I made to XML
> Enc I made the implicit assumption that the key was more valuable than the
> message, an assumption that may or may not be true. If you assume that the
> content of the message is as important as the key, then CBC is clearly
more
> secure, but if the key is more important than the message (e.g. the key
will
> be used more than once) then ECB offers some advantage. It's a matter of
> usage, and factors outside the most common assumptions rather severely
> influencing the security of the system.
> Joe
>
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 16:58:20 -0700
Can I have your permission to send this directly to XML Encryption?
Alternately if you'd care to send it directly to XML Encryption you'll have
to sign up (http://www.w3.org/Encryption/2001/). Also is there some location
I can send people to for references for you?
Joe
p.s. I would have sent this privately but I wanted to make it known that I
want all perspectives on this subject heard.
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9ge4ol$osg$[EMAIL PROTECTED]...
> lcs Mixmaster Remailer wrote:
> >Someone named Joseph Ashwood is posting to the XML Encryption list,
> >presenting himself as a cryptography expert. In his most recent posting
> >he offers an argument as to why ECB mode should be supported in addition
> >to CBC! Will any respected cryptographers speak up to say that this is
> >a credible argument?
>
> No, the argument is nonsense. ECB is far less secure than CBC mode,
> and in his scenario he forgot to consider that there are non-key-recovery
> attacks on ECB mode that are extremely serious. This invalidates the
> claim.
>
> In my opinion, it would be absurd to use ECB mode. CBC mode is just fine.
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: Simple Crypto II, the public key...
Date: Sat, 16 Jun 2001 03:16:09 +0300
Tom St Denis wrote:
>
> "Fat Phil" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> > >
> > > "Fat Phil" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Tom St Denis wrote:
> > > > > Phil Carmody wrote:
> > > > > > Tom St Denis wrote:
> > > > > > > Of course [for anyone in the dark] a mod operation with these
> > > modulos is
> > > > > > > just a shift right n bits and an addition.
> > > > > > >
> > > > > > > So "mod 255" would be
> > > > > > >
> > > > > > > a = ((a >> 8) + a) & 255;
> > > > > >
> > > > > > Stick 65535 into that :-)
> > > > >
> > > > > 65535 cannot be the product of two #'s less than 255.
> > > >
> > > > In "a mod operation" (your words) products don't enter into it.
> > > > If you had said "in a mulmod (of numbers <255)", then your defence
> would
> > > > be valid, but you didn't.
> > > > Swat up on "programming by contract" next time you have any spare
> time.
> > >
> > > You can't ever get a # greater than 255*255 in any operation. Think
> about
> > > it. The only way to get 65536 is todo 256*256 where 256 is not an
> element
> > > of the ring thus no a valid operation
> >
> > Tom,
> > I look to the heavens for a reason to not use highly pejorative
> > language, but I find none.
> > So I'll stop after saying.
> > Read my my previous post again please. Pay more attention to it this
> > time please.
>
> Say what you want. #>s greater than the square of the largest element are
> not possible.
>
> Even if you did 237^324423492874239347298723489723489242893742 mod 255, you
> will NEVER get a number larger than 255*255.
Look at what you've written!
Any expresssion in that ring will never have a value over 254.
Full stop.
You are seriously confusing the ring in question with machine integers
that the code snippet operates on.
Seriously confusing.
Why do you permit multiplication to create an intermediate result
greater than 254, but no other operation? In the field of computer
arithmetic calculations, multiplication is not a special operation.
(Yes, I know it's special in the ring, but C does not work in the ring,
it works on machine integers.)
If you claim, with no caveat about the domain, that "a = ((a >> 8) + a)
& 255;" is "mod 255" then you are being misleading.
Phil
------------------------------
From: those who know me have no need of my name <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: 15 Jun 2001 23:28:10 GMT
<T6vW6.129114$[EMAIL PROTECTED]> divulged:
>In fact PHP/ASP/XML are all re-inventions of HTML+Perl. Encrypted content
>via SSL already exists and is used widely.
tom, why do you flip out like this? taken to it's logical (idiotic)
extreme your statement says that nobody should do anything because it's all
been done.
e.g., perl was nothing more than a few shell tools aggregated into a single
tool, and html was just an stripped down sgml. the authors of each found
something lacking in what was available and decided that something needed
to be done. (btw: html is written using xml, see
<http://www.w3.org/MarkUp/#whatis>.)
you mention ssl as if it handles everything that might be related to "html"
-- do you even know if it is sufficient or appropriate? since ssl exists
should we all throw away pgp (or gpg if you prefer)? after all e-mail can
be sent using ssl, so why bother with pgp or gpg? perhaps you'll take a
moment to think about it and realize that xml can exist outside of a
transmission channel, and that ssl doesn't handle anything except data
within a transmission channel. heck, ssl depends on tcp. xml can be
transferred using udp. now what?
do you even know what the xml encryption effort is all about? see
<http://www.w3.org/Encryption/2001/>. a trivial example is:
how would ssl handle this ...
some text, perhaps marked-up
text you'd like encrypted in case the "page" is saved
some more text, perhaps marked-up
with xml encryption it might be ...
some text, perhaps marked-up
<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc'>
<xenc:EncryptionMethod xenc:Algorithm="urn:nist-gov:tripledes-ede-cbc">
<s0:IV xmlns:s0='http://somens'>ABCD</s0:IV></xenc:EncryptionMethod>
<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
<ds:KeyName>NamedKey</ds:KeyName></ds:KeyInfo>
<xenc:CipherText>DEADBEEF</xenc:CipherText></xenc:EncryptedData>
some more text, perhaps marked-up
--
okay, have a sig then
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple Crypto II, the public key...
Date: Sat, 16 Jun 2001 00:20:45 GMT
"Fat Phil" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > "Fat Phil" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Tom St Denis wrote:
> > > >
> > > > "Fat Phil" <[EMAIL PROTECTED]> wrote in
message
> > > > news:[EMAIL PROTECTED]...
> > > > > Tom St Denis wrote:
> > > > > > Phil Carmody wrote:
> > > > > > > Tom St Denis wrote:
> > > > > > > > Of course [for anyone in the dark] a mod operation with
these
> > > > modulos is
> > > > > > > > just a shift right n bits and an addition.
> > > > > > > >
> > > > > > > > So "mod 255" would be
> > > > > > > >
> > > > > > > > a = ((a >> 8) + a) & 255;
> > > > > > >
> > > > > > > Stick 65535 into that :-)
> > > > > >
> > > > > > 65535 cannot be the product of two #'s less than 255.
> > > > >
> > > > > In "a mod operation" (your words) products don't enter into it.
> > > > > If you had said "in a mulmod (of numbers <255)", then your defence
> > would
> > > > > be valid, but you didn't.
> > > > > Swat up on "programming by contract" next time you have any spare
> > time.
> > > >
> > > > You can't ever get a # greater than 255*255 in any operation. Think
> > about
> > > > it. The only way to get 65536 is todo 256*256 where 256 is not an
> > element
> > > > of the ring thus no a valid operation
> > >
> > > Tom,
> > > I look to the heavens for a reason to not use highly pejorative
> > > language, but I find none.
> > > So I'll stop after saying.
> > > Read my my previous post again please. Pay more attention to it this
> > > time please.
> >
> > Say what you want. #>s greater than the square of the largest element
are
> > not possible.
> >
> > Even if you did 237^324423492874239347298723489723489242893742 mod 255,
you
> > will NEVER get a number larger than 255*255.
>
> Look at what you've written!
> Any expresssion in that ring will never have a value over 254.
> Full stop.
Oops yeah that should be 254^2
> You are seriously confusing the ring in question with machine integers
> that the code snippet operates on.
> Seriously confusing.
Not really. I have done mod 15 with similar code. I compared it to
(a*b)%15 and got the EXACT SAME RESULTS assuming a,b are <15.
> Why do you permit multiplication to create an intermediate result
> greater than 254, but no other operation? In the field of computer
> arithmetic calculations, multiplication is not a special operation.
> (Yes, I know it's special in the ring, but C does not work in the ring,
> it works on machine integers.)
It should have been 254... I was thinking of mod 256 for some reason...
> If you claim, with no caveat about the domain, that "a = ((a >> 8) + a)
> & 255;" is "mod 255" then you are being misleading.
But it is. Since a cannot be > 254^2 this will faithfully reproduce the
desired result.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 00:28:11 GMT
"those who know me have no need of my name" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]...
> <T6vW6.129114$[EMAIL PROTECTED]> divulged:
>
> >In fact PHP/ASP/XML are all re-inventions of HTML+Perl. Encrypted
content
> >via SSL already exists and is used widely.
>
> tom, why do you flip out like this? taken to it's logical (idiotic)
> extreme your statement says that nobody should do anything because it's
all
> been done.
No to some extent the contrived examples end. Coding in ASM is more basic
then C, but binary is more basic then ASM, heck why use a computer since we
have neurons!
If you look at what these YAPL (Yet Another Programming Language) provide,
typically more often than not it's a self-righteous need to feel proud of
re-inventing the wheel.
For example I could justify PERL along with C since PERL is more string
oriented. [i.e data base, log files, scripts, etc]. C is by far the most
basic HLL to exist. It's versatile and not tied to one platform or program
style.
Java for example is neat, but hardly efficient and vastly non-portable.
PHP is a re-hash of Perl. The idea is to make dynamic websites, but a perl
script through CGI will provide the SAME thing.
I dunno about ASP/XML.
I mean seriously most people use Java/Javascript for annoying roll-overs and
ads. The best use of Java so far is for learning applets that demonstrate
things. So I could justify Java [not Javascript].
This is not to say all YAPLs are useless and a waste of time, but all too
often a "new buzzword" is what people are trying to maintain.
Why not just learn
Parrot/Python/Perl/Shell/C/Pascal/C++/Java/Javascript/ASP/PHP/Cobol/Modula-3
/Fortran/basic and assembler for 34 cpus?
Tom
------------------------------
From: [EMAIL PROTECTED] (Jschutkeker)
Date: 16 Jun 2001 00:42:06 GMT
Subject: Re: Bow before your new master
Think this guy should get some professional help...?
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 02:43:45 +0200
"those who know me have no need of my name" <[EMAIL PROTECTED]> a écrit dans
le message news:
[EMAIL PROTECTED]
> e.g., perl was nothing more than a few shell tools aggregated into a single
> tool, ...
that's not true. perl took a bunch of common unix ideas and
constructs used by a variety of unix tools and these were
smashed together into something that was written from scratch.
it has two and only two features:
- it can handle binary files
- it bridges the gap between a shell script and a program
it is one of the most god awful hacks on the face of the
planet. it is unreadable and the control flow constructs
are more or less random.
and this is before we even hack apart perl 5, when it went
totally out of control.
iirc:
''rn may not be faster than readnews, but it seems like it's faster''
-- larry wall
well, why didn't you just measure it?
i know i measured how long it took the source to 2.10.1.2 rn to fall
~10 metres, to the ground, when we threw the line printed source out
of a first floor window (2nd floor for the americans).
took ~3 seconds.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Fri, 15 Jun 2001 17:43:19 -0700
John Myre <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Paul Pires wrote:
> <snip>
> > Take Prozac.
> <snip>
>
> Mm.
>
> I do not interpret the anonymous post to be any kind of
> disparagement of Joe. I take it to be a plea for help:
> "what are we to believe?" It seems Joe is arguing for
> diversity in a standard, and comes up with a reason for
> ECB to be *more secure* than CBC under some conditions.
>
> It is quite reasonable for this conclusion to worry the
> folks in charge of the standard. It's certainly nothing
> I've ever seen before.
>
> (I don't agree, BTW. He shows how a certain attack fails
> when in ECB, but he doesn't show the encryption is secure.
> It's just insecure in a different way.)
>
> If I were in charge of a standard, and someone gave me
> advice, I would be a fool not to investigate both the
> advice and the credentials of the advisor.
>
> JM
I apologies if I have offended both to you and the OP.
Now that that is out of the way, I did read it differently
than you and perceived a disparaging tone that you did
not. I felt his characterization was misleading. He could
have just posted Joe's words and asked for comment
but he set it up in a biased fashion.
> presenting himself as a cryptography expert.
That wasn't clear from the referenced post.
> he offers an argument as to why ECB mode should be supported in addition
> to CBC!
Mr. Ashwood made no such recommendation.
>Should someone who supports the use of ECB mode be
> considered an expert in a forum where not everyone is knowledgeable
> about cryptography? It is very worrisome what form the standard will
> end up taking when this is what passes for expert cryptographic advice.
"passes for expert cryptographic advice." That's disparaging.
As far as the, "Take Prozac" part goes, it was working a bit
too hard at being cute. I didn't mean to suggest that he was
mentally ill, just that it was a little hysterical. Perhaps a
different pharmaceutical would have worked better.
Upon reflection, I'm in a grumpy mood and it was a cheap
shot.
Have I used up my quota yet?
Paul
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: Simple Crypto II, the public key...
Date: Sat, 16 Jun 2001 02:46:51 +0200
"Fat Phil" <[EMAIL PROTECTED]> a écrit dans le message news:
[EMAIL PROTECTED]
> Why do you permit multiplication to create an intermediate result
> greater than 254, but no other operation?
when multiplication meets modulus it is special. delaying the
modulus operation buys you a speedup.
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 02:53:15 +0200
"Paul Pires" <[EMAIL PROTECTED]> a écrit dans le message news:
yZxW6.740$[EMAIL PROTECTED]
> As far as the, "Take Prozac" part goes, it was working a bit
> too hard at being cute. I didn't mean to suggest that he was
> mentally ill, just that it was a little hysterical. Perhaps a
> different pharmaceutical would have worked better.
i suggest you read up on your psychopharmacology. i recommend
_drug treatment_ , originally edited by graham s avery.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
