Cryptography-Digest Digest #418, Volume #14 Wed, 23 May 01 17:13:01 EDT
Contents:
Re: Best, Strongest Algorithm ("Tom St Denis")
Re: Ideas for project ("Tom St Denis")
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Joseph Ashwood")
Re: ECB plus padding instead of CBC? ("Joseph Ashwood")
Re: What's the use of the 4 additive constants in SHA-1 ("Simon Johnson")
Re: taking your PC in for repair? WARNING: What will they (Darren New)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Help with a message ("Amethyste")
Re: decorrelated bitsliced cipher ("Simon Johnson")
Great Free Encryption Software ("George Peters")
New type of cryptanalysis ("Simon Johnson")
Re: Help with a message ("Douglas A. Gwyn")
Re: survey ("Douglas A. Gwyn")
Re: survey ("Douglas A. Gwyn")
Re: CIA Kryptos last 97 characters ("Douglas A. Gwyn")
Re: What's the use of the 4 additive constants in SHA-1 ("Tom St Denis")
Re: survey ("Tom St Denis")
Re: decorrelated bitsliced cipher ("Tom St Denis")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Wed, 23 May 2001 18:56:13 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in message
news:<[EMAIL PROTECTED]>...
> :> [EMAIL PROTECTED] (Joseph Ashwood) wrote in
<OXFxVM$1AHA.190@cpmsnbbsa07>:
>
> : I bet you 1000$ if you publish serious analysis of Bicom and why it's
> : better than say CTR mode for encrypting messages you will get the fame
> : and glory you so desire.
>
> It certainly has some different properties - here is some of the upside:
>
> * Use of the same key on different messages is much better with BICOM, due
> to the whitening.
I can use the same 128-bit AES key for the rest of my life and not
compromise a CTR based system.
> * Bitflipping produces a huge error extension in BICOM - but none in
> counter mode.
This is NOT a feature of most applications. Think of a multimedia stream
that gets completely and forever garbled because 1/2500 of a second was
damaged....
> * BICOM compresses - files should be smaller, so there's less cyphertext
> for the attacker to look at and messages are brought closer to the
> unicity distance, so the likelihood of multiple correct-looking decrypts
> is increased.
Ah, but the avg. joe will use deflate (or mpeg, or ...) before encrypting
too. This is not a feature that CTR based system couldn't share.
> :> Let me state in a way you can understand. The NSA wants only
> :> people to use RIJNDEAL in weak ways. They may provide a
> :> list of programs that use RIJNDEAL in blessed ways. Matt has
> :> used RIJNDEAL but it wont be blessed since its not as weakly
> :> implimented as the NSA likes. He doesn't use nonbijective compression
> :> like PGP. He doesn't use padding thats nonbijective. It will
> :> encrypt any file. And any file can be uniquely decyrpted using
> :> any key. This is not the kind of implimentaion the NSA wants
> :> people to even know about. They don't even want people to
> :> know about the concept. Since it allows for strong encryption
> :> if uses in serial with another bijective encryption system.
> :> It does add in the information helpful for breaking as other
> :> methods do.
>
> : That's a fine paragraph. You lack proof for both assumptions.
>
> : 1) BICOM is secure
> : 2) BICOM is better than anything currently out.
>
> : I have listed alot of features of CTR mode over BICOM (again for
> : clarity sake)
>
> [snip 1-3]
>
> : 4. CTR is provably as secure as the underlying block cipher (assuming
> : the keys are all random).
>
> How is this an advantage over BICOM?
Um well BICOM is not provably secure as the block cipher. I would consider
CTR to have the advantage.
>
> [snip 5 & 6]
>
> : Yes, Bicom provides other things such as "bijectiveness" (which is the
> : entirely wrong word when talking about a block cipher).
>
> BICOM is not a block cypher.
I realize that. But when talking about ciphers (say in the same sentence)
saying "non-bijective" is a bad idea.
> : But BICOM does not provide any of the 6 above points.
>
> Yes it does.
Um no it doesn't. Did you read any of my points? Like seekable, random
access, error control, etc...? Afaik BICOM is a "all-or-nothing" scheme...
> : Further more problems with BICOM
>
> : 1. No proof of security.
>
> No proof for CTR mode either.
Um yes there is. If you had ever care to read up.
> : 2. Not provably more secure then CTR mode
>
> That depends on the assumptions and the attack model somewhat. If BICOM
> compresses the target text - and brute force is the best attack - it will
> be provably more secure than counter mode.
Why? Compressing stuff doesn't really make it any more secure. It just
makes the ciphertext smaller.
> : 3. Not seekable
> : 4. Not random access
>
> Those are the same point with different numbers.
I meant by #4 to say "can't skip errors". I was in a hurry... sorry.
> : 5. Not suitable for low end processors
>
> You mean it's /slightly/ more complex than Rijndael itself? That is true.
If it involves arithmetic encoding I doubt you would covince a developer for
a 8051 to use it. CTR involves xors...
> : 6. Not as simple as CTR
>
> That is only really a factor if you're having to write code.
> Since working implementations of both exist, it doesn't make much odds
> under many circumstances.
Um try implementing BICOM on a 8051 with 1kb of data and code memory.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Ideas for project
Date: Wed, 23 May 2001 18:58:01 GMT
"Simon West" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello,
> I am in the final few months of a Master's Degree
> conversion course in I.T. I am currently in the initial
> investigation stages of my final project
Masters in IT? What the heck... are you a librarian?
> which is in the area of Web Security and data encryption.
> So far I have acheived a general understanding of the
> basics of symmetric and asymmetric encryption and background
> history, legislation, etc but still have to get to grips fully
> with the number theory underlyingthe algorithms.
> This is acheivable.
> What I am seeking are ideas, from those of you more
> learned in the subject, as to suitable iteresting applications
> which could be developed during a two month project.
> I intend to learn Java in the course of the project.
> My current programming skills include Ada95,
> a little C++, HTML, XML and a little javascript.
> Any ideas that I could consider would be very much
> appreciated.
> Cheers,
> SIMON WEST.
Well typically I would suggest to read some texts like Applied Crypto. Then
I would suggest to write/break some cryptosystems (I don't mean ciphers I
mean the collection of tools). Since you seem to be short on time, how
about making a baby PGP clone? I would put alot of work into making it so
the average know-nothing could use it.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 23 May 2001 19:13:05 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<hJTO6.15884$[EMAIL PROTECTED]>:
>I can use the same 128-bit AES key for the rest of my life and not
>compromise a CTR based system.
I guess you can't read. BICOM uses RIJNDAEL with a 256 bit key.
Tom get a life your an asshole if your think some crappy implimentation
you dream up. Since you haven't coded it yet. Could even come close
to as secure using inferior CTR mod with a 128 bit AES key. You
don't even know how BICOM works. You still don't even see or
understand how a one byte output file could actaully represent
thousands of possible input messages. Where as CTR mode would
limit that to 256 possible messages.
You have to be dam careful useing a CTR system with same key
since you need to start at different point each time or you run
into the same problem when people use a OTP incorrectly.
Which meand you need some way to keep track of the new starting
point if you encrypt several files. Keep it up many even you
can learn something.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 23 May 2001 11:56:07 -0700
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joe and the other phony crypto gods
WOOOHOOOOOOO!!!!!!!!!! I've been declared a crypto god!!!!!!!!!! Now if only
I had a job as one.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 12:26:48 -0700
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>
> > Counter mode is a third option, and I think you've failed to completely
> > understand how it works (judging from what was said with regards to
> > tom's suggestion). However if you have to be able to survive the loss of
> > an unknown number of blocks Counter mode will simply not have any
> > remaining advantages over your mode or CBC. Given this I think Tom's
> > recommendation of Counter mode can be safely ignored.
>
> Count mode if I understand it is:
>
> (crypt(block-count as 16 byte bignum)) xor (crypt(16 byte data-chunk))
Actually it's crypt(block count as 16-byte numbers) XOR (data chunk)
You can shrink it my only using k bits of the encrypted counter, and some
say to only use one bit. So you've got an additional overhead of a 128-bit
add (which you could probably reduce to a 64-bit add and pad with zeros),
and an XOR. But regardless I think we agree that it is not entirely suitable
to your situation.
> > Assuming that you are looking at datagrams of no more than 4 Rijndael
> > blocks at a time, I believe your mode to be the best for your situation.
>
> Where did "no more than 4 Rijndael blocks" come from?
It came from the fact that to transfer an N-byte chunk with CBC (or any
other IV based encryption) requires N + block size space, while your idea
takes 4/3*N (round to block size) space. The collision occurs when both are
equal to four, so 3 blocks worth of data.
>
> > Since you expressed that you need to know what the number of the block
> > was you might instead consider changing the last 32-bits (or however
> > many bits you would need) to a counter,
>
> Actually this built in counter effect is a big plus for the count mode.
> But you couldn't turn the cruft-padding into count-padding, that way it
> would be predictable and hence useless or at least very much weaker.
Well the problem is not unpredictability, because attacking the cipher takes
an enormous amount of known-plaintext. Currently that line is the entire
output space, and I don't expect the requirements for Rijndael to shrink
into the doable range for quite some time, so honestly it's not worth
worrying about, the use of a 32-bit counter would not be highly detrimental
(provided that your data being transferred is less likely to collide than
1/2^32).
Joe
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: What's the use of the 4 additive constants in SHA-1
Date: Wed, 23 May 2001 21:02:50 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:S26O6.150816$[EMAIL PROTECTED]...
>
> "Vincent Ip" <[EMAIL PROTECTED]> wrote in message
> news:9eaaj4$qsf$[EMAIL PROTECTED]...
> > Hi all,
> >
> > I noticed that additive constants are used in many hash algorithms but I
> > don't know what's the design idea behind.
> > To introduce a message independent components for the message digest?
> >
> > Could anyone explain the design reasons?
>
> Simple. The nonlinear functions have fixed points (namely zeroes) so if
the
> data cancels out ever it will stick at zero.
>
> Try SHA without the constants and see the # of zeroes... I bet (not sure
off
> hand) it will be higher than expected.
>
> tom
>
On top of this.. I'd also like to conjecture (probably wrongly) that the
constants may have something to do with protection against differential
analysis.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they
Date: Wed, 23 May 2001 20:03:22 GMT
Jim Turner wrote:
> Two others to look at are LCC, which has a decent IDE, and MINGW,
> which is based on GNU but uses standard windows DLLs instead of a unix
> emulation DLL. There is also the DEV-C++ package which adds an IDE to
> MINGW or Cygwin.
Does it really need to be written in C?
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
This is top-quality raw fish, the Rolls-Rice of Sushi!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 23 May 2001 19:57:41 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <uA#7mx74AHA.278@cpmsnbbsa07>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Joe and the other phony crypto gods
>
>WOOOHOOOOOOO!!!!!!!!!! I've been declared a crypto god!!!!!!!!!! Now if
>only I had a job as one.
> Joe
>
I think you may be a ware that I am not an expert in English
but I am not sure I raised you to the "crypto god" level
but Since you can't anwser with facts and don't know much
about crypto. If it gets your rocks off go ahead a think of
yourself as a "phony crypto god" its about as close as you
will get.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Amethyste" <[EMAIL PROTECTED]>
Subject: Re: Help with a message
Date: Wed, 23 May 2001 20:32:09 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> a �crit dans le message news:
[EMAIL PROTECTED]
> I have to object to this. A proper Index of Coincidence
> is the ratio of the observed number of coincidences to the
> expected number of coincidences, and therefore is somewhere
> around 1.
You are probably right, it is useful to standardize IC.
But when I have a doubt about the language I prefer the Friedmann form.
(In fact I used a small cryptanalytic tool written in VB6 and I have not
included tables for IC, program and source at http://www.chez.com/notes)
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: decorrelated bitsliced cipher
Date: Wed, 23 May 2001 21:30:46 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:qxDO6.8803$[EMAIL PROTECTED]...
> Wouldn't a decorrelated bitsliced cipher be kinda neat?
>
> The idea is todo a GF mult using word registers movements instead of bit
> shifts...
>
> i.e take something like
>
> unsigned long gf_mul(unsigned long a, unsigned long b)
> {
> unsigned long result = 0;
> while (a) {
> if (a & 1)
> result ^= b;
> a >>= 1;
> if (b & 0x80000000ul)
> b = (b << 1) ^ 0xd59c382dul;
> else
> b <<= 1;
> }
> return result;
> }
>
> We change the if statements to logical stuff... i.e
>
> result[0..n-1] ^= b[0..n-1] & a[0]
> a[0] = a[1], a[1] = a[2], ...
> c = b[n-1]
> shift b[n-1] = b[n-2], b[n-2] = b[n-3], ...
> b[0..n-1] ^= polynomial[0..n-1] & c
>
> The idea is that the GF mult takes the same time regardless of the
operand.
>
> We could use this todo GF mults in GF(2^4)/p(x) where p(x) is some
> irreducible polynomial mod 2. That way the best differential accross the
> sbox would have a prob of 1/15 of occuring.
>
> The security would be based on the wide-trail design but the immunity to
> differnetial and linear cryptanalysis would be much much higher since the
DP
> bound is 1/15 not 1/4 over all keys.
>
> Of course this brings up the idea of using GF(2^8)/p(x) and get a bound of
> 1/255 but requires larger sboxes... (or no sboxes and use some linear
mixing
> that doesn't commute with GF(2)).
>
> This cipher could be fast. In fact cool idea. Make a 64-bit block cipher
> using eight bytes and doing GF mults in GF(2^8) and some linear transform
> that would rotate and shift the bytes around.
>
> What do you guys/gals think?
>
> Tom
>
Ace.. should be quite fast.. I'd keep the GF mults down to 2^4 though keeps
the speed up...
------------------------------
From: "George Peters" <[EMAIL PROTECTED]>
Subject: Great Free Encryption Software
Date: Wed, 23 May 2001 15:35:11 -0500
Two sites that contain great encryption products can be found at the
following:
http://www.datasecuritysolutions.com/download.htm. They have a public key,
a passphrase app (called Zamber) and a hard disk encryption tool for
freeware
as well as demos of their other products.
http://www.endecs.com/uenigma.zip. This is an entire suite of applications
including two file systems, email/ftp clients and point to point
communications.
Both sites are worth investigating.
Cheers,
GP
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: New type of cryptanalysis
Date: Wed, 23 May 2001 21:47:02 +0100
I don't know if I'm being an idiot.. but here might be a 'new' way to break
a cipher....
I call it "polynomial analysis"... its like linear analysis in the sense
that one makes an approximation.. it differs in the fact that rather than
using a linear approximation we use a polynomial. I haven't worked out the
subtleties yet (and this is probably where it screws up).. but here's how I
think it might work:
First, attack a single round: What we do is find a polynomial f(x) such that
f(x)=ax^r + bx^(r-1) + cx^(r-2).... in which ever finite field or ring is
suitable. a,b,c are the round keys. In order for this to work, we have to
solve the equation for a given r inputs.. so it stands to reason that we
have to find an equation that hold 'r' times... Now recovering these values
would be much like solving for decorrelation.. and that's exactly what I'm
attempting to do.. make an isomorphic decorrelated version of the cipher
which could be broken with something like boomerang.
Its food for thought, but probably wrong a numerous points =)
Simon.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Help with a message
Date: Wed, 23 May 2001 20:18:42 GMT
Robert Reynard wrote:
> I don't think so. I don't think William Friedman defined it that way either.
He did eventually, because it removes a contextual factor from
the interpretation.
> According to the Encylopedia of Cryptology, the Index of Coincidence (IC)
> for a random mixture of letters is 0.0385 and the IC for a typical plaintext
> message is 0.0667.
That's a mistake. Those are the "kappa" values.
> Expectation of occurrences, or coincidences, plays no part in the definition
> or calculation.
That's why that is not an Index of Coincidence.
The word "index" connotes comparison against a norm.
The definitive treatment of this is in Mountjoy's article on the
"bar" statistics in an old issue of NSATJ, unfortunately not yet
declassified (so far as I know). That would be a useful paper for
an FOIA request.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Wed, 23 May 2001 20:26:32 GMT
Mok-Kong Shen wrote:
> Would you please explain a bit on the meaning of 'stream
> ciphers that are not of the key-generator class'?
Basically, there is no subsystem that generates a
plaintext-independent key which is then combined
with the plaintext in a totally separate subsystem.
Note that when I phrase it that way, it is evident
what some weaknesses might be in key-generator
based systems.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Wed, 23 May 2001 20:21:53 GMT
Tom St Denis wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> > > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Tom St Denis wrote:
> > > > > Well my design is simple and faster than most other known block
> ciphers.
> > > > > Does that count?
> > > > No.
> > > > void encrypt(const char *key, char *data) { } // very fast and simple
> > > And you call me immature? Wow, you guys have high standards... double
> > > standards but high none the less.
> > I was making an important point. I'm sorry you missed it.
> I posted a complete algorithm and rough paper to talk about the decisions I
> made.
> Your reply was just immature and a poke. Sorry, what did I miss?
Think about it. I too posted a complete algorithm.
I didn't write a "rough paper" about it because it
is simply a counterexample to the idea that being
simple and fast gives the design merit.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CIA Kryptos last 97 characters
Date: Wed, 23 May 2001 20:30:42 GMT
[EMAIL PROTECTED] wrote:
> To me, that means that a simple substitution can transform the
> output from that table to the standard vig or beaufort table.
Yes, indeed. In fact I tried that, looking for step-by-1
use of the tableau, but found nothing useful.
If a "running key" is in fact used, there isn't enough
material to expect success without a lucky guess about
the key.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: What's the use of the 4 additive constants in SHA-1
Date: Wed, 23 May 2001 20:55:20 GMT
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:9eh4m7$4gf$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:S26O6.150816$[EMAIL PROTECTED]...
> >
> > "Vincent Ip" <[EMAIL PROTECTED]> wrote in message
> > news:9eaaj4$qsf$[EMAIL PROTECTED]...
> > > Hi all,
> > >
> > > I noticed that additive constants are used in many hash algorithms but
I
> > > don't know what's the design idea behind.
> > > To introduce a message independent components for the message digest?
> > >
> > > Could anyone explain the design reasons?
> >
> > Simple. The nonlinear functions have fixed points (namely zeroes) so if
> the
> > data cancels out ever it will stick at zero.
> >
> > Try SHA without the constants and see the # of zeroes... I bet (not sure
> off
> > hand) it will be higher than expected.
> >
> > tom
> >
>
> On top of this.. I'd also like to conjecture (probably wrongly) that the
> constants may have something to do with protection against differential
> analysis.
You're right, you are wrong. Think about it if both pairs are xored with 1
(a 1 bit) then it's a zero difference. The constants do not add in any
differences.
The best way to exploit it is without the constants you will see alot of
outputs have too many 0's then random... (i.e should be around 80 on avg).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Wed, 23 May 2001 20:56:43 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Tom St Denis wrote:
> > > > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]...
> > > > > Tom St Denis wrote:
> > > > > > Well my design is simple and faster than most other known block
> > ciphers.
> > > > > > Does that count?
> > > > > No.
> > > > > void encrypt(const char *key, char *data) { } // very fast and
simple
> > > > And you call me immature? Wow, you guys have high standards...
double
> > > > standards but high none the less.
> > > I was making an important point. I'm sorry you missed it.
> > I posted a complete algorithm and rough paper to talk about the
decisions I
> > made.
> > Your reply was just immature and a poke. Sorry, what did I miss?
>
> Think about it. I too posted a complete algorithm.
> I didn't write a "rough paper" about it because it
> is simply a counterexample to the idea that being
> simple and fast gives the design merit.
Fine be a jackarse.
You're not proving anything other than you have an insane ability to argue
irrelevent semantics.
My designs are actually based on some stuff I observed. I am trying to
learn stuff. I can't do it alone though. Foolish me to think others will
want to willingly help instead of use their time to belittle others. How
big you must feel. Bravo.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: decorrelated bitsliced cipher
Date: Wed, 23 May 2001 20:58:01 GMT
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:9eh6b0$16$[EMAIL PROTECTED]...
> This cipher could be fast. In fact cool idea. Make a 64-bit block cipher
> > using eight bytes and doing GF mults in GF(2^8) and some linear
transform
> > that would rotate and shift the bytes around.
> >
> > What do you guys/gals think?
> >
> > Tom
> >
> Ace.. should be quite fast.. I'd keep the GF mults down to 2^4 though
keeps
> the speed up...
Well that's the tradeoff. The bigger the field the more resistance you get.
With GF(2^4) a mult takes four iterations of the main loop. You can do
shifts by just moving words from one place to another, etc..
I have some C code todo this if you care to see.
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
