Cryptography-Digest Digest #854, Volume #12 Fri, 6 Oct 00 04:13:01 EDT
Contents:
Re: CRC vs. HASH functions (Mack)
Re: CRC vs. HASH functions (Mack)
Re: Looking Closely at Rijndael, the new AES (Mack)
Getting best available security without knowing which cipher to use (Ray Dillinger)
Re: what is wrapped PCBC? (SCOTT19U.ZIP_GUY)
Re: TEA (Mok-Kong Shen)
Re: Looking Closely at Rijndael, the new AES (Mok-Kong Shen)
Re: Rijndael is AES.... (pgp651)
Re: Rijndael test vectors (Mok-Kong Shen)
Re: Getting best available security without knowing which cipher to use (Runu Knips)
Blowfish uses big endian (according to OpenSSL and GnuPG) (Runu Knips)
Re: TEA (Runu Knips)
Re: The best way to pronounce AES (Runu Knips)
Re: The best way to pronounce AES (David Crick)
CRYPTON site (was Re: It's Rijndael) (David Hopwood)
Re: Rijndael test vectors ("Brian Gladman")
Re: Rijndael test vectors ("Brian Gladman")
Re: It's Rijndael (David Hopwood)
Suggestion for Digital Cash System ("P.C. Teo")
Re: It's Rijndael (Runu Knips)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CRC vs. HASH functions
Date: 06 Oct 2000 04:11:59 GMT
>Mack wrote:
>
>> 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 table driven hash function? Did you mean a CRC? In any
>case, I'd like to see the algorithm to compute a 256 bit
>result with the stated operations.
>
>
>--Bryan
>--
>email: bolson at certicom dot com
>
>
Ack yes ... of course a table driven hash function is a possibility.
Hmmm ... yes ... full of possibilities.
Of course I did mean table driven CRC function. Sorry for the error
it has been a long long month.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CRC vs. HASH functions
Date: 06 Oct 2000 04:15:41 GMT
>>
>> 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
>
See point 3. If you need security use a HASH function.
If you need to hash data (ie. simple fingerprint) use a CRC.
A lot of text recommend using integer division for hashing.
A CRC is generally faster than division with a large integer
ie a few hundred bits.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: 06 Oct 2000 04:25:16 GMT
>On Thu, 05 Oct 2000 22:45:21 -0200, "Paulo S. L. M. Barreto"
><[EMAIL PROTECTED]> wrote, in part:
>
>>Then let me introduce "One-Time Pad".
>>Can you think of anything smaller or faster? Yet if you don't accept
>>that as secure, then just forget *anything* else.
>
>That is true, but not germane.
>
>The one-time-pad is secure because the key matches the message in
>size.
>
>When the key is fixed in size, however, simple XOR (of the key over
>and over) is not secure. For a fixed size key - a key just large
>enough to prevent brute force search - can a fast, small, simple
>cipher be secure?
>
>That is the question to which "no" may _well_ be the answer, and that
>is the question really being discussed, even if that hasn't been
>indicated explicitly: can _work factor security_, as opposed to
>_information-theoretic security_, be obtained from a small, fast
>cipher.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
Nothing could be faster than a OTP encryption operation.
The problem lies in Key generation and distribution.
For a 6GByte file the key is 6GB that is about 60 CD's (A little less
use 700MB CD's) There is nothing small about OTP.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Getting best available security without knowing which cipher to use
Date: Fri, 06 Oct 2000 05:17:16 GMT
It is possible to split messages into multiple parts and transmit
the parts -- so that the message may be reassembled only when all
of the parts are present.
Rivest has done this with his "package transform" -- if you are
missing any part of the message, then you can't figure out any
of the whole.
Where multiple ciphers are available, it seems possible to use
such a "package" transform to take advantage of the *BEST* security
offered by any member of a set of ciphers, even when you don't
know which cipher it is that offers the best security.
For example, after a package transform, I have twenty blocks of
message -- all of which look like random bits, which is good for
enciphering security anyhow since the 'plaintext' has high
entropy. Now, I encrypt one with algorithm A, the second with
algorithm B, the third with Algorithm C .... and so on up to the
twentieth.
If I have twenty ciphers, and I suspect that an enemy has broken
or can break most of them, but don't know which ones the enemy
has broken or can break, this technique should permit me to still
transmit messages securely. If even one cipher remains opaque
to the snoop, then the snoop cannot recover that block and undo
the package transform.
Just a note, but obviously I should not use the same key with
these suspect ciphers -- if the opponent can break one and recover
your key, then she would have the key to all others as well.
Of course, this involves trusting that the attacker does not
know an attack on the package transform that works with only
the number of blocks of the package that the attacker can
recover. But that was a given. The package transform is
pretty solid, however -- its roots are directly in the discrete
logarithm problem.
Thoughts, Ideas, Comments?
Bear
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: what is wrapped PCBC?
Date: 6 Oct 2000 05:18:30 GMT
[EMAIL PROTECTED] (Mack) wrote in <20001006000832.15659.00000334@ng-
fd1.aol.com>:
>>[EMAIL PROTECTED] (Marc) wrote in <[EMAIL PROTECTED]>:
>>
>>>
>>>No email supplied other than [EMAIL PROTECTED], sorry
>>>for asking public.
>>
>> You can email from the main webpage
>>
>>>
>>>> The "wrapped PCBC" will handle any byte length for a file longer than
>>>> 3 block lengths.
>>>
>>>How does "wrapped PCBC" work, and why do you prefer it over "ciphertext
>>>stealing" which works with files >= 1 block length?
>>
>> The best page to look at is the one by Horst:
>> http://xoom.members.com/ecil/page2.htm
>>it is for scott19u but it is explained there quite well however
>>I have to admit even with horsts hell Mok and DW seem to be totally
>>lost. I suspect its only because they both were to lazy to look.
>>
>>David A. Scott
>>--
>>SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
>> http://www.jim.com/jamesd/Kong/scott19u.zip
>>Scott famous encryption website **now all allowed**
>> http://members.xoom.com/ecil/index.htm
>>Scott LATEST UPDATED source for scott*u.zip
>> http://radiusnet.net/crypto/ then look for
>> sub directory scott after pressing CRYPTO
>>Scott famous Compression Page
>> http://members.xoom.com/ecil/compress.htm
>>**NOTE EMAIL address is for SPAMERS***
>>I leave you with this final thought from President Bill Clinton:
>>
>
>wrapped PCBC is basically a form of chaining similar to CBC and PCBC.
>It uses multiple passes over the text wrapping the last block to the front
>
>It is a form of AONT. If the encryption function is unbreakable wrapped
>PCBC is unbreakable.
>
>example
>
>P1 P2 P3 P4
>E1=f(P4^P1^P2)
>E2=f(E1^P2^P3)
>E3=f(E2^P3^P4)
>E4=f(E3^P4^E1))
However in scott19u E1 does not overlay P1 there is a 9 bit shit
so that the file rotates 9 bits each pass.
>
>now here is where it gets interesting
>
>second round produces what we will call G
>G1=f(E4^E1^E2)
>G2=f(G1^E2^E3)
>G3=f(G2^E3^E4)
>G4=f(G3^E4^G1)
>
>notice that this is invertible
>
>In scott19u and relatives the second xor is changed to a +.
>
>It must be decrypted last block first to unwind it.
>In particular scott19u uses large tables for f and round keys.
>
>This prevents 'the Onions attack' by Paul Onions which is
>a form of Slide attack. It is interesting that it isn't mentioned
>in David Wagner's paper on Slide attacks. I believe David may have
>been around a bit when that attack was introduced.
>
Well at the time David Wanger brought up his slide attack
he made a grand statement that it was the death of my cipher
until someone tried it and mentioned some of the problems it
caused for the slide attack. Wagner in only one small post
admitted that the slide attack may well not work against it
but that he did not really understand what my code did.
I guess having the complete source code that compiles was just
to hard for him to follow.
Actually I suspect he never looked at it at all and was just
spouting BS out his mouth. Most people who attend Berkeley are
quite arrogant. I konw I have met many of them and one of my siblings
went there for 3 years. But then again there are a few rare
good ones from there.
>I posted a paper about it a long time back in sci.crypt.research
>I introduced IS8, RS8 and M8 of those only M8 had round keys
>and is still unbroken. It is in the north american crypto archive
>as X8.ZIP
>
I remeber but for some reasom I thought your name was Maack
but then again I can't spell worth shit.
>
>
>Mack
>Remove njunk123 from name to reply by e-mail
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: TEA
Date: Fri, 06 Oct 2000 08:32:53 +0200
David Wagner wrote:
>
> Use a trusted cipher; 3DES, if you can afford it, or AES, if not.
I conjecture that this is indeed the way plenty of people
would choose for many years to come.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Fri, 06 Oct 2000 08:32:47 +0200
John Savard wrote:
>
> When the key is fixed in size, however, simple XOR (of the key over
> and over) is not secure. For a fixed size key - a key just large
> enough to prevent brute force search - can a fast, small, simple
> cipher be secure?
>
> That is the question to which "no" may _well_ be the answer, and that
> is the question really being discussed, even if that hasn't been
> indicated explicitly: can _work factor security_, as opposed to
> _information-theoretic security_, be obtained from a small, fast
> cipher.
>
I suppose that the question is problematical because the
concepts fast, small and simple don't have agreed upon
quantifiable measures, not to mention the known difficulty
in connection with the issue of strength.
M. K. Shen
------------------------------
Date: 6 Oct 2000 06:31:46 -0000
From: pgp651 <Use-Author-Supplied-Address-Header@[127.1]>
Subject: Re: Rijndael is AES....
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
=====BEGIN PGP SIGNED MESSAGE=====
Pigs could know you instead.
Pigs don't have to rent / live with you, simple visit will do.
Pigs can fly, specially black, unmarked helicopters at night.
Pigs know magic, specially good magic.
On Thu, 05 Oct 2000, Ron B. <[EMAIL PROTECTED]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 5 Oct 2000 14:58:00 -0000, pgp651
><Use-Author-Address-Header@[127.1]> wrote:
>
>>Pigs are everywhere, and pigs are clever.
>>Are you sure that you don't have any pigs around you ?
>>
>I don;'t know any pigs. Pigs are forbidden by my rental agreement.
>My cat eats pigs. Pigs type worse then my cat.
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Fri Oct 6 06:31:44 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOd1x0k5NDhYLYPHNAQGZ0Qf+OoZiovSE4wc2ECtoU+Xh5wpD1WhtF1i3
mb0dRuXBgCrZPRuT0C7Wwvn1/qZTO+Sb5cH7QQg6HzwQ3bIcyLdmzAOrit+YY7Le
QnhXtjbByMcq5Ot6HU+W314BgV3mdd6b+NtDopbDPbdTj4qgkZNA8WArPFSajHz0
25Ed6ZxtrcAU+Ijav3PS81tkNHfZi3O4cpoFoECidoFRmcTqvxI6GjyuttU+GtmN
NXcsP3OyRMXhzhFM4dRIaiTRiCL7jH25y9dp0TrvzBixKBaj5+tPZ2aH5g91NtjD
o1fy5XKCMJaj4PaO7hthp2laEYG1166baR2LvxYAwfc1QbwcNYEszA==
=LdSU
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Rijndael test vectors
Date: Fri, 06 Oct 2000 08:49:45 +0200
John Savard wrote:
>
> I'm still miffed that the specification for Rijndael - even the
> current version - does not exhibit the S-box. That it happens to be
> the multiplicative inverse on GF(2^8) followed by a bitwise matrix
> multiply is very nice background material, but prospective
> implementers ought not to be expected to jump through hoops of
> advanced mathematics.
If I don't err, this is the most concise way of specifying
the substitution in question, for the purpose of explaining
how it is arrived at and of having a nice looking document.
One could compute that out and put the stuff in a table form,
of course. I guess that an actual implementation would in
fact use such a table. The matter with GF should be familiar
with people of CS or EE knowing some coding theory.
M. K. Shen
------------------------------
Date: Fri, 06 Oct 2000 08:40:29 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Getting best available security without knowing which cipher to use
Ray Dillinger wrote:
> Thoughts, Ideas, Comments?
Well, you said nothing new, did you ?
------------------------------
Date: Fri, 06 Oct 2000 08:49:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Blowfish uses big endian (according to OpenSSL and GnuPG)
Tom St Denis wrote:
> Actually I am rather sure that "little endianess" is understood.
AFAIK Blowfish uses big endian.
In other words: your CryptoBag and Schneiers reference
implementation both dont specify it, and both GnuPG and
OpenSSL agree about using big endian for Blowfish.
------------------------------
Date: Fri, 06 Oct 2000 09:01:06 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: TEA
David Wagner wrote:
> Runu Knips wrote:
> >Btw, there is a very good russian cipher, GHOST.
> I'm not sure I'd call it "very good".
Then read it as 'still very secure', especially if one remembers
when it was developed.
> It hasn't seen much scrutiny in the open world, and I wouldn't
> recommend it for use.
Maybe not the open world, but AFAIK the russians have very good
cryptographers, too, and Schneier commented in his AC that a
round of GHOST looks weaker than a round of DES, on which its
design is based, but you have 32 instead of 16 of them, and
they can be implemented far faster in software. Together with
the fact that it uses 256 bit keys its security seems to be
still very good.
In fact I just noted GHOST because the OP is a russian.
> Use a trusted cipher; 3DES, if you can afford it, or AES, if not.
I don't understand why you trust 3DES and Rijndael more than
Blowfish or Serpent, especially because NIST said explicitly
that Serpent offers more security than AES/Rijndael, and the
OP asked for a _SIMPLE_ cipher.
------------------------------
Date: Fri, 06 Oct 2000 09:18:53 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES
Scott Craver wrote:
> I know I have no authority to decide these things, but I
> strongly feel that "AES" should be pronounced, "uh-YES."
Americans which have problems to spell 'Rijndael' and
'AES' should just use 'Twofish'. First its an american
product ;-) and second there's surely no spelling
problem ;-))))
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES
Date: Fri, 06 Oct 2000 08:29:13 +0100
Runu Knips 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."
>
> Americans which have problems to spell 'Rijndael' and
> 'AES' should just use 'Twofish'. First its an american
> product ;-) and second there's surely no spelling
> problem ;-))))
So what exactly is a "Twof", and how does one act like one? ;)
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
Date: Fri, 06 Oct 2000 06:05:45 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: CRYPTON site (was Re: It's Rijndael)
=====BEGIN PGP SIGNED MESSAGE=====
John Savard wrote:
> On Wed, 04 Oct 2000 19:03:21 +0100, David Hopwood
> <[EMAIL PROTECTED]> wrote, in part:
>
> >To answer John Savard's question, the CRYPTION 1.0 paper is at
> >
> > http://crypt.future.co.kr/~chlim/pub/cryptonv10.ps
> >
> >and CRYPTON 0.5 (the AES candidate) at
> >
> > http://crypt.future.co.kr/~chlim/pub/cryptonv05.ps
>
> Well, I knew they were supposed to be at crypt.future.co.kr, but I
> have not had success in reaching those URLs.
crypt.future.co.kr (203.248.159.14) isn't responding to pings
(which is wierd because I use NetMind to tell me about broken links,
and it didn't tell me about this one).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOd1dazkCAxeYt5gVAQFb/gf8DtspijT/qNCVVSNrew6ZIK9h1wHLj0KO
Pk7hdfPc3L8xrUkLmCY0htp2K192DgMOpaBKUYPBw+FbDT1RaTv5+B5/x89AQE/c
DaEbx1rYTO228zWHH5apPHvdfTd3xF9XNJ+G8AibMX59KASi7GO4KSb3dOBwAHJJ
TlcXx3icrnJyJiDhYvrj2CmvTjf04J0GLs3WB+XBAR4pSl9OihnIj47NRJMESh/4
Q8FsCi72yzU8cflaTxsWjRuyd816ZOzihwjeDtGV+eU4p3wL2RJOpdRgJEpbh3el
t965jjan7aDnxAM4gudhcZ/5YbBVGiSqYYpt1lF+mUUYqIVfFi11yQ==
=cUED
=====END PGP SIGNATURE=====
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Rijndael test vectors
Date: Fri, 6 Oct 2000 08:43:41 +0100
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 3 Oct 2000 23:11:41 +0100, "Brian Gladman"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >A world I hope we can remove by getting the specification right on such
> >matters.
>
> I'm still miffed that the specification for Rijndael - even the
> current version - does not exhibit the S-box. That it happens to be
> the multiplicative inverse on GF(2^8) followed by a bitwise matrix
> multiply is very nice background material, but prospective
> implementers ought not to be expected to jump through hoops of
> advanced mathematics.
>
> Of course, one still needs to perform a simpler operation in GF(2^8)
> to do the Mix Column step, but *that* operation is a straightforwards
> one that is also done in computing CRCs, so the mechanical procedure
> for it is commonly documented.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Rijndael test vectors
Date: Fri, 6 Oct 2000 08:47:26 +0100
"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 3 Oct 2000 23:11:41 +0100, "Brian Gladman"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >A world I hope we can remove by getting the specification right on such
> >matters.
>
> I'm still miffed that the specification for Rijndael - even the
> current version - does not exhibit the S-box. That it happens to be
> the multiplicative inverse on GF(2^8) followed by a bitwise matrix
> multiply is very nice background material, but prospective
> implementers ought not to be expected to jump through hoops of
> advanced mathematics.
I am uncertain of your concern here.
I had no problem implementing from the specification in this area (except
for the fact that the first report got the bit order inverted).
In what form do you think it should be presented?
Brian Gladman
------------------------------
Date: Fri, 06 Oct 2000 06:24:08 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: It's Rijndael
=====BEGIN PGP SIGNED MESSAGE=====
Volker Hetzer wrote:
> Mok-Kong Shen wrote:
> > Runu Knips wrote:
> > > If there would be another such contest in future, I would
> > > vote for making the round count a parameter, so everybody
> > > can choose higher or lower security, as they wish. This
> > > way one could select a higher number of rounds if one
> > > wishes. I don't know how much such a concept would
> > > actually cost in hardware implementations.
> >
> > I have expressed exactly the same wish several times.
> > There seems to be no reason why it can't be very readily
> > put into the standard.
>
> The AES's guys argument was that you can't simply attach or
> trim rounds without affecting key schedule and perhaps other
> properties too. So, each proposed number of rounds has to
> be analysed.
> Unless round flexibility is *designed* into the algorithm
> as proposed by Runu, modifying the round number makes
> IMHO little sense.
While that argument might be correct for some algorithms, it's wrong
for Rijndael; the key schedule works perfectly well as defined in the
spec for any number of rounds, and given the structure of the cipher
there's no reason to believe that any other constraint on the number of
rounds is necessary.
The performance will of course change, but it's quite easy to extrapolate
from the existing performance analyses. (If, for example, the number of
rounds was changed to 10/14/18 for 128/192/256-bit keys respectively, the
speed and hardware requirements of the 10 and 14-round variants would
already have been analysed.)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOd1hvzkCAxeYt5gVAQGouAf9Gz8IeqRUtZNxCOtg8x9m+doweb2qA2XV
bUaoMul52q2bIDFVzZozKzGGf3Mbm9lHpZrqhpPKEXbOVooQ5QB1JwL8Tqfh24ea
qjVgjWY1/U6oIozdoDmxXRXBLYCyyQwSReDIsDNXI0LkjrFH3ZeM4VN3hmtzIXh3
2HiEECU2EU5Hom5U2WuRJKHo4BMxJYDVdq7kl5BWlGsMwU5OMKTl/i6OOSPemhle
tJS6e2T3IkSBvZIju8B+ma2lvOueGf+7/Wl59ICVmVPO296jMmnQQa+N4qGvhfXE
m3rE4oJF4GNkZAVLnAOOvUhfMMQY7Sw10QVM3Dgf0/umOmpLJY5mGg==
=oOBa
=====END PGP SIGNATURE=====
------------------------------
From: "P.C. Teo" <[EMAIL PROTECTED]>
Subject: Suggestion for Digital Cash System
Date: Tue, 3 Oct 2000 16:10:05 +0800
I am going to implement a Digital Cash System. Any suggestion of current
existing Digital Cash System?
I need a cost effective system. Any popular system?
Thanks
------------------------------
Date: Fri, 06 Oct 2000 10:02:51 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Doug Kuhlman wrote:
> Mok-Kong Shen wrote:
> > I have the impression that increasing rounds is no problem
> > for Rijndael. If this is done by its own team, it appears
> > to be not too risky in 'extrapolating' to say that the
> > result would also be o.k. just as at the present. Those
> > who are very conservative could apply a safety factor
> > to take into account of any presumed eventuality, I suppose.
> At the complete sacrifice of interoperability (as it's currently set
> up). And a loss in speed. For a questionable increase in security.
Agreed. The main benefit of the standard is the interoperability,
and this is lost if you modify the algorithm.
------------------------------
** 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
******************************
