Cryptography-Digest Digest #991, Volume #11 Fri, 9 Jun 00 18:13:01 EDT
Contents:
Re: Cryptographic voting (Virgil)
Re: XTR independent benchmarks (d g)
Re: Random IV Generation (Terry Ritter)
Re: Updated: Evidence Eliminator Dis-Information Center (Includes info on false SPAM
accusations) (Larry W4CSC)
Re: Random IV Generation (Terry Ritter)
Re: My lastest paper on Block Ciphers (Rex Stewart)
Re: My lastest paper on Block Ciphers ([EMAIL PROTECTED])
Re: Observer 4/6/2000: "Your privacy ends here" (U Sewell-Detritus)
Re: randomness tests (Albert P. Belle Isle)
Re: Encoding 56 bit data ---HELP--- ([EMAIL PROTECTED])
Re: encoding of passwords ([EMAIL PROTECTED])
Re: Encoding 56 bit data ---HELP--- (tomstd)
Re: My lastest paper on Block Ciphers (tomstd)
Re: Arithmetic Coding (SCOTT19U.ZIP_GUY)
Re: Arithmetic Coding (tomstd)
Re: help for rc5 cryptanalysis (Anton Stiglic)
----------------------------------------------------------------------------
From: Virgil <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Fri, 09 Jun 2000 15:00:30 -0600
In article <8hq5cu$ceg$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]>
wrote:
>>
>> Their leader seems to have given up the role of Moses to take up the
>> role of Julius Caesar.
>
>If the gunners are the government, then I would think that a better
>description is that their leader seems to have given up the role of
>Washington for Hitler or Stalin.
That should be your first clue that the "gunners" in the U.S.A. are
those who put the right to own weapons of distruction before all other
rights, even the right to life.
--
Virgil
[EMAIL PROTECTED]
------------------------------
From: d g <[EMAIL PROTECTED]>
Subject: Re: XTR independent benchmarks
Date: 09 Jun 2000 14:26:56 -0700
"Paulo S. L. M. Barreto" <[EMAIL PROTECTED]> writes:
> Roger Schlafly wrote:
> >
> > Wei Dai wrote:
> > > That structure is already present in GF(p^6) and is not imposed by XTR.
> > > The reason it can represent a field element by only 2 subfield elements
> > > is because it works in a multiplicative subgroup of size p^2-p+1, which
> > > every GF(p^6) has. The question is whether discrete log in GF(p^6) is
> > > really as difficult as in a prime field (when the two fields have about
> > > the same order)? I think there is definitely room for doubt.
> >
> > There is also the possibility that discrete logs in the subgroup
> > of GF(p^6) is much easier that in the entire GF(p^6).
>
> Answer to Wei Dai:
>
> I can't see any fundamental difference between working in (subgroups of)
> GF(p^6) and GF(2^m), where the size of p^6 is roughly equal to that of
> 2^m. Please correct me if I am wrong: the best attack known against DL
> in GF(2^m) has the same complexity as the best attack against DL in
> GF(r) where r ~ p^6 except for the constant factor in the exponent.
While it is not directly relevant, there have been attacks on
cryptosystems using prime power fields that point out that at least
some systems over prime power fields may be weaker, especially if the
exponent is composite. For instance, consider Vaudenay's attack on
the Chor/Rivest cryptosystem [1] and the Gaudry/Hess/Smart attack [2]
on the ECDLOG problem over a field of characteristic 2 and composite
degree over F_2.
Notably, Vaudenay's attack does not generalize to Lenstra's powerline
system which uses prime exponents. Similarly, the GHS attack does not
generalize to ECs on fields of prime degree over F_2.
For the DLOG case, Coppersmith's DLOG algorithm for F_{2^m} was known
long before the number field sieve was applied to DLOG over F_p.
Regards,
==
Dipankar
[EMAIL PROTECTED]
[1] http://www.dmi.ens.fr/~vaudenay/pub.html#Vau98h
[2] http://www.hpl.hp.com/techreports/2000/HPL-2000-10.html
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Random IV Generation
Date: Fri, 09 Jun 2000 21:14:05 GMT
On 9 Jun 2000 11:00:43 -0700, in
<8hrbcb$2ip$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> There *is* a reason to keep an IV secret: With CBC an exposed IV
>> allows an opponent to change the recovered plaintext for the first
>> block at will.
>
>I suppose that's a plausible reason, but it's much better
>to just MAC everything (the IV and the ciphertext), so I'm
>not sure it's a very *good* reason.
But it *is* "very *good*" to know that the problem exists and then to
handle it in some way; as opposed, say, to not knowing.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Larry W4CSC)
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Updated: Evidence Eliminator Dis-Information Center (Includes info on
false SPAM accusations)
Date: Fri, 09 Jun 2000 21:19:34 GMT
EE, what does the Active X in this webpage do? What's it run on
systems where noone is looking??
Larry...just curious....and a little paranoid of Active X and scripts.
On Fri, 09 Jun 2000 20:45:50 +0100, EE Support
<[EMAIL PROTECTED]> wrote:
>Hi all,
>
>Our news input feed at evidence-eliminator.com has been out for a week
>due to a dud satellite. We haven't been able to correct this weeks
>dis-information posts against our software directly, but:
>
>We have seen some posts coming on deja and remarq including false
>"spam" accusations, etc, etc.
>
>We don't "SPAM" but we strongly believe in our right to dispute and
>counter the hundreds of "SPAMMING" false messages posted to security
>newsgroups about our software. It has become commonly said by posters
>to these newsgroups that the ones posting the "anti-Evidence
>Eliminator" messages in all their disguises, are wearing badges and
>intend to compromise your privacy and security, by stopping you
>downloading a free Evidence Eliminator.
>
>This week's false messages appear to span several newsgroups listed in
>the header of this msg and this post is to counter those false rumors.
>
>Our updated Dis-Information centre URL is:
>
>http://www.evidence-eliminator.com/dis-information.shtml
>
>Hope this helps,
>--
>Regards,
>EE Support
>[EMAIL PROTECTED] (remove NO_SP_AM for e-mail)
>http://www.evidence-eliminator.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Random IV Generation
Date: Fri, 09 Jun 2000 21:24:46 GMT
On 9 Jun 2000 12:05:06 -0700, in
<8hrf52$2ne$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> wrote:
>> "David A. Wagner" wrote:
>> > Use random, unpredictable IV's. Non-random IV's are risky.
>>
>> Would it be sufficient to use the encryption of the counter
>> as the IV?
>
>I don't know of any problems with it. It's probably ok, but I'd feel
>much better about it if I had a proof.
I have many times expressed anxiety about using so-called "counter
mode." It is easy to imagine that it *must* be secure, if only we
assume the cipher is secure, and why would we use any other kind? But
we do not in fact know that any cipher is secure, and the counting
plaintext is one of the worst possible tests: The lsb always changes,
the next higher bit changes half as often and only when the lsb goes
to 0, and so on. These plaintext signals seem almost ideal for
exposing bit correlations, should any exist. And it seems entirely
reasonable that a real block cipher might have problems with diffusion
from signals which are entirely grouped close to one edge.
Counter mode with a binary counter seems to be just asking for
trouble. One alternative would be to use a polynomial counter, to get
about half the "counting" bits to change on each count, which should
be a lot less risky.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: My lastest paper on Block Ciphers
Date: Fri, 09 Jun 2000 21:23:24 GMT
You seem to have gotten a fair amount of discussion about
the format of the paper. I think you were wanting some
feedback on the content. I don't know how many technical
papers you have written so let me cover several bases.
The paper, as written appears to fall victim to the same
problem I had with most of my earlier writings on computer
and communications security. In short, it is only meaningful
to those who already have a background in the subject matter.
On the other hand, I suppose they would be able to understand
most of it if they had a really good background in statistics
and some experience in computers. Mostly what I am trying to
say is your audience is fairly narrow.
In truth, I don't see how you could expect to give proper
treatment to more than a couple of attacks and countermeasures
in a paper only a dozen or so pages long.
That said, I can see three very good reasons for
you to have written and published it.
It allows you to "sum up" the various modes of attack and methods
of resisting those attacks - and since it is in writing it forces
you to do it with a fair amount of precision. This prevents you
from bluffing yourself about what you do and don't know about one
form of attack or another (in a different way, successfully
implementing the attack forces that same clarity on you).
For the above reason, this is also good as a supplement to
a resume. While it may be too early for you to be mailing
out resumes to prospective employers, it is never too early
to start thinking about it (and one offer from RSA doesn't
make this moot, you may decide instead to work for someone
else entirely).
Your paper helped me review and verify my understanding of those
attacks, and indeed I was completely out in left field about a
couple of them (I'm in computer security, so I only require
a rudimentary knowledge of these subjects). I guess that makes
me one of the primary people who this paper is good for :-)
In summery, thanks for writing it.
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> tomstd wrote:
> >
> > I have just finished the Draft of my latest paper. It's called
> >
> > "On Cryptographically Strong F Functions"
> >
> > And is available (sorry) only in Word97 format at
>
> You're going to find it much easier to get people interested
> in looking at things if you post PDF files. Or even PS files.
> PDF files you can do easily, though it may cost you a small
> sum to get the needed software. (Or perhaps not anymore?).
> PS you can do with Word at no charge, just install the PostScript
> printer driver.
>
> paul
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My lastest paper on Block Ciphers
Date: Fri, 09 Jun 2000 21:23:02 GMT
In article <8hrevn$cjt$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> Hi, I know this is a cryptography forum, but i've been looking
> for some post-script viewers for windows.
Simon, a possible place to start is miktex.de.
:)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (U Sewell-Detritus)
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: 9 Jun 2000 21:35:54 GMT
me <[EMAIL PROTECTED]> wrote:
[.....]
>
>http://www.udhr50.org/UDHR/default.htm
>
>Universal Declaration of Human Rights
>...
>Article 11
>
>(1) Everyone charged with a penal offence has the right to be presumed
>innocent until proved guilty according to law in a public trial at which
>he has had all the guarantees necessary for his defence.
*IANAL*
Doesn't look like the ECHR is a good place for the UK to test the water
on the legality of RIP.
According to David Pannick QC, writing in The Times law recently,
The European Convention has little jurisprudence when it comes to
"reverse legal burden of proof." This is forcing judges to look beyond
their jurisdictions for guidance eg Canada, and Australia.
Curiously, whist Pannick, waving one flag, argues in his column that
Reverse Legal Burden of Proof is a bad thing, particularly so
for Sexual Offences (another of Straw's proposals), waving another flag,
Pannick has also played a part in the domestic erosion of the
natural interpretion of Article 6.2 - "innocent until proved guilty" -
see R v Kebilene in which Pannick, then counsel for the DPP argued that
section 16A of Prevention of Terrorism (Temporary Provisions) Act 1989
did not contravene the Convention.
my layman's interpretation of 16A is that "unless you can prove
otherwise, possession of articles and items of information innocent
in themselves but capable of forming part of the paraphernalia or
operational intelligence of terrorism", you shall be guilty of an
offence.
Hardly "innocent until proved guilty"
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: randomness tests
Date: Fri, 09 Jun 2000 17:35:39 -0400
Reply-To: [EMAIL PROTECTED]
On Fri, 09 Jun 2000 14:28:17 GMT, [EMAIL PROTECTED] wrote:
>
>
>hello all,
>
>in order to check randomness of my random number(bit) generator
>i use
>1. ent package
>2. diehard package
>
>i read about FIPS PUB 140-1, any implementation around?
>
>can anyone suggest me any tests?
>
>thanks for any help ...
>
>e-mail : [EMAIL PROTECTED]
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
The Monobit Test, the Poker Test, the Runs Test and the Long Runs Test
are quite straightforward and specified in section 4.11 of FIPS 140-1,
a copy of which is available in our cryptographic standards library at
http://www.CerberusSystems.com/INFOSEC/stds/fip140-1.htm#sec4.11
among other places.
In addition to ensuring that your PRNG passes these Statistical
Random Number Generator Tests, it's very important that you include
the real-time Continuous Random Number Generator Test in whatever
cryptosystem implementation uses your generator's output.
Validating the statistics of your algorithm is necessary but not
sufficient for trusting the resulting keystream.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encoding 56 bit data ---HELP---
Date: Fri, 09 Jun 2000 21:29:55 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> In article <8hr2kq$2ii$[EMAIL PROTECTED]>, sarnold_intertrust@my-
> deja.com wrote:
> >This brings to mind a question I have had for some time now; is
> there
> >any point in using a key larger than the data to be encrypted?
> If there
> >is danger in brute-force-searching the key, why not brute-force
> search
> >the plain-text instead? :)
>
> Did you think that through at all? I hope not.
The bit about "brute-force plain-text" was very much tongue-in-cheek,
but the question -- using keys larger than the data -- still makes me
wonder. :)
> Also brute forcing a key is more practical then the plaintext
> simply because I don't want to give you *any* ciphertext at all,
> why would I give 2^64 or 2^128 blocks?
That is a *lot* of blocks. :)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: encoding of passwords
Date: Fri, 09 Jun 2000 21:25:44 GMT
In article <e7WhrFk0$GA.297@net025s>,
"Wouter" <[EMAIL PROTECTED]> wrote:
> I want to know how the encoding of password occurs in Unix / Linux
> -systems (the /etc/passwd file).
Wouter, it depends on the distribution. Some distributions (Debian at
least, and FreeBSD as well afaik) don't use DES, but rather MD5. Others
(OpenBSD) use Blowfish with a configurable number of applications.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Encoding 56 bit data ---HELP---
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 14:40:22 -0700
In article <8hrnjs$jjt$[EMAIL PROTECTED]>, sarnold_intertrust@my-
deja.com wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> In article <8hr2kq$2ii$[EMAIL PROTECTED]>,
sarnold_intertrust@my-
>> deja.com wrote:
>
>> >This brings to mind a question I have had for some time now;
is
>> there
>> >any point in using a key larger than the data to be
encrypted?
>> If there
>> >is danger in brute-force-searching the key, why not brute-
force
>> search
>> >the plain-text instead? :)
>>
>> Did you think that through at all? I hope not.
>
>The bit about "brute-force plain-text" was very much tongue-in-
cheek,
>but the question -- using keys larger than the data -- still
makes me
>wonder. :)
It shouldn't. There are (2^64)! possible ways to permute 64-bit
blocks... that is way more then 2^64, 2^128 or even 2^256...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: My lastest paper on Block Ciphers
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 14:45:54 -0700
In article <8hrn7n$j8c$[EMAIL PROTECTED]>, Rex Stewart
<[EMAIL PROTECTED]> wrote:
>You seem to have gotten a fair amount of discussion about
>the format of the paper. I think you were wanting some
>feedback on the content. I don't know how many technical
>papers you have written so let me cover several bases.
>
>The paper, as written appears to fall victim to the same
>problem I had with most of my earlier writings on computer
>and communications security. In short, it is only meaningful
>to those who already have a background in the subject matter.
>On the other hand, I suppose they would be able to understand
>most of it if they had a really good background in statistics
>and some experience in computers. Mostly what I am trying to
>say is your audience is fairly narrow.
Well it's intended for beginners (i,.e from a beginner for
beginners) so I will try to add more explanations in the
revisions. If you notice anything I should document please let
me know.
>In truth, I don't see how you could expect to give proper
>treatment to more than a couple of attacks and countermeasures
>in a paper only a dozen or so pages long.
Well under 50 pages is what I want. It's suppose to be an
introductory paper for people wishing to develop their own block
ciphers. It's also a good way to review all the stuff I have
read over the past year.
>That said, I can see three very good reasons for
>you to have written and published it.
>
>It allows you to "sum up" the various modes of attack and
methods
>of resisting those attacks - and since it is in writing it
forces
>you to do it with a fair amount of precision. This prevents
you
>from bluffing yourself about what you do and don't know about
one
>form of attack or another (in a different way, successfully
>implementing the attack forces that same clarity on you).
Well there are alot of errors in the draft as it stands right
now. Matthew Fisher pointed out my GOST differential can only
be used in three rounds, so I made a big mistake there. Also my
summary of 'non-linear' transforms is very incomplete. I will
be working on that section quite a bit.
> For the above reason, this is also good as a supplement to
>a resume. While it may be too early for you to be mailing
>out resumes to prospective employers, it is never too early
>to start thinking about it (and one offer from RSA doesn't
>make this moot, you may decide instead to work for someone
>else entirely).
Well of course I would love to have this help me get a job, but
that's not why I wrote it.
>Your paper helped me review and verify my understanding of those
>attacks, and indeed I was completely out in left field about a
>couple of them (I'm in computer security, so I only require
>a rudimentary knowledge of these subjects). I guess that makes
>me one of the primary people who this paper is good for :-)
>
>In summery, thanks for writing it.
>
Your welcome. Please keep in mind it's a work-in-progress. I
hope to have finished it by the end of June at the latest (I
have exams next week...arrg). So it won't be a never ending
story/.... :)
It was fun to write, and will be interesting to fix up. I hope
it can help others as well (when it's done).
Thanks for reading it,
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Arithmetic Coding
Date: 9 Jun 2000 21:43:41 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>tomstd <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>:>[...] matt's site that has the best info on useful with source code
>:>adaptive unadulterated arithmetic coding. [...]
>
>: To the best of my knowledge no arithmetic coder adds anything
>: that doesn't need to be there. So your logic is flawed my friend.
>
>What if the arithmetic stream does not terminate on a byte boundary?
>
Tim the converting of a stream of bits that is not constrained
to byte boundaries is not that hard of problem. You can find programs
to handle that at Matts site or mine. In Matt's case he assumes a infinte
string of zero bits at the end. I am not sure why you are asking this
question. Unless your trying to make little Tommy who seems to
lack any sense of knowledge about compression or encription except
what he can parrot from the phony crypto gods.
>Think about it - an arithmetic coding stream is pretty good - but it
>is only rarely as perfect as you will find at:
>
> http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
as far as the tests I ran of matts stie listed above it is
one of the few unadulterated arithmetic compression methods
in that no information is added as in 99.9% of other arithmetic
methods out there. But tommy is to blind to comprehend something
as obvious as that so why mess with anwsering him since he is
not compabile of understanding simple facts.
------------------------------
Subject: Re: Arithmetic Coding
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 09 Jun 2000 15:02:31 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
>>tomstd <[EMAIL PROTECTED]> wrote:
>>: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>>
>>:>[...] matt's site that has the best info on useful with
source code
>>:>adaptive unadulterated arithmetic coding. [...]
>>
>>: To the best of my knowledge no arithmetic coder adds anything
>>: that doesn't need to be there. So your logic is flawed my
friend.
>>
>>What if the arithmetic stream does not terminate on a byte
boundary?
>>
>
> Tim the converting of a stream of bits that is not
constrained
>to byte boundaries is not that hard of problem. You can find
programs
>to handle that at Matts site or mine. In Matt's case he assumes
a infinte
>string of zero bits at the end. I am not sure why you are
asking this
>question. Unless your trying to make little Tommy who seems to
>lack any sense of knowledge about compression or encription
except
>what he can parrot from the phony crypto gods.
>
>>Think about it - an arithmetic coding stream is pretty good -
but it
>>is only rarely as perfect as you will find at:
>>
>> http://www3.sympatico.ca/mtimmerm/biacode/biacode.html
>
> as far as the tests I ran of matts stie listed above it is
>one of the few unadulterated arithmetic compression methods
>in that no information is added as in 99.9% of other arithmetic
>methods out there. But tommy is to blind to comprehend something
>as obvious as that so why mess with anwsering him since he is
>not compabile of understanding simple facts.
Please enlighten me as to what "information" programs like pkzip
add to the compressed data stream that aid's in cryptanalysis?
>From what I can see, yes in LZ77 out there are "invalid" output
words, but similar to the case of ASCII, so what is your point?
LZ77 compresses much better then Huffman coding for the most
part so except for the initial blocks of text, most of the lz77
stream has more information per bit then Huffman could possibly
have. This is simple to prove too. Let's assume you are using
a lzss coder with a 15 bit index, and 9 bit length (24 bit
words). We can theoretically pack 512 bytes per 3 bytes or a
ratio of 170:1. Now look at huffman. Each input byte can be
packed into as little as a single bit... this is only 8:1.
So at it's best huffman is 21 times less efficient then lzss at
it's best. Of course we have been through this before... So
please enlighten me.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: help for rc5 cryptanalysis
Date: Fri, 09 Jun 2000 18:11:17 -0400
Stanley wrote:
>
> Hi
> I know there are many experts in this group. Could anyone help me out on
> cryptanalysis of rc5, with just 8 rounds without any rotations? A hint of
> how to break it will be great. Thanks in advance.
>
> Stanley
This looks very similar to Schneier's first question in "A self-study
course in block-cipher cryptanalysis" ;) It's nice to see all does
answers....
Anton
------------------------------
** 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
******************************
