Cryptography-Digest Digest #634, Volume #14 Sun, 17 Jun 01 10:13:00 EDT
Contents:
Re: IV (Tim Tyler)
Re: Tell me could this one-way function be somewhat secure ("Simon Johnson")
Re: hello? ("Simon Johnson")
Re: CipherText E-mail encryption (Bryan Olson)
Re: CipherText E-mail encryption ("Simon Johnson")
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Tom's base64 code (was Re: CipherText E-mail encryption) (Fat Phil)
Re: Tom's base64 code (was Re: CipherText E-mail encryption) (Fat Phil)
Re: Tom's base64 code (was Re: CipherText E-mail encryption) ("Tom St Denis")
Bizzare Cryptanalysis ("Simon Johnson")
Re: Uniciyt distance and compression for AES (Tim Tyler)
FIPS-140 statistical test for any length of bits? ("Dobs")
Re: FIPS-140 statistical test for any length of bits? ("Tom St Denis")
Re: FIPS-140 statistical test for any length of bits? (DJohn37050)
Re: FIPS-140 statistical test for any length of bits? ("Dobs")
Re: National Security Nightmare? ("Simon Johnson")
Re: best encryption? ("Simon Johnson")
Re: FIPS-140 statistical test for any length of bits? ("Dobs")
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: The 94 cycle 64-bit block cipher :-) ("Simon Johnson")
Re: Bizzare Cryptanalysis (Fat Phil)
Re: best encryption? (SCOTT19U.ZIP_GUY)
Re: The 94 cycle 64-bit block cipher :-) ("Tom St Denis")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: IV
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Jun 2001 09:52:55 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:>I think your summary says something different to the theorem - something
:>that is stronger - and is not actually supported by the theorem at all.
: Quite possibly! It _is_ a summary, after all, so it is impossible
: to include all the nuances. It's a judgement call which nuances are
: important enough to mention and which ones aren't.
At least the authors included a reference to the document which the
summary was supposed to represent.
I hope any future documents along similar lines would at least mention
the point in the "perceived disadvantages with CTR mode" section.
Since this is one of the major problems with leakage of plaintext
information in CTR mode, it seems prudent to at least mention it
in documents discussing the disadvantages of the mode.
As it stands, the fact that len(P) = len(C) gets listed in the "advantages
of CTR mode" section - and the fact that this completely gives away the
exact length of every single plaintext doesn't even get mentioned.
: While I agree that there might be some rare cases where CTR mode is less
: secure than CBC mode, I claim that (1) these are rare and unimportant,
...um - /every single message/ has it's *exact* length in the clear!
I don't see how this is either rare or unimportant.
: (2) the difference between the two modes will still be quite small,
...a document being one of 2^256 possibilities is "almost the same" as a
document being one of a possible 256?
Maybe it is if that "2^" is omitted - but those symbols make a bit of a
difference! ;-)
: and (3) in such scenarios even CBC mode is unlikely to be completely
: satisfactory anyway.
Very possibly. Encryption methods are rarely "completely satisfactory".
: There are plenty of other examples, too. For instance, you could note
: that "taking the last block of the ciphertext" forms a somewhat better
: MAC if you use CBC mode than if you use CTR mode. Does this mean that
: we should consider CBC mode significantly more secure than CTR mode?
: No, I don't think so.
Well, I think it was you who mentioned CTR mode being secure in the sense of
secrecy on this thread - so this seems like a change of subject from that.
There seems to be something of a difference from giving plaintext
information from every message to attackers on a plate, and the vague
possibility of adding a rather crappy short of MAC to the message with
slightly less effort.
This is an aside now - but I'm not familiar with the idea you are
describing. It sounds rather dumb. You don't know the last CBC block
until you have encrypted everything - in which case it's a bit late to
include it as a MAC inside the encryption. Including it /outside/ the
encryption appears to be a case of duplicating the last block - which
seems like a rather pointless exercise.
You /could/ get the last block, append it, and encrypt the message.
The advantage of doing that seems pretty slender. You could equally
well do that if you performed the second encryption in CTR mode.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Tell me could this one-way function be somewhat secure
Date: Sun, 17 Jun 2001 11:23:56 +0100
"Marko Lavikainen" <[EMAIL PROTECTED]> wrote in message
news:9gdm8n$2us$[EMAIL PROTECTED]...
> I was wondering that when using hash-function, there is always a change
for
> collision. So, could not one use, say, two hash functions with different
> properties.
Yes you could.. but i wouldn't advise it on the reasoning that you have
replaced one assumption (of whatever cryptosystem your designing) with two
because you are now forced to assume that two hashing algorithms are secure
instead of one. It only takes one of these hashes to get broken (in your
case, i'm not sure wether this is true for all constructions of this type)
for the system to be rended completely weak.
I think its wise to always reduce the number of assumptions in systems to
its bear minimum. So i'd just use a single hash with a bigger digest size.
Simon.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: hello?
Date: Sun, 17 Jun 2001 11:35:32 +0100
"wtshaw" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
> > > Tom St Denis
>
> > There is just too much of you around this board.
>
> Never is it so when someone pursues an intellectual passion to learn and
> expand what all might know. In spite of ups and downs, as crypto is why
> many are here, the rest of life can often merely be a distraction. The
> field deals with the supreme essence of ultimate knowledge, knowing what
> others cannot, and preserving uniqueness, preserving individual
> superiority in a personal kingdom. If bored....no, the true zealot is
> never bored as defeat directs one to realization and can spur activity in
> new directions.
Hear! Hear!
Simon.
> --
> In trying to get meaning from the TmV-OK saga, remember that
> those who do not learn from history are apt to repeat it.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sun, 17 Jun 2001 03:43:55 -0700
Tom St Denis wrote:
>
> "Bryan Olson" wrote:
[...]
> > I gave you the simplest cases that demonstrate the error.
> > Here's code:
> >
> > void show_bug(void)
> > {
> > long inlen, outlen;
> > static const unsigned char zeros[3];
> > unsigned char buff[9];
> >
> > for (inlen = 1; inlen < 4; ++inlen)
> > {
> > base64_encode(zeros, inlen, buff, &outlen);
> > printf("%ld zero octets encoded to length %ld string: %s\n",
> > inlen, outlen, buff);
> > }
> > }
>
> Hmm? In my test suite I replaced "fill with random" with "fill
> with zeros".
Why did you do that? I noted specific simple cases and provided C
source (written to your function's interface) that will feed those
cases to your encoder. Why won't you test those?
> I get a long string of zeros which magically decodes.
That doesn't make any sense. The encoded string should be
composed of printable characters; a long string of zeros is
not a possible encoding. Why should it decode, and to what?
> What is the problem with the code you are noting? Maybe I am just not
> seeing it.
There exist distinct octet strings for which the encoder produces
the same output. The three I've noted are:
the string of one octet, that octet holding the value zero,
the string of two octets, both holding the value zero,
the string of three octet, all three holding the value zero.
I have not seen the decoder. I suspect that for one of those
strings, encoding then decoding will return the original. If that's
correct, then for the other two strings, encode-decode will return an
octet string of of a different length from the original.
--Bryan
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sun, 17 Jun 2001 12:05:00 +0100
"Prichard, Chuck" <[EMAIL PROTECTED]> wrote in message
news:Vj8W6.1145$[EMAIL PROTECTED]...
> Its a demonstration.
>
> The feature is planned for implementation in a commercial release.
>
> The fixed data encryption key will be available only to one who has
> successfully decompiled the VB6 application. Because no such decompilers
> are
> presently available to the general public, its thought that making the
> key
> fixed in the demonstration copy was advantageous. A greater degree of
> simplicity is assured for the first time experience of the product.
>
> -C. Prichard
>
Cryptographically, your product most probably stinks.. but how much it
stinks is depedant on how sensitive the information you wish to encrypt
actually is. If your protecting from your kid sister.. XOR is probably
enough.. if you want to protect from us.. you'll have to do alot better...
Simon.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sun, 17 Jun 2001 11:10:42 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (David Wagner) wrote in
> <9gh468$26hd$[EMAIL PROTECTED]>:
>
> >Actually, CTR mode is a little _harder_ to use correctly than CBC mode,
> >because the consequences of inadvertently reusing an IV in CTR mode are
> >much more severe than the consequences of reusing an IV in CBC mode. I
> >would argue that it is an interesting open problem how to design modes
> >of operation that have the desirable features of CTR mode
(parallelizable,
> >extremely simple) yet have better robustness.
>
> Strange do I see cracks in your armour. Are you honestly starting
> to admit CTR may not be the mode of choice. Or are you starting to
> realize it will be poorly implemetned in most cases.
Note that the weakness Wagner is discussing is only relevant if you have a
fixed key over several messages.
> I don't think it an open problem. Speed and highly parallelizable
> encryption that is extrememly simple most likely can't be secure.
> especailly with zero error propagation as in CTR mode.
An OTP is blazing fast.
Tom
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: Tom's base64 code (was Re: CipherText E-mail encryption)
Date: Sun, 17 Jun 2001 14:15:19 +0300
David Hopwood wrote:
> - there is no check that the output does not overflow the buffer size
> (i.e. the only way to use this code safely would be for the calling
> code to calculate how long the output would be). This is a serious
> error, likely to lead to security bugs.
Would a helper function
size_t getB64ExpandedSize(size_t rawInputSize)
{
return (4*rawInputSize+1)/3+1;
}
quieten your objection to that bit?
I wouldn't say it was a 'serious' error. The client is almost always
responsible for ensuring written-to buffers are the right size.
"don't use gets, use fgets instead" fails if clients do
char*b=(char*)malloc(10);
char*x=fgets(b, 20, stdin); /* big big bad */
I'm just being picky, all your other points are spot on.
For reference, the last 15 months of my life have been spent removing
crappy bugs from ~20 man-years worth of crappy code written by people
who never code reviewed and never tested. And to be honest, when people
have been responsible for both passing a size, and allocation of a
buffer, I've never seen them mess up, even when there have been scaling
relations. The interface requires just enough thought that people do
actually think about it properly.
Phil
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: Tom's base64 code (was Re: CipherText E-mail encryption)
Date: Sun, 17 Jun 2001 14:19:36 +0300
David Hopwood wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > Why do they add the "=" symbol [in base64].
>
> That's a good question. I don't see any reason for the "=" padding
> (the length of the input is unambiguous even without it). Still,
> there's no point in changing the algorithm over such a small quibble.
I assume it's simply so that compressors can race forwards in chunks of
4, and only check if they've overrun by 1 or two bytes after they've
read 4 bytes from either their input stream or their memory buffer.
Probably classified as a 'programmer laziness' feature.
Phil
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Tom's base64 code (was Re: CipherText E-mail encryption)
Date: Sun, 17 Jun 2001 11:20:57 GMT
"Fat Phil" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> David Hopwood wrote:
> > - there is no check that the output does not overflow the buffer size
> > (i.e. the only way to use this code safely would be for the calling
> > code to calculate how long the output would be). This is a serious
> > error, likely to lead to security bugs.
>
> Would a helper function
>
> size_t getB64ExpandedSize(size_t rawInputSize)
> {
> return (4*rawInputSize+1)/3+1;
> }
> quieten your objection to that bit?
>
> I wouldn't say it was a 'serious' error. The client is almost always
> responsible for ensuring written-to buffers are the right size.
> "don't use gets, use fgets instead" fails if clients do
>
> char*b=(char*)malloc(10);
> char*x=fgets(b, 20, stdin); /* big big bad */
>
> I'm just being picky, all your other points are spot on.
>
> For reference, the last 15 months of my life have been spent removing
> crappy bugs from ~20 man-years worth of crappy code written by people
> who never code reviewed and never tested. And to be honest, when people
> have been responsible for both passing a size, and allocation of a
> buffer, I've never seen them mess up, even when there have been scaling
> relations. The interface requires just enough thought that people do
> actually think about it properly.
I agree my code was a bit callous. In my own defenece I did just hack it up
in a night. I wanted a Crypto DLL to play with and I couldn't find any.
Thanks for noting these things though, I will check for these types of
errors in the future.
Tom
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Bizzare Cryptanalysis
Date: Sun, 17 Jun 2001 12:31:34 +0100
Lets assume for a second that we can define a process by which we can
differentiate an algorithm. Now, since all algorithms we use are
deterministic and have a period of some description this would seem to imply
that there would also be a period to the differentiation series. Thus, we
can define a Maclaurin expansion for the algorithm..
I'm pretty sure extraction of a key could be performed from this expansion
and would be a nice way to attack algebraic ciphers.
Simon.
Simon.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Jun 2001 11:43:25 GMT
[EMAIL PROTECTED] wrote:
: Can we just go ahead and call this a dead thread that has turned into a
: catfight? Go ahead and take the parting shot - I'm not going to reply
: to this thread again.
As you wish. Farewell, then.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: FIPS-140 statistical test for any length of bits?
Date: Sun, 17 Jun 2001 14:00:39 +0200
Is it possible to test random numbers of any length of bits with FIPS-140,
or it has to be 20'000 bits? Is there possibility to change it for shorter
lets say 1'000 bits. How should I compute the required Intervals???
Best Regards
-M.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: FIPS-140 statistical test for any length of bits?
Date: Sun, 17 Jun 2001 12:12:18 GMT
"Dobs" <[EMAIL PROTECTED]> wrote in message news:9gi6fr$76s$[EMAIL PROTECTED]...
> Is it possible to test random numbers of any length of bits with FIPS-140,
> or it has to be 20'000 bits? Is there possibility to change it for
shorter
> lets say 1'000 bits. How should I compute the required Intervals???
> Best Regards
Typically 1000 bits is not enough for good statistical tests. 20'000 was
chosen as the minimum and indeed it is what people chose too. You can of
course change the tests to work on N bits as long as you change the expected
results.
Tom
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 17 Jun 2001 12:40:47 GMT
Subject: Re: FIPS-140 statistical test for any length of bits?
You can do stat tests on a bitstring of any length. FIP 140-1 apparently had
filters of 1 in a million (or so) and any stat ref can give you the numbers to
use for larger or smaller sizes.
Don Johnson
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: FIPS-140 statistical test for any length of bits?
Date: Sun, 17 Jun 2001 15:05:02 +0200
Thanks for answer. What do You mean by stat ref ? Do You know any Web page
where can I find it?
Użytkownik DJohn37050 <[EMAIL PROTECTED]> w wiadomości do grup dyskusyjnych
napisał:[EMAIL PROTECTED]
> You can do stat tests on a bitstring of any length. FIP 140-1 apparently
had
> filters of 1 in a million (or so) and any stat ref can give you the
numbers to
> use for larger or smaller sizes.
> Don Johnson
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Sun, 17 Jun 2001 14:18:48 +0100
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> JPeschel wrote:
> <snip>
> > No, Phil, the English of Americans and the British is one language.
> <snip>
>
> Barely.
>
> JM
I question that "Barely"... Lets compare the difference between the British
and American englishes and The difference between British English and
Japanesse....
If American English and british english is so barely the same language, then
why are you able to understand my writing?
Simon.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: best encryption?
Date: Sun, 17 Jun 2001 14:25:32 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Dirk Heidenreich) wrote in
> <9g1rnk$t4o$04$[EMAIL PROTECTED]>:
>
> >Hello,
> >
> >i am not in use to any security programms. But i am interested into how
> >to safe my data. I am looking for a very good programm, so which one
> >would you suggest? What is objective the best?
> >Thanks for your help.
> >
>
> Since you ask. If its for your own file security. I would
> use mine scott16u or 19u. If you have fairh in AES I would
> use BICOM
>
Note: Scotts technology is unanalysed. Un-analysed material is not trusted
in the crypto-community.
Simon.
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: FIPS-140 statistical test for any length of bits?
Date: Sun, 17 Jun 2001 15:21:04 +0200
Thanks for answer.Do you know where can I take this expected results from?
Any links?
-M.
Użytkownik Tom St Denis <[EMAIL PROTECTED]> w wiadomości do grup
dyskusyjnych napisał:C81X6.141774$[EMAIL PROTECTED]
>
> "Dobs" <[EMAIL PROTECTED]> wrote in message
news:9gi6fr$76s$[EMAIL PROTECTED]...
> > Is it possible to test random numbers of any length of bits with
FIPS-140,
> > or it has to be 20'000 bits? Is there possibility to change it for
> shorter
> > lets say 1'000 bits. How should I compute the required Intervals???
> > Best Regards
>
> Typically 1000 bits is not enough for good statistical tests. 20'000 was
> chosen as the minimum and indeed it is what people chose too. You can of
> course change the tests to work on N bits as long as you change the
expected
> results.
>
> Tom
>
>
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sun, 17 Jun 2001 13:31:29 GMT
>
> Cryptographically, your product most probably stinks.. but how much it
> stinks is depedant on how sensitive the information you wish to encrypt
> actually is. If your protecting from your kid sister.. XOR is probably
> enough.. if you want to protect from us.. you'll have to do alot
better...
>
> Simon.
>
>
As I have said, there is no real defense that can be implemented on the
computer.
So I maintain that the ONLY answer is to advocate removal of encrypted
data thought to be sensitive and vulnerable if the computer can be
accessed without your knowlege.
This approach immediately gets the user moving toward a more possibly
secure cryptosystem at the outset of his experience with the product.
I contend it is a responsible approach that has merit.
-C. Prichard
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: The 94 cycle 64-bit block cipher :-)
Date: Sun, 17 Jun 2001 14:32:57 +0100
"Phil Carmody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Well I feel honoured that you are archiving my stuff :-) Feel free to
> > download/repost/edit/whatever anything on my site. You can take my
source
> > and redistribute it if you want. (That's the point of sharing ya know
:-0).
>
> Sharing is good. Readers contributing back is even better.
>
> > I would appreciate comments on my upcomming ideas though. Even if you
don't
> > have something rigorous more than "oh neat". It's nice to just hear
from
> > others.
>
> Upcoming? Hmmm, I'd rather rewind the clock a few months if I may :-)
>
> I'm curious about your 3-hash actually.
> <<<
> for (r = 16; r < SIZE; r++) {
> t = W[r - 3] ^ W[r - 8] ^ W[r - 14] ^ W[r - 16] ^ r ^
> 0x9E379B93ul;
> W[r] = (t << 1ul) | (t >> 31ul);
> }
> >>>
>
> The ^r seems to be added to add a little more non-linearity, an the
> ^0x9E379B93ul seems to add some noise to those cases over-populated with
> zeros.
> However, the ^r only touches the bottom 7 bits (or thereabouts)
>
> Assuming x86 has a nice fast integer multiply, wouldn't
> ^(r*0x9E379B93ul)
> do a better job, potentially touching all bits?
>
>
> I'm also curious - why aren't the well-known CRC algorithms used as
> hashes? Is it that they aren't one-way? (they look reversable, but I've
> not studied them closely). Or is it just that they are too short, and if
> they were make longer they'd take too long to actually get all the bits
> mixed up? (so would be useless for a short message)
>
> Phil
There reversible. CRC's AFIAK are based on inversion in GF(2^w)/p(x).
Inversion can be reversed. :) (the choice of the field is speed related
IRRC)
Simon.
------------------------------
From: Fat Phil <[EMAIL PROTECTED]>
Subject: Re: Bizzare Cryptanalysis
Date: Sun, 17 Jun 2001 16:42:17 +0300
Simon Johnson wrote:
>
> Lets assume for a second that we can define a process by which we can
> differentiate an algorithm. Now, since all algorithms we use are
> deterministic and have a period of some description this would seem to imply
> that there would also be a period to the differentiation series. Thus, we
> can define a Maclaurin expansion for the algorithm..
>
> I'm pretty sure extraction of a key could be performed from this expansion
> and would be a nice way to attack algebraic ciphers.
The problem with this is that 'differentiation' is an operator which can
only sensibly be applied to continuous functions. The functions used in
all the crypto I can think of are discrete.
Phil
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: best encryption?
Date: 17 Jun 2001 13:39:21 GMT
[EMAIL PROTECTED] (Simon Johnson) wrote in
<9gib3v$i7i$[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Dirk Heidenreich) wrote in
>> <9g1rnk$t4o$04$[EMAIL PROTECTED]>:
>>
>> >Hello,
>> >
>> >i am not in use to any security programms. But i am interested into how
>> >to safe my data. I am looking for a very good programm, so which one
>> >would you suggest? What is objective the best?
>> >Thanks for your help.
>> >
>>
>> Since you ask. If its for your own file security. I would
>> use mine scott16u or 19u. If you have fairh in AES I would
>> use BICOM
>>
>
>Note: Scotts technology is unanalysed. Un-analysed material is not trusted
>in the crypto-community.
>
Actaully those that have analysed it where quit impressed. However
David Wagner cliamed to have looked at scott19u and said it was dead
due to his Slide Attack. Of course when some one tried and it failed
David Wagner had to admit he lied. He had assumed since I have not been
to any conference it had to be weak. I think lying is a way of life with
some of there guys. But it not a weak short keyed system like the AES
stuff its desinged to be strong. However the funny thing is that
Matt Timmermanns actaully used the AES winner in a strong bijective way
and the same crypto community fails to acknowledge just how great his
version of the AES RIJNDAEL cipher is. They either like Wagner pretend
to know nothing about it. Or they say a bijective compression encryption
program using full size RIJNDAEL blocks is not possible. But Matt did
it and its available to all. Includes the source code. Its bijective
nature makes it very suitable for use in series and with authentiacation.
I have posted batch strems here that show how easy it is to make a
fully authenicated compression encryption with it.
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: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: The 94 cycle 64-bit block cipher :-)
Date: Sun, 17 Jun 2001 13:45:08 GMT
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:9gibhj$t27$[EMAIL PROTECTED]...
> There reversible. CRC's AFIAK are based on inversion in GF(2^w)/p(x).
> Inversion can be reversed. :) (the choice of the field is speed related
> IRRC)
Close, CRCs are based on division. You treat the message as a huge
polynomial in boolean polynomial basis, divide it by a prime polynnomial and
get the remainder.
Of course they are implemented as shift registers for speed...
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
******************************
