Cryptography-Digest Digest #848, Volume #12 Thu, 5 Oct 00 09:13:00 EDT
Contents:
Re: PRNG improvment?? (Tim Tyler)
TEA ("Nik")
blowfish implementatios in different machines. ("P. Pascual")
Re: Advanced Encryption Standard - winner is Rijndael (Jonathan Thornburg)
Re: blowfish implementatios in different machines. (David Schwartz)
Re: HELLO?!?!?! Where are you, Jim Gillogly? I wish you would (Bob Harris)
Re: Idea for Twofish and Serpent Teams (Tom St Denis)
Re: Any products using Rijndael? (Tom St Denis)
Re: TC8 -- Yet Another Block Cipher (Tom St Denis)
Re: blowfish implementatios in different machines. (Tom St Denis)
Re: CRC vs. HASH functions (Tom St Denis)
Re: TEA (Tom St Denis)
Re: The best way to pronounce AES (Tom St Denis)
Re: Idea for Twofish and Serpent Teams (Tom St Denis)
Re: blowfish implementatios in different machines. (David Schwartz)
Rijndael Coverage Improved on Web Site (John Savard)
Re: blowfish implementatios in different machines. (Tom St Denis)
Re: blowfish implementatios in different machines. (Tom St Denis)
Re: Encryption Project ("Arnold Shore")
Re: Advanced Encryption Standard - winner is Rijndael (Runu Knips)
Re: blowfish implementatios in different machines. (Runu Knips)
Compute Public Key from Private Key - Algorithms? ("Arnold Shore")
Re: Signature size ("Joseph Ashwood")
Re: TEA (Runu Knips)
Re: TC8 -- Yet Another Block Cipher (Pascal JUNOD)
Re: Encryption Project ("Robert Hulme")
Re: BlowFry... (Runu Knips)
newbie pathetic question ("Danilo")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: PRNG improvment??
Reply-To: [EMAIL PROTECTED]
Date: Thu, 5 Oct 2000 09:53:11 GMT
John Myre <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote (quoting DAG):
:> : Uniform distribution emphatically does *not* mean that all
:> : values occur exactly the same number of times in any given
:> : finite sample. [...]
:>
:> Nor does this appear to be true of the output of ds908's generator.
: It does if you interpret his post the way most of us
: are doing. Try reading the OP again, trying out the
: assumption that "shuffle" is the main operation; that
: the point is to introduce a random permutation of a
: very large array that is guaranteed to have the same
: count of each value.
"INDEX values in the range of 0-2559" would not be terribly useful
if existing entries were being removed after bing picked.
However, I now see how others are interpreting the post, with
"shuffle" being taken to imply a permutation was being generated.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: "Nik" <[EMAIL PROTECTED]>
Subject: TEA
Date: Thu, 5 Oct 2000 14:20:49 +0400
Whether there are legal restrictions of application of the given algorithm,
in particular for commercial use.
Excuse for mine bad English.
Alex Nik
------------------------------
From: "P. Pascual" <[EMAIL PROTECTED]>
Subject: blowfish implementatios in different machines.
Date: Thu, 5 Oct 2000 12:20:36 +0200
An elemental question that I don't know.
A string encrypted with a C version of the blowfish algorithm can be
decrypted with a Visual C version of the same algorithm running in
a windows machine?
Thanks.
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: 5 Oct 2000 12:27:02 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
[[many comments with which I quite agree]]
>[[...]] I think I'll
>give people like Eli Biham and David Wagner another year to work on it
>before having any measure of confidence.
That short a time? My intuition is that 5-10 years of all the world's
crypto people beating on it unsuccessfully will be needed before we can
view it as more robust than 3DES (which, after all, now has 25ish years
of everyone-beating-on-it experience). Of course, the problem is that
neither John Savard nor I has much (I suspect _anything_) in the way
of quantitative analysis for our respective "how long till we trust it?"
numbers...
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Only 7 countries have the death penalty for children. Which are they?
A: Congo, Iran, Nigeria, Pakistan[*], Saudi Arabia, United States, Yemen
[*] Pakistan moved to end this in July 2000. -- Amnesty International,
http://www.amnesty.org/ailib/aipub/2000/AMR/25113900.htm
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: blowfish implementatios in different machines.
Date: Thu, 05 Oct 2000 03:55:54 -0700
"P. Pascual" wrote:
> An elemental question that I don't know.
> A string encrypted with a C version of the blowfish algorithm can be
> decrypted with a Visual C version of the same algorithm running in
> a windows machine?
If done correctly, yes. If not, no.
You must come up with a single unique way to map characters in the
string to blocks in the cipher. It's easy to not do this.
For example, if the string begins 'ABCDEFGH' what are the two 32-bit
integers that this corresponds to?
If the first 8 bytes of ciphertext over the wire are 0x01 0x02 0x03
0x04 0x05 0x06 0x07 0x08, what are the two 32-bit integeres that this
corresponds to?
Again, you need a single unique way to map the strings to the integers
that go into and come out of the cipher.
DS
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: Re: HELLO?!?!?! Where are you, Jim Gillogly? I wish you would
Date: Thu, 05 Oct 2000 06:59:27 -0400
[EMAIL PROTECTED] (daniel mcgrath) wrote:
> Why is Jim Gillogly so often not responding to my posts regarding the
> cryptograms? I have even been sending these messages to him as e-mail
> AS WELL AS posting them and he STILL won't saying anything. Where is
> he? I wish he would respond!!!
This reminds me of the guy (long ago) who knocked on my dorm room door at 2
AM, demanding that I help him get his program working. It was due the next
morning, and if I didn't help him get it working, it would be "my fault" if
he failed the class. I have to assume he failed.
The "rec" in rec.puzzles means recreation. There's no obligation.
Bob Harris
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Date: Thu, 05 Oct 2000 11:04:34 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> Runu Knips writes:
>
> >Helger Lipmaa wrote:
> >> Tom St Denis wrote:
> >> > Do what RSA did and make your own "Symmetric Cipher Standards"
and
> >> > ignore the govt.
> >>
> >> There was a thread recently in this newsgroup, about the general
> >> attitude that guys who understand nothing about security try to
strut
> >> and to demand and to insult those who know better.
> >
> >Tom might insult people unnecessarily in this NG, but
> >AFAIK he's far from being a 'guy who understand nothing
> >about security' !
>
> Much of what Tom posts is insulting, patronzing, wrong or
exaggerated. Helger
> might have written "guys who understand damn little about security"
instead of
> "nothing about
> security" but you do see his point, don't you? Neophytes insulting
and calling
> into question the opinion of real experts deprives sci.crypt of more
postings
> from real experts.
Ok mr "I am so perfect". Why don't you reply to my other mathy
questions and comments I post. Do you have any comments on real
crypto, or just on "some stupid kid that is rude".
See I find it ironic that when I do post anything half-intelligent you
guys ignore it, but when I question a "professional" you jump all over
me.
Hmm... Funny...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Any products using Rijndael?
Date: Thu, 05 Oct 2000 11:05:47 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I wonder if there is any product that actually use this new AES?
>
> AFAIK nobody used Rijndael yet because nobody thought it is
> very secure.
>
> > Im looking for disk encryption.
>
> Good ciphers I would trust under all conditions are:
>
> Twofish
> Blowfish
> Serpent
>
> AES/Rijndael and IDEA are also ciphers with not too low
> security. SEAL is a very good stream cipher, and, like
> IDEA, patented. GHOST is a good russian design, old but
> AFAIK still very secure. CAST128, also called CAST5, is
> another really good cipher.
How do you figure IDEA is not secure? Only 4.5 rounds have
been "theoretically" broken and it requires 99% of the codebook.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: TC8 -- Yet Another Block Cipher
Date: Thu, 05 Oct 2000 11:08:18 GMT
In article <[EMAIL PROTECTED]>,
David Blackman <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > This cipher is designed after CS-Cipher but is much simpler and uses
> > little ram/rom. It's a cute cipher and I would appreciate any
comments.
> >
> > This cipher has awesome diffusion amongst the bytes (64-bit block
> > cipher) and is very simple to look at.
> >
> > I noticed very little comments on MyFish... oh well...
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> 64 bit block cyphers are toys. It seems that even with chaining modes,
> there are birthday attacks after a few GB, and lots of us would like
to
> be able to work with more data than that.
>
> Please switch to 128 bits for future designs. Or maybe even 256. I'm
> half expecting someone to come up with a generic attack on all 128 bit
> block cyphers, now that everyone is committed to using them for the
next
> 30 years :-)
Hmm... well you're wrong, but that's ok.
If you actually looked at the website (oops forgot to post the link
sorry...) you would realize that TC8 is for "low bandwidth" uses...
Sorry the url is
http://www.geocities.com/tomstdenis/
near the bottom.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: blowfish implementatios in different machines.
Date: Thu, 05 Oct 2000 11:14:00 GMT
In article <8rhkj5$[EMAIL PROTECTED]>,
"P. Pascual" <[EMAIL PROTECTED]> wrote:
> An elemental question that I don't know.
> A string encrypted with a C version of the blowfish algorithm can be
> decrypted with a Visual C version of the same algorithm running in
> a windows machine?
If you implement the algorithm as per the paper then my i8032 board
should be able to read your string as well (given the key, etc...).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Date: Thu, 05 Oct 2000 11:11:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> Having been working hard and not here for a while
> the topic of CRC vs. HASH functions
> came up in a thread.
>
> 1) CRC are faster than HASH functions of
> comparable size. That is a fact. Many
> hash functions use a CRC like layer at the
> top to mix in data linearly. SHA-1 is no exception.
> A table driven 256 bit hash function requires 4 32-bit word
> lookups/byte, four 32-bit word XORs, a shift and an XOR
> to add data.
>
> A 16-bit lookup uses fewer lookups but much bigger
> tables.
>
> 2) checksum is a special case of a CRC
> consider the CRC polynomial 2^8+1.
> Two common CRC's are the product of 2^1+1
> and some other primitive. This has certain
> 'nice' properties.
>
> 3) If you are hashing data use a CRC.
> If you need security use a HASH function.
>
> 4) A HASH does not guarantee anything
> A CRC guarantees certain changes will always
> change the output.
I can say "you're wrong" or "you're right" but without knowing "what"
you're doing with either I can't decide.
If you need a fingerprint that is hard to forge pick a hash, if you
need to protect against random file errors pick a crc or perhaps MD4
(it was rather fast, not particularly secure though).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: TEA
Date: Thu, 05 Oct 2000 11:13:02 GMT
In article <39dc570f$[EMAIL PROTECTED]>,
"Nik" <[EMAIL PROTECTED]> wrote:
> Whether there are legal restrictions of application of the given
algorithm,
> in particular for commercial use.
>
> Excuse for mine bad English.
Hmm well generally TEA is not regarded as a good cipher. You could try
looking up X-TEA, but that cipher is slow and hasn't been analyzed
(unfortunately)...
It's patent free, etc... so you could drop it in an application now.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES
Date: Thu, 05 Oct 2000 11:09:11 GMT
In article <[EMAIL PROTECTED]>,
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> Scott Craver wrote:
> >
> > I know I have no authority to decide these things, but I
> > strongly feel that "AES" should be pronounced, "uh-YES."
> >
> > Like Mr. Dingle or whoever it was from the train station in
> > the old Jack Benny radio
show. "auhYEEEEEEEEEEEEEEEEEEEEEESSSS????"
> >
>
> Maybe you should just call it by its True Name: "Rain Doll"...
Hehehe I used to pronouce that cipher as "reg-n'-dale'"...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Date: Thu, 05 Oct 2000 11:16:19 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > In article <[EMAIL PROTECTED]>,
> > Arturo <[EMAIL PROTECTED]=NOSPAM> wrote:
> > > On Mon, 02 Oct 2000 18:15:57 GMT, Tom St Denis
<[EMAIL PROTECTED]>
> > wrote:
> > >
> > > >Do what RSA did and make your own "Symmetric Cipher Standards"
and
> > > >ignore the govt.
> > > >
> > > That�s exactly what the GSM gang did, and see the results:
an
> > > easy-to-break cipher.
> >
> > See now your being a complete idiot.
>
> Tom, if you have the better arguments, there is no need to
> insult your opponent. Just tell him your arguments !
Well when I make glarring errors I am not afraid of you standing up
saying "duh, tom stop being stupid!". True I should be more polite but
the decision by NIST really peeved me.
> > Twofish and Serpent are not homebrew ciphers designed by
> > Business majors. They are two very good
> > ciphers designed by the best of the best.
>
> Yep.
>
> I don't think those ciphers need any more advertisement, such
> as assigning another special, useless name to them. Their
> quality speaks for themselves.
Which is why if Eli Biham developped his own "cipher std" I would fully
support it (provide it was secure).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: blowfish implementatios in different machines.
Date: Thu, 05 Oct 2000 04:26:27 -0700
Tom St Denis wrote:
> In article <8rhkj5$[EMAIL PROTECTED]>,
> "P. Pascual" <[EMAIL PROTECTED]> wrote:
> > An elemental question that I don't know.
> > A string encrypted with a C version of the blowfish algorithm can be
> > decrypted with a Visual C version of the same algorithm running in
> > a windows machine?
> If you implement the algorithm as per the paper then my i8032 board
> should be able to read your string as well (given the key, etc...).
The paper does not explain how you dice the string into 64-bit chunks
or what you do if the string is not a multiple of 64-bits. The paper
does not explain in what order you send the 64-bit chunks of output over
the wire or into a file.
For interoperability, just implementing the same cipher is not enough.
DS
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Rijndael Coverage Improved on Web Site
Date: Thu, 05 Oct 2000 11:27:59 GMT
As befits Rijndael's status as the new AES, I've extended the
description of it on my web page. Also, I moved it to first place in
my listing of algorithms by swapping it with LOKI-97.
I now describe the key schedule, although not in complete detail. (It
was unclear whether the constant to be XORed was a power or a
factorial from the description given.) Also, I now give the S-box
explicitly.
As well, I note how the different parts of Rijndael correspond to
parts of DES - even noting the error I made in thinking Rijndael
seriously flawed. Also, I am even bold enough to propose tweaks to
Rijndael: I note how alternate Mix Column matrix multiplications could
be replaced by a scaled-down version of the PHT from SAFER so that the
cipher would be less uniform.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: blowfish implementatios in different machines.
Date: Thu, 05 Oct 2000 11:39:10 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> "P. Pascual" wrote:
>
> > An elemental question that I don't know.
> > A string encrypted with a C version of the blowfish algorithm can be
> > decrypted with a Visual C version of the same algorithm running in
> > a windows machine?
>
> If done correctly, yes. If not, no.
>
> You must come up with a single unique way to map characters in
the
> string to blocks in the cipher. It's easy to not do this.
>
> For example, if the string begins 'ABCDEFGH' what are the two
32-bit
> integers that this corresponds to?
>
> If the first 8 bytes of ciphertext over the wire are 0x01 0x02
0x03
> 0x04 0x05 0x06 0x07 0x08, what are the two 32-bit integeres that this
> corresponds to?
>
> Again, you need a single unique way to map the strings to the
integers
> that go into and come out of the cipher.
Well the endianess is specified as part of the cipher. And going
binary->ascii is not hard...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: blowfish implementatios in different machines.
Date: Thu, 05 Oct 2000 12:02:11 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Tom St Denis wrote:
>
> > In article <8rhkj5$[EMAIL PROTECTED]>,
> > "P. Pascual" <[EMAIL PROTECTED]> wrote:
>
> > > An elemental question that I don't know.
> > > A string encrypted with a C version of the blowfish algorithm can
be
> > > decrypted with a Visual C version of the same algorithm running in
> > > a windows machine?
>
> > If you implement the algorithm as per the paper then my i8032 board
> > should be able to read your string as well (given the key, etc...).
>
> The paper does not explain how you dice the string into 64-bit
chunks
> or what you do if the string is not a multiple of 64-bits. The paper
> does not explain in what order you send the 64-bit chunks of output
over
> the wire or into a file.
>
> For interoperability, just implementing the same cipher is not
enough.
Actually I am rather sure that "little endianess" is understood. And
you don't dice 64 bits of ciphertext when you send it. Like all block
ciphers you need the entire block to proceed.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Re: Encryption Project
Date: Thu, 5 Oct 2000 08:14:18 -0400
I'm doing almost exactly what you describe. But (if I understand you
correctly) a question: If the password isn't stored, then how would the Pay
information be encrypted for loading by any batch process?
If the password IS stored, then its storage (wherever) is a vulnerability.
No???
I've gone to asymmetric encryption, using the Dyncrypto product (CAST and
ECC algorithms). To simplify, the userID and password are conccatenated to
form the private key, from which the public key is computed and stored.
I use that public key to encrypt the data during a periodic batch run. For
information that's subject to lookup, I store a hash value in addition to
its encrypted form.
There's much more than this, but the above is an overview.
Arnold Shore
Annpolis, MD USA
"Robert Hulme" <[EMAIL PROTECTED]> wrote in message
news:8rcjpf$i2s$[EMAIL PROTECTED]...
> The situation has changed a little...
>
> What seems to be happening now (and correct me please if this is
incredibly
> stupid) is this:
>
> The data in the database is going to be encrypted. So it'll go from being
> like this:
> ID Name Pay
> 1 Rob $10,000
>
> to
> ID EncryptedData
> 1 AASDFO"�$
>
> the data will be encrypted by the application I'm writing that processes
the
> data from their payroll system - and encrypted with something like
TripleDES
> or something, with the users password as the key. The password will be an
8
> character random alpha numeric.
>
> Then the encrypted database will be put on the database server - and even
if
> someone nicked each record is encrypted with a password / key that is
unique
> for each record. ASP (or PHP as we might get to use now) will decrypt and
> decode (into the right variables) all the fields for a record that were
> originally stored as seperate fields. That way the passwords are only
stored
> on the computer that encrypts the database, and mailed to each person
> individually (postal mail) - the passwords are not stored on the server.
>
> So a check would be performed when people try to login to see if the
> password/key they're trying for a particular record produces valid data or
> not.
>
> Is this glaringly wrong?
> -Rob
>
>
------------------------------
Date: Thu, 05 Oct 2000 14:09:27 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
nemo outis wrote:
> Thanks. I guess "security through obscurity" is a workable solution (in
> the sense of another layer of protection beyond the core algorithmic layers)
> if you have your own sufficiently large "captive review community" of
> mathematicians, computer scientists, et al. to review/test your systems.
Yep, if you have 40.000 mathematicans which can test your stuff you
surely can add such a layer of additional protection. The real
protection, however, comes from an unknown amount of not publically
available knowledge about kryptographical techniques.
------------------------------
Date: Thu, 05 Oct 2000 14:11:07 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: blowfish implementatios in different machines.
"P. Pascual" wrote:
> A string encrypted with a C version of the blowfish algorithm can be
> decrypted with a Visual C version of the same algorithm running in
> a windows machine?
If not, at least one of the versions are buggy.
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Compute Public Key from Private Key - Algorithms?
Date: Thu, 5 Oct 2000 08:20:07 -0400
I'll appreciate any information on algorithms and implementations that
support subject process.
I'm using a commercial product set that performs this ratrher nicely
(AFAIK), but I've been bitten by the algorithm bug, and want access to the
underlying theory.
Thanks, folks.
Arnold Shore
Annapolis, MD USA
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Signature size
Date: Wed, 4 Oct 2000 22:59:34 -0500
> in which all but 32 bits are chosen
> by the attacker.
Exactly, but since the instruction is known to be 32-bits,
the instruction itself is fixed.
Joe
------------------------------
Date: Thu, 05 Oct 2000 14:26:41 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: TEA
Nik wrote:
> Whether there are legal restrictions of application of the given algorithm,
> in particular for commercial use.
If you want mainly a SIMPLE cipher, maybe Blowfish is an option for you.
Another very simple algorithm is RC4, but beware you don't call it RC4
if you use it, because RSA Data Security Inc has a trademark on that
name; call it Arcfour instead.
Well from the AES ciphers Serpent seems to be the simplest one. It is
however hard to get a good implementation of the s-boxes, try
http://www.btinternet.com/~brian.gladman/cryptography_technology/aes/index.html
Btw, there is a very good russian cipher, GHOST. It is very old and not
too fast, but it is also still considered secure (and unlikely to change
that state because it has a 256 bit key and 32 rounds, where each round
is a little worse than original DES, on which this design was based).
All the above ciphers are free. Serpent and Blowfish are maybe the
most secure ciphers you can get. At least with Serpent everybody
in this NG seems to agree about that.
------------------------------
Date: Thu, 05 Oct 2000 14:30:40 +0200
From: Pascal JUNOD <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TC8 -- Yet Another Block Cipher
> This cipher has awesome diffusion amongst the bytes (64-bit block
> cipher) and is very simple to look at.
You can have a look about birthday attacks concerning CBC-mode and any
64-bit block cipher:
http://lasecwww.epfl.ch/birthday.shtml
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Laboratoire de S�curit� et de Cryptographie (LASEC) *
* INR 313, EPFL, CH-1015 Lausanne, Switzerland ++41 (0)21 693 76 17 *
* Place de la Gare 12, CH-1020 Renens ++41 (0)79 617 28 57 *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: "Robert Hulme" <[EMAIL PROTECTED]>
Subject: Re: Encryption Project
Date: Thu, 5 Oct 2000 13:36:12 +0100
Hi,
>I'm doing almost exactly what you describe. But (if I understand you
>correctly) a question: If the password isn't stored, then how would >the
Pay
>information be encrypted for loading by any batch process?
Yeah - in the system I'm considering the passwords would be stored on the
computer that originally encrypts the data back in the office. The passwords
would remain on that computer while the encrypted data would be sent to the
internet database server. That way the passwords are kept safe back in the
office on a non networked machine.
>I've gone to asymmetric encryption, using the Dyncrypto product. To
>simplify, the userID and password are conccatenated to form the >privatge
>key, from which the public key is computed and stored.
Yeah. Thankfully it looks like the client is going to let us use Apache
webserver and PHP now. This means we can use the free mcrypt library with
PHP to encrypt / decrypt using strong encryption.
Like so : <?PHP $data=mcrypt_decrypt(CIPHER_TripleDES, $encrypteddata, $key)
where key would be there password and $encrypteddata would be the data
collected from the database via a simple SELECT DATA FROM TABLE WHERE
USERID='3' (or whatever).
------------------------------
Date: Thu, 05 Oct 2000 14:38:34 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: BlowFry...
Rob Marston wrote:
> To this end I have produced an 8bit version of BlowFish
> which for fun I have christened BlowFry.
I wouldn't waste a new name for such a crippled algorithm.
BlowFish/4 or so would have been enough.
And it seems to be a 4 bit, not 8 bit version of the
algorithm. Too, you should store
*xl = L & 0xf
*xr = R & 0xf
because the addition might cause an overflow to the
upper 4 bits of the result (Btw, I would have simply
used a single byte as in- and output)
> This variant I hope keeps the BlowFish algorithm
> intact but drastically simplifies the analysis.
> The problem I have had with this implementation
> and this is where my knowledge crumbles is what
> the S-Box's should contain.
Random bits which depend upon the value of the key.
> I was wondering if you could advise me what
> the appropriate values for these 26 S-Box
> elements would be...
Well, in the original algorithm that are the
first bits of pi.
> The aim of BlowFry was to use it to mount a
> differential attack scenario and hence learn
> a little more.
Good luck !
> Interestingly I've noticed that a lot of BlowFry
> encryption results appear as pairs. {Plot a
> scattergram of blowfry.csv and you will see}
> I assume this is a function of the bad S-Box
> design...
No idea.
------------------------------
From: "Danilo" <[EMAIL PROTECTED]>
Subject: newbie pathetic question
Date: Sun, 1 Oct 2000 12:10:23 +0200
I wonder why is arithmetic coding not used to scramble messages ?
If I arithmetic compress a message, but using a frequency table which
is actually my key (both in the frequencies and in the order of the bytes),
wouldn't it be very hard to decrypt ?
Excuse in advance for my pathetic ignorance of the matter.
Danilo
------------------------------
** 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
******************************
