Cryptography-Digest Digest #628, Volume #11 Tue, 25 Apr 00 12:13:02 EDT
Contents:
Re: The Illusion of Security (Jonathan Thornburg)
Re: Magnetic Remenance on hard drives. (Jonathan Thornburg)
My perfect 1MB cipher !!! Unbreakable !!!! (Eternal Troll)
Re: sci.crypt think will be AES? (Runu Knips)
Re: The Illusion of Security (Guy Macon)
Re: Can a password be to long? (Runu Knips)
Re: suggested change to cb (Mark Wooding)
Re: Requested: update on aes contest (Jonathan Thornburg)
Re: sci.crypt think will be AES? (David Blackman)
Re: Requested: update on aes contest (Jonathan Thornburg)
Re: Tutorial on text encryption ([EMAIL PROTECTED])
Re: papers on stream ciphers (Tom St Denis)
Re: sci.crypt think will be AES? (Richard Parker)
Re: AES Style CAST Cipher (Tom St Denis)
Re: AES Style CAST Cipher (Tom St Denis)
Re: quantum computation FAQ? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: The Illusion of Security
Date: 25 Apr 2000 11:01:28 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
[[ many interesting and cogent comments ]]
I think people interested in this thread might find the article
Ross Anderson
"Why Cryptosystems Fail"
Originally published in Proceedings of the First ACM Conference on
Computer and Communications Security (11/93) pp 215 - 227
online at http://www.d.shuttle.de/isil/crypt/txt/wcf.html
of great interest. I'll quote the abstract here:
Designers of cryptographic systems are at a disadvantage to most other
engineers, in that information on how their systems fail is hard to
get: their major users have traditionally been government agencies,
which are very secretive about their mistakes. In this article, we
present the results of a survey of the failure modes of retail banking
systems, which constitute the next largest application of cryptology.
It turns out that the threat model commonly used by cryptosystem
designers was wrong: most frauds were not caused by cryptanalysis or
other technical attacks, but by implementation errors and management
failures. This suggests that a paradigm shift is overdue in computer
security; we look at some of the alternatives, and see some signs that
this shift may be getting under way.
Enjoy,
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Which countries [only 5 of them] have the death penalty for children?
A: Iran, Nigeria, Pakistan, Saudi Arabia, and United States
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Magnetic Remenance on hard drives.
Date: 25 Apr 2000 11:08:04 +0200
In article <[EMAIL PROTECTED]>,
Thor Arne Johansen <[EMAIL PROTECTED]> wrote:
>I certainly have no malicious objectives when I argue that overwritten
>data is unrecoverable. My arguments are based on the lack of public
>documentation of successful recoveries of overwritten data.
People interested in this might enjoy
> ## http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
>
> Secure Deletion of Data from Magnetic and Solid-State Memory
>
> Peter Gutmann
> Department of Computer Science
> University of Auckland
> [EMAIL PROTECTED]
>
> This paper was first published in the Sixth USENIX Security Symposium
> Proceedings, San Jose, California, July 22-25, 1996
>
> I am currently working on an update to this paper which is about twice
> as long as this one, goes into a lot more detail (including background
> information and explanations which were too long for this paper), and
> covers new technology which has appeared since 1996, especially in
> terms of recovering data from memory. I expect to have it available in
> the second quarter of 1999.
>
> Abstract
>
> With the use of increasingly sophisticated encryption systems, an
> attacker wishing to gain access to sensitive data is forced to look
> elsewhere for information. One avenue of attack is the recovery of
> supposedly erased data from magnetic media or random-access memory.
> This paper covers some of the methods available to recover erased data
> and presents schemes to make this recovery significantly more
> difficult.
>
> [[...]]
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Which countries [only 5 of them] have the death penalty for children?
A: Iran, Nigeria, Pakistan, Saudi Arabia, and United States
------------------------------
Date: Tue, 25 Apr 2000 11:10:34 +0200
From: Eternal Troll <[EMAIL PROTECTED]>
Subject: My perfect 1MB cipher !!! Unbreakable !!!!
[EMAIL PROTECTED] schrieb:
> This is the biggest disinformation in history...all Public
> Product Ciphers are week and vulnerable...
Ah, If we're in this theme: I've found the new mega-secure
1 MBit unbreakable cipher ! It will be unbroken even if
you have a supercomputer and 10**(1 million) years of
time ! You don't believe it ? Just try to break this:
0000000 8b 25 50 c2 79 87 16 b3 6a 93 5a a4 69 fd 54 2b
0000020 92 c3 f2 c1 c7 65 be ae b7 af e9 f7 a1 51 4f 30
0000040 62 66 27 98 a9 3d 53 cd 65 87 29 ef 1c 83 7b 47
0000060 73 49 ed 16 e9 31 5d dc 4a 84 62 45 a9 e7 2b 9d
0000100 65 75 0c 10 0c cd 67 a6 c7 ee a4 5e a4 75 5c 45
0000120 90 bf f3 c0 78 a6 3a 75 1d 33 bc 21 ee d6 e8 f2
0000140 d9 4c 15 34 0e cf 48 a7 b3 46 11 65 47 22 05 99
0000160 49 a0 76 ae ec 0a 31 48 c6 d9 2d 71 6a 12 e4 ad
0000200 4e 1e d7 42 50 89 ee c3 63 a6 eb 6c b6 95 1b f2
0000220 b6 91 bc cc 61 ba 63 5f 0d 8f f3 a8 9c 91 3a 56
0000240 d8 c5 bd ae c8 a1 d6 ae b7 04 9c 78 ac c8 cf 2b
0000260 cd ac 5b 86 cf c9 31 a0 f8 58 9a 27 ba 96 e5 2d
0000300 d7 84 65 7d 3e 04 b6 c6 5e b1 de 0e 79 54 8d 14
0000320 22 42 a6 73 49 61 6d b3 e9 bb d6 2f cc c4 ff 5d
0000340 c9 8d eb 01 e0 09 4a e6 71 a9 02 62 97 6e 96 fd
0000360 a7 51 bc 7b 1e 56 11 fd 1f 30 00 f9 49 7c d6 ae
(I *love* the Linux random device)
------------------------------
Date: Tue, 25 Apr 2000 11:16:31 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Tom St Denis wrote:
> Why I like Twofish. It's fast, it's compact, it's versatile (speed/size
> tradeoffs), it's designed sanely. It's also very good choice for
> hardware. It's also secure the best attack breaks (without whitening)
> only 6 rounds and doesn't work against the full algorithm.
Hey another Twofish fan ! :)
I'll like it most of all AES candidates, too. You've forgot another
point: its the AFAIK only one which is free NOW (no matter if it
will be the AES winner, or not).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: The Illusion of Security
Date: 25 Apr 2000 05:25:17 EDT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>
>On 25 Apr 2000 01:55:50 EDT, in <8e3c16$[EMAIL PROTECTED]>,
>in sci.crypt [EMAIL PROTECTED] (Guy Macon) wrote:
>
>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>>>If we get a cipher executable off the net, we really have no idea what
>>>we get. But if we must assemble and link source code to use the
>>>cipher, we will be part of a remarkably small group. So these are
>>>also not solutions.
>>
>>What do you think of the solution to this particular problem proposed at
>>[ http://www.ciphersaber.gurus.com ]?
>
>It would help me to know what you think the solution was. Since I
>think only a small group would even compile source, I expect it would
>be an even smaller group who would actually construct the source
>themselves. Many of those who could do that might disagree with the
>cipher design and so not want to. That doesn't sound like a solution
>for society, but some hobbyists might like it.
>
Sounds about right. I sometimes forget that most people aren't like
me, my biologist wife, or my engineer buddies.
It has crossed my mind to write up a Ciphersaber Excel spreadsheet...
------------------------------
Date: Tue, 25 Apr 2000 11:24:24 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Can a password be to long?
John wrote:
> I know passwords can be to shrot, but I recall reading
> somewhere, a long time ago, about being to long. Is this true.
Yes, if the program is written poorly you might overrun a buffer.
This is the so-called overflow attack which allows to get control
over setuid root programs, or network services on different
machines.
But the algorithms themselves never can get too much password
input. If they're only defined for certain inputs, they just
cut the rest.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: suggested change to cb
Date: 25 Apr 2000 09:35:35 GMT
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> How about dynamically allowing various chaining methods.
> Something like:
> CBC(void *in, void *out,cipher_state *state, *cipher(...))
> Or port it over to C++ and encapsulate the extras.
Adding block chaining modes over the top of a generic cipher interface
strikes be as a good way of reducing performance. The extra layer of
indirection for each block encryption is a fairly high price to have to
pay.
In Catacomb[1], I implemented modes as big chunks of C macros which
built specialized mode implementations for a given cipher and then
wrapped generic interfaces around them. This seems to work extremely
well.
Something similar could be done in C++, I don't doubt. I couldn't see
the advantage myself.
[1] http://www.excessus.demon.co.uk/misc-hacks/#catacomb There are
known bugs in the current version, and I foresee great big interface
changes in the next release, in particular to the key management
stuff.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Requested: update on aes contest
Date: 25 Apr 2000 11:42:31 +0200
In an article whose nested quoting overflowed my mental stack
(but I don't think caused a buffer-overrun security breakin :) ),
someone suggested:
> Along with AES I propose that a prng be proposed. Say a counter mode
> based on the AES cipher. Just so the document is complete.
Getting a *good* cryptographic PRNG from a cipher isn't that simple:
there are a lot of subtlties. See
J. Kelsey, B. Schneier, D. Wagner, and C. Hall
"Cryptanalytic Attacks on Pseudorandom Number Generators"
Fast Software Encryption, Fifth International Workshop Proceedings
(March 1998), Springer-Verlag, 1998, pp. 168-188.
online at http://www.counterpane.com/pseudorandom_number.html
for an interesting discussion. The abstract is both short and
informative; I'll quote it here:
In this paper we discuss PRNGs: the mechanisms used by real-world
secure systems to generate cryptographic keys, initialization vectors,
"random" nonces, and other values assumed to be random. We argue that
PRNGs are their own unique type of cryptographic primitive, and should
be analyzed as such. We propose a model for PRNGs, discuss possible
attacks against this model, and demonstrate the applicability of this
model (and our attacks) to four real-world PRNGs. We close with a
discussion of lessons learned about PRNG design and use, and a few
open questions.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"Washing one's hands of the conflict between the powerful and the powerless
means to side with the powerful, not to be neutral." - Freire / OXFAM
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Date: Tue, 25 Apr 2000 19:47:41 +1000
Tom St Denis wrote:
>
> I think Twofish will win the AES contest simply because it's the best we
> can see so far.
>
> Tom
Serpent is also nice. A bit slower on desktops and servers, but desktops
and servers are so fast that it is ok for most applications. Probably
very quick in dedicated hardware, which is important for some
applications. More rounds than anything else, which makes clueless
people like me think it must be very secure :-)
RC6 and Rijndael don't seem to have enough "headroom", ie not enough
extra rounds above the number that have been (partially, theoretically)
cracked so far. Maybe Mars as well. That might be a worry if we want AES
to stay secure for a long time. Rijndael is otherwise fast and nice, so
Rijndael with a few more rounds would make sense, as suggested by Bruce
Schneier and probably others. I'm not sure if that kind of change is
allowed at this late date.
RC6 and Mars look difficult on absolute low end CPUs. I'm not sure how
important that really is, but it was one of the big things in the call
for AES candidates, so i guess it will carry a lot of weight. It also
looks hard to do absolute high end dedicated hardware for these same
two. I think they're both in trouble.
So Twofish or Serpent.
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Requested: update on aes contest
Date: 25 Apr 2000 11:49:55 +0200
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> you don't need to "see" the innards of an IC implementation
> any more than you need to "see" the binary machine code generated
> from the high-level-language program. In fact the IC logic is
> probably generated by a "silicon" compiler these days. You can
> look at the source code (assuming cooperation from the vendor) in
> both cases, or you can run functional tests or validation in both
> cases.
The problem is, hardware can have trojan-horse backdoors in it which
are essentially impossible to spot using black-box functional tests.
See
http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
for an informative (and very amusing!) example of this by none other
than Henry Spencer himself:
HS> Suppose one built a 3DES accelerator chip
HS> so that, if and only if:
HS>
HS> (a) the chip is doing near-continuous encryptions at high speed, and
HS> (b) the keys are changing every packet or two, and
HS> (c) the chip detects -- via a simple mechanism like a little hash table --
HS> a key which has appeared before, recently, and
HS> (d) this key has not been marked "compromised" in the hash table, and
HS> (e) an internal 16-bit packet counter is all-1s,
HS>
HS> then
HS>
HS> (!) mark the key compromised in the hash table, XOR the key with the
HS> string "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!", prefix it with a
HS> random-looking constant bit pattern, and sprinkle the resulting bits into
HS> the encrypted data, in a haphazard but deterministic pattern.
HS>
HS> This is, of course, an encryption error. But rules (a)-(e) make it
HS> essentially irreproducible, so it won't happen a second time (and will be
HS> quite difficult to reproduce even in a test setup). Almost certainly it
HS> will get written off as a random error, and the affected packet will be
HS> re-processed correctly and re-sent, and all will be well.
HS>
HS> Except that an eavesdropper on the high-speed wire just looks for the
HS> constant bit pattern in the right places in a packet, and (almost) every
HS> time he sees it, he's nabbed an encryption key.
The conclusion is that Ken Thompson's class compiler trojan-horse hack
( http://www.acm.org/classics/sep95/ , also at
http://www.cs.umsl.edu/~sanjiv/sys_sec/security/thompson/hack.html )
can be applied to hardware, too.
In other words, you need full oversight of the hardware "source code"
(both the higher-level CAD software and the full chip layout) in order
to be able to trust hardware.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"Washing one's hands of the conflict between the powerful and the powerless
means to side with the powerful, not to be neutral." - Freire / OXFAM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Tutorial on text encryption
Date: Tue, 25 Apr 2000 10:09:39 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Joseph Ashwood wrote:
> Except it's non-invertable.
XOR rand() is as non-invertable as OR 0xFF is ;)
it should be:
data[i] = data[i] XOR (key[i] = rand());
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOQVStjBaTVEuJQxkEQInTQCg50SRICr+RYYEs9fiWMY62OEildIAoKhM
mAD1eO7runWxKlOzr8zOwjPl
=EnG/
=====END PGP SIGNATURE=====
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: papers on stream ciphers
Date: Tue, 25 Apr 2000 10:18:25 GMT
Joseph Ashwood wrote:
>
> >> For an attack XOR has several useful properties, the most
> >> important of which being that if one knows the plaintext,
> >> one can easily encrypt a new message to the same
> recipient
> >> with the same key, without determining the key.
> > This is pure garbage. If my output is pure random junk
> and I xor it
> > against the plaintext I have a provably secure system.
> First on what grounds do you consider it pure garbage?
> Solely on the grounds that you can think of no other attack
> on my theory? My theory has very solid backing, perhaps a
> quick example:
> Known plaintext: 0xDEADBEEF
> Known ciphertext: 0x12345678
> Pad(previously unknown):0xCC99E897
> New message: 0xA38DA7ED
> New Ciphertext (encrypted with the same pad so on decryption
> it will make sense to the reader): 0x6F144F7A
>
> Additionally how do you pretend to generate this "pure
> random junk"? Please see the thread on randomness in Quantum
> Cryptography where it is stated that Kolmogorov proved that
> you cannot prove randomness.
Are you saying to use the same pad twice?
So basically you have broken all stream ciphers right now since xor is
just the worse thing you can do? BTW feistel ciphers normally use xor
too, so you just broke DES, Blowfish, CAST, Twofish, ....
Tom
------------------------------
Subject: Re: sci.crypt think will be AES?
From: Richard Parker <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2000 10:22:46 GMT
Runu Knips <[EMAIL PROTECTED]> wrote
> Hey another Twofish fan ! :)
>
> I'll like it most of all AES candidates, too. You've forgot another
> point: its the AFAIK only one which is free NOW (no matter if it
> will be the AES winner, or not).
Actually, the authors of four of the five AES finalists have stated that
their algorithms are available for free, regardless of which candidate is
selected as the AES winner. Even better, three of the five finalists are,
for all practical purposes, in the public domain. Only RSA, the owner of
RC6, has declined to make a similar statement. Here are the statements from
the other four finalists:
MARS
"..we are making MARS available on a royalty-free basis, worldwide,
regardless of AES outcome."
<http://csrc.nist.gov/encryption/aes/round2/AESAlgs/MARS/mars-ip-update.pdf>
<http://www.tivoli.com/news/press/pressreleases/en/2000/mars.html>
Rijndael
"Rijndael is available for free. You can use it for whatever purposes you
want, irrespective of whether it is accepted as AES or not."
<http://www.esat.kuleuven.ac.be/~rijmen/rijndael/>
Serpent
"Serpent is now completely in the public domain, and we impose no
restrictions on its use."
<http://www.cl.cam.ac.uk/~rja14/serpent.html>
Twofish
"Twofish is unpatented, and the source code is uncopyrighted and
license-free; it is free for all uses."
<http://www.counterpane.com/twofish.html>
-Richard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES Style CAST Cipher
Date: Tue, 25 Apr 2000 10:25:51 GMT
Mark Wooding wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > I have one question... If you look at my source I have the PHT then the
> > key mixing... should it be the other way around? I just left it like so
> > because I don't know which is better...
>
> 1. Comments on cipher structure
>
> Block cipher design isn't really my field. That's never made me keep my
> opinions to myself yet, though.
>
> Your structure reminded me a bit of Twofish (with the PHTs to double the
> Feistel block width, and the 4 8x32 S-box results XORed together). A
> brief comparison of your basic cipher structure with that of Twofish is
> interesting.
Actually I use 8 8x32 S-boxes, however my s-boxes are static and quite
abit bigger then thoses of Twofish.
> Twofish keeps most of its mess in its Feistel function -- there are just
> a couple of rotates outside to break up the byte structure some more.
> You've got your PHT and key mixing in the main cipher structure (a bit
> like Blowfish, in fact). Leaving that aside -- I suspect it's not
> terribly important -- the main difference I see is that Twofish treats
> its initial whitening step as addition of key material and follows it
> immediately with its serious diffusion step of rotation, S-box
> substitution, the MDS matrix and the PHT.
>
> By contrast, your cipher (which probably deserves a name at some
> point[1]) does the input whitening, a PHT and then more key mixing. I'd
> probably go as far as suggesting that you don't need input whitening in
> a block cipher which does key mixing directly rather than in the Feistel
> function -- see Blowfish for an example of how this works. I'd probably
> do the key XOR, PHT and then the Feistel function, once for each round,
> and then an output whitening step. If I were feeling paranoid, I'd put
> in a one-bit rotate after the PHT, rotating each half of the output in
> opposite directions, just to shunt the results of the carries around a
> bit more.
I can remove the pre-whitening step, but the rotations I don't feel will
make it any better. I am not doing parallel substitutions (like
Twofish?) of bytes I am doing 4 8x32 substitutions on each 32-bit input.
The obvious goal of the PHT is to propagate error just a little.
> 2. Comments on the code
>
> C programming really is my field.
>
> `memcpy' is a rotten way to convert bytes to words. It's thoroughly
> nonportable. Don't do it. As an example of a good, portable way to do
> this, visit http://www.excessus.demon.co.uk/misc-hacks/#mLib, fetch the
> latest version, and see the LOAD32 and STORE32 macros.
Actually in my CryptoBag I use portable methods, I was just lazy here.
I want to show off more the round functions then the overall code.
Point taken.
> `clrscr' is not a C function. It may be provided by some
> implementations but its use is nonportable. As an aside, clearing the
> screen (as I believe is the purpose of this function) is unnecessary and
> annoying.
When doing kiddie-analysis (i.e flipping bits) it's easier to focus on
the new output with a clear screen :)
> The `main' function returns an `int', not `void'. You must return a
> value from `main' -- if nothing better occurs to you, return zero.
>
> Read the comp.lang.c FAQ for lots of good advice about writing portable
> C.
I know, I know, I was just lazy.
> [1] A quick look at Wordnet suggested the name STAMP to me for no
> particularly good reason except that it was offered as a synonym for
> CAST.
Hmm... STAMP? Sure why not. I will touch-up the code and repost it as
STAMP :)
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: AES Style CAST Cipher
Date: Tue, 25 Apr 2000 10:49:20 GMT
I updated the source so if you want to still look at it...
http://24.42.86.123/stamp.c
Tom
Tom St Denis wrote:
>
> Mark Wooding wrote:
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > > I have one question... If you look at my source I have the PHT then the
> > > key mixing... should it be the other way around? I just left it like so
> > > because I don't know which is better...
> >
> > 1. Comments on cipher structure
> >
> > Block cipher design isn't really my field. That's never made me keep my
> > opinions to myself yet, though.
> >
> > Your structure reminded me a bit of Twofish (with the PHTs to double the
> > Feistel block width, and the 4 8x32 S-box results XORed together). A
> > brief comparison of your basic cipher structure with that of Twofish is
> > interesting.
>
> Actually I use 8 8x32 S-boxes, however my s-boxes are static and quite
> abit bigger then thoses of Twofish.
>
> > Twofish keeps most of its mess in its Feistel function -- there are just
> > a couple of rotates outside to break up the byte structure some more.
> > You've got your PHT and key mixing in the main cipher structure (a bit
> > like Blowfish, in fact). Leaving that aside -- I suspect it's not
> > terribly important -- the main difference I see is that Twofish treats
> > its initial whitening step as addition of key material and follows it
> > immediately with its serious diffusion step of rotation, S-box
> > substitution, the MDS matrix and the PHT.
> >
> > By contrast, your cipher (which probably deserves a name at some
> > point[1]) does the input whitening, a PHT and then more key mixing. I'd
> > probably go as far as suggesting that you don't need input whitening in
> > a block cipher which does key mixing directly rather than in the Feistel
> > function -- see Blowfish for an example of how this works. I'd probably
> > do the key XOR, PHT and then the Feistel function, once for each round,
> > and then an output whitening step. If I were feeling paranoid, I'd put
> > in a one-bit rotate after the PHT, rotating each half of the output in
> > opposite directions, just to shunt the results of the carries around a
> > bit more.
>
> I can remove the pre-whitening step, but the rotations I don't feel will
> make it any better. I am not doing parallel substitutions (like
> Twofish?) of bytes I am doing 4 8x32 substitutions on each 32-bit input.
> The obvious goal of the PHT is to propagate error just a little.
>
> > 2. Comments on the code
> >
> > C programming really is my field.
> >
> > `memcpy' is a rotten way to convert bytes to words. It's thoroughly
> > nonportable. Don't do it. As an example of a good, portable way to do
> > this, visit http://www.excessus.demon.co.uk/misc-hacks/#mLib, fetch the
> > latest version, and see the LOAD32 and STORE32 macros.
>
> Actually in my CryptoBag I use portable methods, I was just lazy here.
> I want to show off more the round functions then the overall code.
> Point taken.
>
> > `clrscr' is not a C function. It may be provided by some
> > implementations but its use is nonportable. As an aside, clearing the
> > screen (as I believe is the purpose of this function) is unnecessary and
> > annoying.
>
> When doing kiddie-analysis (i.e flipping bits) it's easier to focus on
> the new output with a clear screen :)
>
> > The `main' function returns an `int', not `void'. You must return a
> > value from `main' -- if nothing better occurs to you, return zero.
> >
> > Read the comp.lang.c FAQ for lots of good advice about writing portable
> > C.
>
> I know, I know, I was just lazy.
>
> > [1] A quick look at Wordnet suggested the name STAMP to me for no
> > particularly good reason except that it was offered as a synonym for
> > CAST.
>
> Hmm... STAMP? Sure why not. I will touch-up the code and repost it as
> STAMP :)
>
> Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: quantum computation FAQ?
Date: Tue, 25 Apr 2000 12:17:50 GMT
In article <8e31nf$tca$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> for some reason I really hate the handwaving explanations that
> reference "quantum parallelism." I think it's partially because I used
> to spout something along those lines before I knew anything, and was
> rightly made fun of for it.
Molnar said this because I wrote:
> The critical difference is that such logic would operate with a
>superposition of states, such that certain kinds of computations occur
>in parallel. Algorithms which can take advantage of this parallelism
>would make it possible to solve problems such as searching and
factoring
>in times which scale to polynomial rates, rather than requiring
>exponentially longer times, as the size of the numbers grow.
If I had said:
The critical difference is that such logic would operate with a
superposition of states, through a quantum phenomenon called
entanglement, which allows logic elements to see their inputs in an
Everettian many-worlds kaleidescope, exploring a logical superposition
of all possible inputs and producing a result through a Feynmann, sum of
histories effect when it returns to the the macro-world with coherency
collapse. Algorithms which can take advantage of this parallelism would
make it possible to solve problems such factoring in times which scale
to polynomial rates, rather than requiring exponentially longer times,
as the size of the numbers grow.
It would have been more accurate technically, but hardly more
comprehensible.
Web
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
