Cryptography-Digest Digest #575, Volume #14 Sat, 9 Jun 01 14:13:01 EDT
Contents:
where can I find information about DES? ("doublemc")
Re: Shannon's definition of perfect secrecy (Mok-Kong Shen)
Re: where can I find information about DES? (Mok-Kong Shen)
Re: Uniciyt distance and compression for AES (SCOTT19U.ZIP_GUY)
Re: cubing modulo 2^w - 1 as a design primitive? (Mok-Kong Shen)
Re: Uniciyt distance and compression for AES ("Tom St Denis")
Re: cubing modulo 2^w - 1 as a design primitive? (Mark Wooding)
Re: Shannon's definition of perfect secrecy (SCOTT19U.ZIP_GUY)
Re: where can I find information about DES? ("Robert J. Kolker")
Re: where can I find information about DES? ("Robert J. Kolker")
Re: cubing modulo 2^w - 1 as a design primitive? ("Tom St Denis")
Re: cubing modulo 2^w - 1 as a design primitive? ("Tom St Denis")
Re: Hex notation (Paul Schlyter)
Re: Shannon's definition of perfect secrecy (John Savard)
Re: cubing modulo 2^w - 1 as a design primitive? ("Tom St Denis")
Re: Simple C crypto ("Sam Simpson")
Re: Simple C crypto ("Sam Simpson")
Re: Shannon's definition of perfect secrecy (SCOTT19U.ZIP_GUY)
Re: Simple C crypto ("Tom St Denis")
RC5 test vector ("Cristiano")
Re: RC5 test vector ("Tom St Denis")
----------------------------------------------------------------------------
From: "doublemc" <[EMAIL PROTECTED]>
Subject: where can I find information about DES?
Date: Sat, 09 Jun 2001 16:20:37 GMT
Hi everybody!.
I´m searching information about DES.
Can you help me to find it?
Thank you.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Shannon's definition of perfect secrecy
Date: Sat, 09 Jun 2001 18:27:33 +0200
Tim Tyler wrote:
>
[snip]
> Yes - he doesn't deal with the conventional OTP on finite files in the
> passage you quote.
After having followed part of this thread, I am still not
very clear about the current status of the debate over the
conventional OTP (which is the case of more practical
significance than the case of infinite stream in my humble
view). Is it correct to say that Shannon's paper doesn't
deal with the conventional OTP and hence he has not proved
the perfect security of the conventional OTP (and hence
some of the literatures seem to be a bit problematic
on the issue)? If yes, is the conventional OTP perfectly
secure or not and how to rigorously prove that in the
positive case? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: where can I find information about DES?
Date: Sat, 09 Jun 2001 18:31:27 +0200
doublemc wrote:
>
> I´m searching information about DES.
If you are not unconditionally needing the original
standard document, look it up in the commonly recommended
textbooks (Stinson, Schneier, Menezes et al., etc.) or do
a search over the internet.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Uniciyt distance and compression for AES
Date: 9 Jun 2001 16:36:08 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<hirU6.69324$[EMAIL PROTECTED]>:
>Also to drag the dead around (like he does to David Wagner) he once said
>he found a short cut attack on RC5 that would reduce the keyspace to
>nothing. I wonder what came of that? He hasn't won the RC5 64 challenge
>yet so I guess he's a BS'ing liar (as he would put it).
>
AS you can tell Tom is full of shit. When did I say something
about short cut attack on RC5 that would reduce the keyspace
to nothing. Or are you just blowing smoke out your ass as usual.
I guess I could can aruging with Tom as usual. But its really
a waste of time. You can belive his distorted lies of you wish.
I for one think the only sane thing is to put him back in my kill
file for another month. Since arguing with him is totally
unproductive.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 18:40:00 +0200
Tom St Denis wrote:
>
> "Mark Wooding" <[EMAIL PROTECTED]> wrote:
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > > It is a bijection since 3 does not divide the order for w=32 or w=64.
> >
> > It's a bijection in Z/(2^w - 1)Z. Unfortunately, we're probably
> > actually working in Z/(2^w)Z. As a result, the mapping is biased,
> > noninjective and nonsurjective. I can't see an attack against sixteen
> > rounds, but that doesn't mean there isn't one.
>
> It lacks one element (namely 2^w - 1). I don't see that as a big bias.
The set of people who feel uncomfortable with a minute
deviation from the ideal is not empty.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Date: Sat, 09 Jun 2001 16:42:30 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <hirU6.69324$[EMAIL PROTECTED]>:
>
> >Also to drag the dead around (like he does to David Wagner) he once said
> >he found a short cut attack on RC5 that would reduce the keyspace to
> >nothing. I wonder what came of that? He hasn't won the RC5 64 challenge
> >yet so I guess he's a BS'ing liar (as he would put it).
> >
>
> AS you can tell Tom is full of shit. When did I say something
> about short cut attack on RC5 that would reduce the keyspace
> to nothing. Or are you just blowing smoke out your ass as usual.
>
> I guess I could can aruging with Tom as usual. But its really
> a waste of time. You can belive his distorted lies of you wish.
> I for one think the only sane thing is to put him back in my kill
> file for another month. Since arguing with him is totally
> unproductive.
To the newbies: Note how he clipped 85% of my post and commented on one
part he could be a smart arse about.
Note how he didn't address the real issues like efficiency, or actual needs!
Tom
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: 9 Jun 2001 16:55:23 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> According to Maple, phi(2^64 - 1) == ifactor(2^64 - 2) =
> ``(2)*``(7)^2*``(73)*``(127)*``(337)*``(649657)*``(92737)
I've no idea what ``(.) or ifactor(.) mean.
Anyway, 2^{64} - 1 = 3.5.17.257.641.65537.6700417. \lambda(2^{64} - 1)
is therefore \lcm(2, 4, 16, 256, 640, 65536, 6700416) = 2^16.3.5.17449.
Which has 3 as a factor.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Shannon's definition of perfect secrecy
Date: 9 Jun 2001 16:47:20 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B224E75.758F6189@t-
online.de>:
>
>
>Tim Tyler wrote:
>>
>[snip]
>> Yes - he doesn't deal with the conventional OTP on finite files in the
>> passage you quote.
>
>After having followed part of this thread, I am still not
>very clear about the current status of the debate over the
>conventional OTP (which is the case of more practical
>significance than the case of infinite stream in my humble
>view). Is it correct to say that Shannon's paper doesn't
>deal with the conventional OTP and hence he has not proved
>the perfect security of the conventional OTP (and hence
>some of the literatures seem to be a bit problematic
>on the issue)? If yes, is the conventional OTP perfectly
>secure or not and how to rigorously prove that in the
>positive case? Thanks.
>
>M. K. Shen
>
Mok I am not sure you can follow english that is in the
style of the 40's. But if you can. Read the images from the
URL that Hopwood posted. Its quite clear possibly to even
you. That the appearently common way of using an OTP does
not contain "perfect security" for a given set of messages
of various lengths. And it should be clear that the trick
is to make any possible intercepted cipher text map back
to any possible message that was in the input set. One way
to do this. But not necessiarly the only way is to pad all
messages to same length. Then use the OTP to create ciphert
text of all the same length. This would then allow any possible
cipher text to be decoded to any possible message in the input
set. But again don't take my word. As if you needed to be
reminded of that. Please take it up on your self to read the
stuff at the URL that Hopwood posted.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: where can I find information about DES?
Date: Sat, 09 Jun 2001 13:06:32 -0400
doublemc wrote:
> Hi everybody!.
> I´m searching information about DES.
> Can you help me to find it?
Use a web browser.
Two key words, such as "encryption" & "DES"
will give you a manageable number of hits which
you can investigate at your leisure.
Web Browsers are a wonderful thing. Learn to
use them.
My favorite browser is:
www.google.com
Bob Kolker
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: where can I find information about DES?
Date: Sat, 09 Jun 2001 13:06:46 -0400
doublemc wrote:
> Hi everybody!.
> I´m searching information about DES.
> Can you help me to find it?
Use a web browser.
Two key words, such as "encryption" & "DES"
will give you a manageable number of hits which
you can investigate at your leisure.
Web Browsers are a wonderful thing. Learn to
use them.
My favorite browser is:
www.google.com
Bob Kolker
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 17:09:56 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
> >
> > "Mark Wooding" <[EMAIL PROTECTED]> wrote:
> > > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > >
> > > > It is a bijection since 3 does not divide the order for w=32 or
w=64.
> > >
> > > It's a bijection in Z/(2^w - 1)Z. Unfortunately, we're probably
> > > actually working in Z/(2^w)Z. As a result, the mapping is biased,
> > > noninjective and nonsurjective. I can't see an attack against sixteen
> > > rounds, but that doesn't mean there isn't one.
> >
> > It lacks one element (namely 2^w - 1). I don't see that as a big bias.
>
> The set of people who feel uncomfortable with a minute
> deviation from the ideal is not empty.
You're being vastly ignorant. A block cipher is "minutely deviated from
ideal".
Would you now not use AES for this reason? Or are you a hypocrit?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 17:11:05 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > According to Maple, phi(2^64 - 1) == ifactor(2^64 - 2) =
> > ``(2)*``(7)^2*``(73)*``(127)*``(337)*``(649657)*``(92737)
>
> I've no idea what ``(.) or ifactor(.) mean.
>
> Anyway, 2^{64} - 1 = 3.5.17.257.641.65537.6700417. \lambda(2^{64} - 1)
> is therefore \lcm(2, 4, 16, 256, 640, 65536, 6700416) = 2^16.3.5.17449.
> Which has 3 as a factor.
I thought if p is your modulus, the order is at most a multiple of p-1?
How do you explain it being a bijection for p=255?
Tom
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Hex notation
Date: 9 Jun 2001 18:16:12 +0200
In article <[EMAIL PROTECTED]>,
Mathew Hendry <[EMAIL PROTECTED]> wrote:
> On Sat, 09 Jun 2001 11:20:59 GMT, "Adam O'Brien" <[EMAIL PROTECTED]>
> wrote:
>
>> Sorry to ask a very basic question but when referring to a hexadecimal
>> number what does 0xAB mean?
>
> Ah, an easy weekend question. :)
>
> '0x' is a prefix used in C and other languages to indicate a hex constant.
> (Other common forms would be '$AB' and 'ABh').
The form 'ABh' is usually written with an extra leading zero though, i.e.
as '0ABh', to avoid having it confused with the synbolic name 'ABh'. Most
langauges have the convention that a numeric constant starts with a decimal
digit while a synbolic name starts with a letter.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Shannon's definition of perfect secrecy
Date: Sat, 09 Jun 2001 17:23:50 GMT
On Sat, 09 Jun 2001 18:27:33 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>If yes, is the conventional OTP perfectly
>secure or not and how to rigorously prove that in the
>positive case?
If you are sending possible messages of varying lengths, then you have
to account for that to really get perfect security. The length of a
message _is_ information about the message; if the compressed form of
'Night calm, nothing to report' is exactly 17 bytes long, when you get
around to sending a message longer than 17 bytes, you have leaked
information.
If you have a known maximum message length, you obtain perfect
security without wasting precious key bits by:
- adding an indicator of message length to your messages before
encrypting,
- after encrypting the message, generate random bits, and pad the
message to the maximum length with them.
To prove that is perfectly secure follows trivially from the fact that
the infinite case of the Vernam is secure for any portion of the data
transmitted.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: cubing modulo 2^w - 1 as a design primitive?
Date: Sat, 09 Jun 2001 17:35:36 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:JMsU6.70742$[EMAIL PROTECTED]...
>
> "Mark Wooding" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > > According to Maple, phi(2^64 - 1) == ifactor(2^64 - 2) =
> > > ``(2)*``(7)^2*``(73)*``(127)*``(337)*``(649657)*``(92737)
> >
> > I've no idea what ``(.) or ifactor(.) mean.
> >
> > Anyway, 2^{64} - 1 = 3.5.17.257.641.65537.6700417. \lambda(2^{64} - 1)
> > is therefore \lcm(2, 4, 16, 256, 640, 65536, 6700416) = 2^16.3.5.17449.
> > Which has 3 as a factor.
>
> I thought if p is your modulus, the order is at most a multiple of p-1?
>
> How do you explain it being a bijection for p=255?
Arrg... I'm a retard.... it's
phi(2^64 - 1) = lcm(2-1,7-1,73-1,126-1,337-1,...)
Right?
ARrg... sorry guys, I didn't give this alot of thought :-(
Tom
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 18:31:18 +0100
"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:6OUT6.19530$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:xITT6.52725$[EMAIL PROTECTED]...
> >
> > > The requirement is for text comments (for example) to be written to a
> file
> > > along with data. We simply don't want people to get into the file to
> read
> > > and/or alter the text. We're not talking about professional hackers or
> the
> > > NSA, just (say) lab technicians who use the equipment. Detecting
> > alteration
> > > of the text is something else.
>
> > > So, no freeware solution to such a simple problem?
>
> > There are tons of public domain crypto tools (tools = algorithms).
> Whether
> > your a competent enough cryptographer to use them is another question.
>
> I don't have to be a competent crypographer if someone else has done the
> work.
Possibly not for your intended use.
<SNIP>
> > If you application is based on secrets like passwords or what have not
> just
> > use a cipher like Blowfish in CTR mode to encode the files. Alterations
> > will show up in the plaintext but if you need more assurance append a
hash
> > of the pre-image to the plaintext. That should stop all attacks on "the
> > math". At that point it's upto physical and password security.
>
> Done a search on Blowfish, but could not find any code.
Lol. http://www.google.com/search?sourceid=navclient&q=blowfish+source
gives dozens of hits - the first one would probably do!!!!!!!!!
> If its more than
> about 100 lines of C then I'm not interested. I just need a key of length
N,
> and two functions
You won't be interested then, Blowfish is quite big because of the static
data.
> #include "encryption.h"
> CString Encrypt( Cstring )
> CString Decrypt( Cstring )
>
> something as simple as that to drop into existing code.
Try TEA instead. Since you'll probably claim to be able to not find it
using a search engine ;) use the following link:
http://vader.brad.ac.uk/tea/source.shtml from
http://www.google.com/search?hl=en&lr=&safe=off&q=TEA+source
Regards,
Sam Simpson
http://www.scramdisk.clara.net/
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 18:33:03 +0100
Having previously seen his requirements, I think TEA will be more than
sufficient!
--
Sam Simpson
http://www.scramdisk.clara.net/
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:s52U6.57511$[EMAIL PROTECTED]...
>
> "Samuel Paik" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Dirk Bruere wrote:
> > > I'm looking for a simple algorithm to code text that is pretty
difficult
> to
> > > break for an amateur without custom s/w.
> > > I had thought of something like (say) a 16 bit number, to be XORed
with
> > > chars, and then this shifted each time it is re-used.
> >
> > Well, that's awful. If you want a short and simple ciphers yet strong
> > ciphers, you might want to check RC4, RC5, RC6, or TEA.
> >
> > TEA:
> > http://vader.brad.ac.uk/tea/tea.shtml
> > http://vader.brad.ac.uk/tea/source.shtml#ansi
>
> No offense but I don't count any of those as "strong". RC5 for example I
> would only trust with 20 rounds or more. RC6 with 28 or more. RC4 is
> showing signs of weakness. TEA is original but not entirely a good
design.
>
> Tom
>
>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Shannon's definition of perfect secrecy
Date: 9 Jun 2001 17:30:48 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Sat, 09 Jun 2001 18:27:33 +0200, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote, in part:
>
>>If yes, is the conventional OTP perfectly
>>secure or not and how to rigorously prove that in the
>>positive case?
>
>If you are sending possible messages of varying lengths, then you have
>to account for that to really get perfect security. The length of a
>message _is_ information about the message; if the compressed form of
>'Night calm, nothing to report' is exactly 17 bytes long, when you get
>around to sending a message longer than 17 bytes, you have leaked
>information.
>
>If you have a known maximum message length, you obtain perfect
>security without wasting precious key bits by:
>
>- adding an indicator of message length to your messages before
>encrypting,
>
>- after encrypting the message, generate random bits, and pad the
>message to the maximum length with them.
>
>To prove that is perfectly secure follows trivially from the fact that
>the infinite case of the Vernam is secure for any portion of the data
>transmitted.
>
>John Savard
John seems to be correct on this one. Thanks maybe you can
help the others who seem lost on the defination wake up.
Because Tim and I have talked for ever and idoits like Tommy
seem in capable of realizing the obvious.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Sat, 09 Jun 2001 17:46:08 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:n5tU6.30707$[EMAIL PROTECTED]...
> Having previously seen his requirements, I think TEA will be more than
> sufficient!
Xoring with 0xAA will fulfill his needs.
Tom
>
> --
> Sam Simpson
> http://www.scramdisk.clara.net/
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:s52U6.57511$[EMAIL PROTECTED]...
> >
> > "Samuel Paik" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Dirk Bruere wrote:
> > > > I'm looking for a simple algorithm to code text that is pretty
> difficult
> > to
> > > > break for an amateur without custom s/w.
> > > > I had thought of something like (say) a 16 bit number, to be XORed
> with
> > > > chars, and then this shifted each time it is re-used.
> > >
> > > Well, that's awful. If you want a short and simple ciphers yet strong
> > > ciphers, you might want to check RC4, RC5, RC6, or TEA.
> > >
> > > TEA:
> > > http://vader.brad.ac.uk/tea/tea.shtml
> > > http://vader.brad.ac.uk/tea/source.shtml#ansi
> >
> > No offense but I don't count any of those as "strong". RC5 for example
I
> > would only trust with 20 rounds or more. RC6 with 28 or more. RC4 is
> > showing signs of weakness. TEA is original but not entirely a good
> design.
> >
> > Tom
> >
> >
>
>
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: RC5 test vector
Date: Sat, 9 Jun 2001 19:34:39 +0200
I'm playing with RC5 and I found this test vector:
RC5-32/12/16
key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
plaintext 00000000 00000000
ciphertext EEDBA521 6D8F4B15
My implementation (in a little endian machine) give ciphertext D1B284F4
12006D6E.
Which result is it correct?
Thanks
Cristiano
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RC5 test vector
Date: Sat, 09 Jun 2001 17:50:46 GMT
"Cristiano" <[EMAIL PROTECTED]> wrote in message
news:9ftmpl$36g$[EMAIL PROTECTED]...
> I'm playing with RC5 and I found this test vector:
> RC5-32/12/16
> key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> plaintext 00000000 00000000
> ciphertext EEDBA521 6D8F4B15
>
> My implementation (in a little endian machine) give ciphertext D1B284F4
> 12006D6E.
> Which result is it correct?
According to the RC5 paper the correct ciphertext is 21A5DBEE 154B8F6D
May I suggest you examin Rivest's paper? It has C code as well!
Tom
------------------------------
** 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
******************************
