Cryptography-Digest Digest #449, Volume #13 Wed, 10 Jan 01 08:13:01 EST
Contents:
Re: secure RNG (Safe)
Re: Crypto book with mathematical explanations? ("harry")
Re: Twofish for dummies ("kihdip")
Re: Idiots guide to Montgomery multiplication ([EMAIL PROTECTED])
Re: Idiots guide to Montgomery multiplication ([EMAIL PROTECTED])
Re: Bluetooth security? ("kihdip")
Re: Q: Recommended reading about digital watermarking (math-oriented) (Stefan
Katzenbeisser)
PKI Bibliography (Detlef =?iso-8859-1?Q?H=FChnlein?=)
Re: Linear analysis (Tom St Denis)
Re: secure DOS files (Tom St Denis)
Re: Bluetooth security? (Markku-Juhani Saarinen)
Crypto Conferences ([EMAIL PROTECTED])
Re: Bluetooth security? ("Ingmar Grahn")
Re: Bluetooth security? (Mok-Kong Shen)
Re: Bluetooth security? ("Ingmar Grahn")
Another Enigma Emulator ([EMAIL PROTECTED])
Re: Crypto Conferences (Pascal Junod)
Hash/Message digest vs Signature vs MAC? ("Ingmar Grahn")
Re: Differential Analysis (Tom St Denis)
Re: Hash/Message digest vs Signature vs MAC? ("kihdip")
Re: Bluetooth security? ("kihdip")
DES validation ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Safe)
Subject: Re: secure RNG
Date: Wed, 10 Jan 2001 06:54:14 GMT
Thank you very little, you pedantic fuck.
Three fairly reasonable diverse answers that actually try to further
the art, and then there's yours: vain and flaccid
I think a lot of us picture you typing your vapid replies with one
hand, the other holding a hand mirror for you to admire yourself while
you wank away.
God forbid you should actually be just helpful. Make sure we can see
the disdain, otherwise it wouldn't be you.
You're a legend in your own mind, which truly dinishes the few skills
you actually have and could lend to some who seek the truth...
And you should, because when you go mano-a-mano with anyone who has
skills, you get your doors blown off every time. You could use the
brownie points, bitch.
On Wed, 10 Jan 2001 01:04:27 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>> snip! because it really doen't matter, does it, Tom?
>
>What is your definition of good? Compared to what tests? What speeds? What
>hardware?
>
>Often source code plays NOTHING todo with the quality of the prng. I.e take
>the best implementation of Yarrow in a static shell (perhaps a AVR with no
>I/O pins) obviously it can't work!
>
>Tom
>
>
>Sent via Deja.com
>http://www.deja.com/
------------------------------
From: "harry" <[EMAIL PROTECTED]>
Subject: Re: Crypto book with mathematical explanations?
Date: Wed, 10 Jan 2001 16:01:30 +0900
I recommend 'An INTRODUCTION to CRYPTOGRAPHY' of
RICHARD A. MOLLIN who is a professor at University of Calary in Canada
and majored at Mathematics.
That book was published at CHAPMAN & HALL/CRC press in last year.
So if you want background of Math. it will help to you.
Harry...
"M.S. Bob" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ingmar Grahn wrote:
> >
> > I'm looking for a book like "Applied Cryptography" by Bruce Schneier -
> > however I want one that goes into a bit more detail in explaining the
> > mathematical background, and possibly also one that covers the most
modern
> > algorithms too (since Schneier's book is a couple of years old). Any
ideas
> > of what might be a suitable book for me?
>
> If you want to concentrate on understanding the mathematics of the
> algorithms, and analysis I would recommend you consider these one of two
> books first off.
>
> Cryptography: Theory and Practice by Douglas Stinson
> CRC Press; ISBN: 0849385210
> <http://www.cacr.math.uwaterloo.ca/~dstinson/CTAP.html>
> For full table of contents, and more details
>
> 1.Classical Cryptography
> 2.Shannon's Theory
> 3.The Data Encryption Standard
> 4.The RSA System and Factoring
> 5.Other Public-key Cryptosystems
> 6.Signature Schemes
> 7.Hash Functions
> 8.Key Distribution and Key Agreement
> 9.Identification Schemes
> 10.Authentication Codes
> 11.Secret Sharing Schemes
> 12.Pseudo-random Number Generation
> 13.Zero-knowledge Proofs
>
> More theory then practice.
> According to Amazon.com, there is suppose to be a new edition in June
> 2001.
>
> A Course in Number Theory and Cryptography by Neil Koblitz
> Springer Verlag; ISBN: 0387942939
>
> Table of Contents
> 1: Some Topics in Elementary Number Theory
> 2: Finite Fields and Quadratic Residues
> 3: Cryptography
> 4: Public Key
> 5: Primality and Factoring
> 6: Elliptic Curves
>
> Lots of number theory, nothing about block ciphers like DES and AES.
>
> These books do not back off from the math required, so don't expect to
> read these a chapter in one sitting, with ease.
>
> Unfortunately they do not add to Applied Cryptography as far as being
> up-to-date, they are textbooks aimed at giving a firm understanding with
> a lots of math content.
>
> If you want more of a reference, which is slightly (1-2? years) more
> up-to-date, but is not designed to be a textbook, but a reference. The
> web site includes downloadable PDFs of all the chapters.
>
> Handbook of Applied Cryptography by by A. Menezes, P. Van Oorschot,
> S. Vanstone
> CRC Press ISBN: 084938523
> <http://www.cacr.math.uwaterloo.ca/hac/>
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Twofish for dummies
Date: Wed, 10 Jan 2001 09:50:38 +0100
Try the C reference code at Counterpane.
Kim
"Robert Larsen" <[EMAIL PROTECTED]> wrote in message
news:msM66.204$[EMAIL PROTECTED]...
> Hi all
>
> I am new to cryptography and only a decent C++ programmer.
> I have read Mr. Schneiers book about the Twofish algorithm and thought I
> understood the key schedule (I haven't tried the encryption algorithm
yet),
> so I implemented it. The problem is, that given the test vectors my code
> produces a wrong extended key. I tried reading the code by the designers
but
> none of the code seemed familiar to me even after knowing the design.
> Does anybody have an easy to understand implementation of the algorithm
> (preferably in C/C++ or Java) they are willing to share ?
>
> Thanks in advance
> Robert Larsen
> [EMAIL PROTECTED]
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Idiots guide to Montgomery multiplication
Date: Wed, 10 Jan 2001 08:45:20 GMT
Thanks everyone I'll give all your suggestions a go
Jonathan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Idiots guide to Montgomery multiplication
Date: Wed, 10 Jan 2001 08:45:21 GMT
Thanks everyone I'll give all your suggestions a go
Jonathan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 10:13:05 +0100
Bruce Schneier wrote this in his CRYPTO-GRAM newsletter (august 2000):
(For subscribtion and old issues visit Counterpanes web-site)
---
Bluetooth
Sometime in the 1950s, various governments realized that you could
eavesdrop on data-processing information from over a hundred feet away,
through walls, with a radio receiver. In the U.S., this was called
TEMPEST, and preventing TEMPEST emissions in radios, encryption gear,
computers, etc., was a massive military program. Civilian computers are
not TEMPEST shielded, and every once in a while you see a demonstration
where someone eavesdrops on a CRT from 50 feet away.
Soon it will get easier.
Bluetooth is a short-range radio communcations protocol that lets pieces of
computer hardware communicate with each other. It's an eavesdropper's
dream. Eavesdrop from up to 300 feet away with normal equipment, and
probably a lot further if you try. Eavesdrop on the CRT and a lot
more. Listen as a computer communicates with a scanner, printer, or
wireless LAN. Listen as a keyboard communicates with a computer. (Whose
password do you want to capture today?) Is anyone developing a
Bluetooth-enabled smart card reader?
What amazes me is the dearth of information about the security of this
protocol. I'm sure someone has thought about it, a team designed some
security into Bluetooth, and that those designers believe it to be
secure. But has anyone reputable examined the protocol? Is the
implementation known to be correct? Are there any programming errors? If
Bluetooth is secure, it will be the first time ever that a major protocol
has been released without any security flaws. I'm not optimistic.
And what about privacy? Bluetooth devices regularly broadcast a unique
ID. Can that be used to track someone's movements?
The stampede towards Bluetooth continues unawares. Expect all sorts of
vulnerabilities, patches, workarounds, spin control, and the like. And
treat Bluetooth as a broadcast protocol, because that's what it is.
Bluetooth:
<http://www.bluetooth.com>
A list of Bluetooth articles, none of them about security:
<http://www.zdnet.co.uk/news/specials/1999/04/bluetooth/>
One mention of security:
<http://www.zdnet.co.uk/news/2000/24/ns-16164.html>
An essay about the Bluetooth hype:
<http://www.idg.net/ic_199451_797_9-10000.html>
Recent article on TEMPEST:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2612547,00.html>
---
Kim
------------------------------
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: Q: Recommended reading about digital watermarking (math-oriented)
Date: 10 Jan 2001 09:17:52 GMT
Jyrki Lahtonen <[EMAIL PROTECTED]> wrote:
> I would like to know a little bit about digital watermarking techniques
> and am looking for books/survey articles on the topic. Most of the stuff
> you find with Alta Vista seem to simply advertise their particular point
> and are rather lacking in their description of the mathematical concepts
> being used (guess they dare not describe their algorithm in detail due
> to
> some legal issue).
As an introduction to the topic, I can recommend you the following
book ;-)
http://www.cl.cam.ac.uk/~fapp2/papers/book99-ih/
Best regards,
S.K.
--
=============================================================
Stefan Katzenbeisser [EMAIL PROTECTED]
http://stud3.tuwien.ac.at/~e9625414 private: [EMAIL PROTECTED]
------------------------------
From: Detlef =?iso-8859-1?Q?H=FChnlein?= <[EMAIL PROTECTED]>
Subject: PKI Bibliography
Date: Wed, 10 Jan 2001 10:58:37 +0000
This is a multi-part message in MIME format.
==============07826B85087349CF87FD1704
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear List!
As I intend to start a university-project
"Development of a PKI-Tutorial" in the next
term, I wonder whether somebody is aware of
a good bibtex-data-base for PKI issues.
Thanks in advance.
Best wishes
Detlef
==============07826B85087349CF87FD1704
Content-Type: text/x-vcard; charset=us-ascii;
name="huehnlein.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Detlef Hühnlein
Content-Disposition: attachment;
filename="huehnlein.vcf"
begin:vcard
n:Huehnlein;Detlef
tel;cell:+49-171-9754980
tel;fax:+49-6196-95888-88
tel;work:+49-6196-95888-22
x-mozilla-html:FALSE
url:www.fbi.fh-darmstadt.de/~huehnlein
org:SECUNET Security Networks AG
adr:;;Mergenthalerallee 77-81;Eschborn;;D-65760;GERMANY
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior Consultant
x-mozilla-cpt:;-1
fn:Detlef Huehnlein
end:vcard
==============07826B85087349CF87FD1704==
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Linear analysis
Date: Wed, 10 Jan 2001 10:11:10 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Does anyone know of any program which automatically does analysis of an
> sbox to find linear relationships?
Sboxgen can be hacked at todo it. Provided the sbox is small enough.
> Also, does anyone have any suggestions for a program to assist me in
> doing linear analysis of a cipher (not just of the sbox) -- perhaps a
> symbolic math package, (like maple or matlab or mathematica) might help?
Like differential analysis each cipher is different. Linear analysis has a
style or technique if you will but it's not concrete. A good linear analysis
of SAFER for example will not work in DES.
> I don't have one, and unless I think it'll help, I'm not going to get
> one (I'm a bit short on disk space).
>
> Lastly, has anyone already *done* linear analysis of the Rijndael/AES
> sbox?
Yup, it has a maximum WalshTransform output of -16/14 I believe (or -14/16)
which means that p=16/256 and you need 1/(p^2) plaintexts or all of them to
crack it. After the affine transform is added the WT output is -16/16.
In other words if you used the sbox as an 8-bit cipher it would be immune to
differential attacks after two rounds (given by (2/(4/256))^r > 256) and a
single round for linear attacks.
Keep in mind that the algebraic degree (sans the affine transform) is low and
can be manipulated with interpolation attacks (Knudsen has a paper on the
subject).
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: secure DOS files
Date: Wed, 10 Jan 2001 10:12:26 GMT
In article <93fi7l$a3dkd$[EMAIL PROTECTED]>,
"Peter Osborne" <[EMAIL PROTECTED]> wrote:
> I've always dreamt of a real private computer, buttttt....
> Since I have probed around with "Scramdisk" and PGP, both seem to be
> well-featured, but that's not what I wanted. Isn't there a really
> simple programme anywhere which exactly does the following steps:
> You type in passphrase before working with your "top-secret"
> directory; these files will be decrypted by a quite poweful AND fast
> algorithm; files can be used as usual; when work is done, all
> sensibel files will be encrypted by that powefull AND fast algorithm,
> and, at last, passphrase or keys will be destroyed automatically
> before system gets shut down.
> Do such code already exist? I don't like to "engineer" it from adam
> and eve...
If I am not mistaken that's the point of Scramdisk. You can unmount
Scramdisk drives when you are done working with them. Maybe you should try
it out for real :-)
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Markku-Juhani Saarinen <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 10:31:18 +0000 (UTC)
Panu Hämäläinen <[EMAIL PROTECTED]> wrote:
: At least the encryption is based on SAFER+, which was one of the AES
: candidates. There should be some analysis about the cipher on the AES
: web site...
Only the authentication is based on SAFER+ which was one the AES
first round candidates but never made it to the second round.
The actual encryption algorithm is a stream cipher called E0. I implemented
this about a year ago; the implementation is available from
http://www.jyu.fi/~mjos/e0.c
Cheers,
-mj
Markku-Juhani O. Saarinen <[EMAIL PROTECTED]> University of Jyväskylä, Finland
------------------------------
From: [EMAIL PROTECTED]
Subject: Crypto Conferences
Date: Wed, 10 Jan 2001 10:47:13 GMT
Hi,
I am looking for the major conferences on cryptography and smart card
security (Names, dates and web sites).
Regards,
Brice.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Ingmar Grahn" <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 12:14:40 +0100
> Only the authentication is based on SAFER+ which was one the AES
> first round candidates but never made it to the second round.
> The actual encryption algorithm is a stream cipher called E0.
Is the E0 algorithm based on some prevously known crypto algorithm, or was
it created for the specific purpose of using it in Bluetooth? If it's
Bluetooth specific, isn't it a drawback that it hasn't been available for
crypto-analysis before it was released?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 12:15:00 +0100
kihdip wrote:
>
> Bruce Schneier wrote this in his CRYPTO-GRAM newsletter (august 2000):
[snip]
> And treat Bluetooth as a broadcast protocol, because that's what it is.
With uncountable mighty organizations (of one's own and/or
foreign countries) sniffing around, there seems indeed to
be no dependable alternative to ensure one's privacy than
carefully done end-to-end encryption (if one has the
liberty to do that).
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Ingmar Grahn" <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 12:16:27 +0100
> from what i hear there are some discussions about extending
> security. but cannot go into detail here.
You say there are some discussions about extending the Bluetooth security?
Could you be a bit more specific about this? I just e-mailed Markus
Jakobsson at Bell-labs (who's one of the authors of "Security Weaknesses in
Bluetooth") asking if he knew if any of the weaknesses found in the v1.0B
standard of Bluetooth was to be corrected in v1.1. But he said that the
flaws were still present in this version. Isn't this extended security
you're talking about supposed to be released until the v2.0 standard? And
anyway, what will this extended security consist of?
/Ingmar Grahn
------------------------------
From: [EMAIL PROTECTED]
Subject: Another Enigma Emulator
Date: Wed, 10 Jan 2001 11:50:01 GMT
I've written (yet another) Enigma emulator, this one is for the Game
Boy Color. (You need a flash cartridge to run it on the real hardware,
otherwise use one of the emulators). May be of interest to some, and it
stores the machine settings + message text in battery-backed RAM.
Source code included in the ZIP file.
The URL is: http://alexandrafletcher.com/Enigma.zip
All feedback gratefully received. :o)
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Wed, 10 Jan 2001 13:08:47 +0100
From: Pascal Junod <[EMAIL PROTECTED]>
Subject: Re: Crypto Conferences
> I am looking for the major conferences on cryptography and smart card
> security (Names, dates and web sites).
For Crypto'01, Eurocrypt'01 and Asiacrypt'01, see
http://www.iacr.org
For SAC'01, see
http://lasecwww.epfl.ch/sac2001
There are another zillion possibilities, but these are four among the most
important.
A+
Pascal
------------------------------
From: "Ingmar Grahn" <[EMAIL PROTECTED]>
Subject: Hash/Message digest vs Signature vs MAC?
Date: Wed, 10 Jan 2001 13:11:50 +0100
Hi!
I'm trying to clear out the concepts of Hash algortithms/message digests,
Signatures and MACs since they seem to be somewhat correlated. Could someone
please correct me where I'm wrong and add comments if suitable:
* A hash algorithm creates a message digest that's different for (almost)
every possible message. Therefore it should be impossible to create a new
message m', such that H(m)=H(m'). This ensures noone can tamper with the
message without us noticing it, right?
* Now, the signature is basically a message digest created with a hash
algorithm, that after it's been calculated also has been encrypted with the
sender/issuers private key. This is so that for example when used in a
certificate, one can check out the issuer(by looking in the certificate
data), and if the issuer is known to the recipient, he already has the
issuers public key (or can get hold of it). So now he takes the encrypted
message digest(=signature) that is sent along with the certificate, and
decrypts it using the issuers public key, and then compare this decrypted
message digest to the one he can calculate himself (using the actual data of
the certificate as input). If they are the same, he knows that the
certificate is legitimate, and that it hasn't been tampered with.
Is this correct? And are there any other other uses for Signatures?
* A MAC is basically a message digest created by a hash algorithm that apart
from the message also takes a key as input. So we have
MAC=HashAlgortithm(K,m). Now, what's the reason for throwing in the key? Why
not just calculate the message digest without the key, and then encrypt the
whole package (Message+Digest)?
Comments please!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Wed, 10 Jan 2001 12:29:12 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> [snip]
> > > In the AES sbox, there are 23 diferentials which have a probability
> > > of 6/256. There are a large number of differentials with
> > > probability of 4/256, 2/256, and 0.
> >
> > Wrong. The highest xor-pair probability is 4/256 not 6/256.
>
> Each of these XOR pair differences occur with probability 6/256.
>
> 08->53 09->62 15->3a 26->94 28->5f 2e->52 34->73 3f->16 46->31 4d->80
> 57->30 5b->5a 68->26 71->c8 7a->b9 80->a6 85->f4 86->27 89->c4 ce->e8
> db->d2 de->7e fe->d8
Something is wrong in your prgoram. There are NO pairs higher then 4/256 in
the Rijndael sbox. It's fact given the construction of the sbox. Basically
the simple way to calc an xor-pair table is do this
table[256][256] = { 0 };
for (x = 0; x < 256; x++)
for (y = 0; y < 256; y++)
++table[x^y][sbox[x]^sbox[x^y]];
Then scan the table for the highest element (ignoring table[0][0]).
(Can you tell I program in C? hehehehe)
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Hash/Message digest vs Signature vs MAC?
Date: Wed, 10 Jan 2001 13:40:11 +0100
"Ingmar Grahn" <[EMAIL PROTECTED]> wrote in message
news:93hji2$c0i$[EMAIL PROTECTED]...
> Hi!
>
> I'm trying to clear out the concepts of Hash algortithms/message digests,
> Signatures and MACs since they seem to be somewhat correlated. Could
someone
> please correct me where I'm wrong and add comments if suitable:
This is a feeble attempt.
> * A hash algorithm creates a message digest that's different for (almost)
> every possible message. Therefore it should be impossible to create a new
> message m', such that H(m)=H(m'). This ensures noone can tamper with the
> message without us noticing it, right?
Almost.
Two plaintexts, m and n, can give the same hash output. Thus H(m)=H(n).
The hash is a fixed length - 160 bit for instance, and has only a limited
space.
Considering that there more possible plaintexts than possibilities with the
fixed 160 bit length, H(m)=H(n) has to be possible (but not very likely).
With the MDC you can verify that the content of the message is just what the
sender has actually sent. - But you cannot be sure that the sender is the
one he claims to be.
>
> * Now, the signature is basically a message digest created with a hash
> algorithm, that after it's been calculated also has been encrypted with
the
> sender/issuers private key. This is so that for example when used in a
> certificate, one can check out the issuer(by looking in the certificate
> data), and if the issuer is known to the recipient, he already has the
> issuers public key (or can get hold of it). So now he takes the encrypted
> message digest(=signature) that is sent along with the certificate, and
> decrypts it using the issuers public key, and then compare this decrypted
> message digest to the one he can calculate himself (using the actual data
of
> the certificate as input). If they are the same, he knows that the
> certificate is legitimate, and that it hasn't been tampered with.
>
> Is this correct? And are there any other other uses for Signatures?
I believe you're right - I'm not that familiar with the signatures.
Although I believe that 'signature' describes the way to sign a message.
Like the 'protocol' you described.
A signature scheme could use a MDC+encryption or a MAC as 'building-blocks'
for the signature.
>
> * A MAC is basically a message digest created by a hash algorithm that
apart
> from the message also takes a key as input. So we have
> MAC=HashAlgortithm(K,m). Now, what's the reason for throwing in the key?
Why
> not just calculate the message digest without the key, and then encrypt
the
> whole package (Message+Digest)?
The key in the MAC ensures that the sender is the one he claims to be.
Normally you encrypt your data and then uses a hash algorithm to
authenticate it and not the other way round.
In IPSec for instance, a index number (SPI) is used to tell the receiver
about the transmission. This number cannot be encrypted, but you'll need the
authentication.
>
> Comments please!
>
As stated, this was a feeble attempt.
Kim
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Bluetooth security?
Date: Wed, 10 Jan 2001 13:47:35 +0100
The E0 algorithm is bluetooth specific.
This must be a drawback as I see it. The paper from Bell-labs concludes that
E0 should be replaced by another known algorithm, for instance AES.
- Sounds reasonable.
Kim
------------------------------
From: [EMAIL PROTECTED]
Subject: DES validation
Date: Wed, 10 Jan 2001 12:50:11 GMT
Hi all
Does anyone have some test vectors for DES. What a i really need is
each of the keys used in each round...and some intermediate values for
the first couple of rounds (like before sbox, after sbox). A single set
of key,plaintext and ciphertext will do but more than one would be nice
Thanks
Jonathan
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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
******************************
