Cryptography-Digest Digest #992, Volume #12 Tue, 24 Oct 00 10:13:00 EDT
Contents:
Re: Huffman stream cipher. (Richard Heathfield)
Re: Huffman stream cipher. (Richard Heathfield)
Re: Huffman stream cipher. (David Schwartz)
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: A naive question (Mok-Kong Shen)
Re: My comments on AES (John Savard)
Re: My comments on AES (Volker Hetzer)
Re: Huffman stream cipher. (Tom St Denis)
Re: Huffman stream cipher. (Richard Heathfield)
BUGS, New Documentation (Sylvain Martinez)
Rijndael file encryption question. ("ajd")
Entropy and Blowfish ("George Gordon")
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Using DH ("George Gordon")
AES ("George Gordon")
Rijndael and PGP ("George Gordon")
----------------------------------------------------------------------------
Date: Tue, 24 Oct 2000 08:13:45 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
<snip>
> >So, even when I turn off all the warnings and all the portability flags,
> >I /still/ don't get a clean compile.
> >
<snip>
>
> I guess you don't realize that warning is not the same as error.
I guess you don't realise that they're the same thing - diagnostics. A
diagnostic is something which prompts you that all might not be well
with your program. Ignore them at your peril.
C requires implementations to provide diagnostics for syntax errors and
constraint violations, and permits them in all other circumstances.
(Fortunately, most compiler-writers tend to warn only about important
stuff.)
> I use to get warning from compliers all the time. It just means becare
> or use at you on risk which really goes with all software.
It is a message from the compiler-writer, and it means: "I think there's
something wrong with this code. Check it very carefully, because the
code probably /is/ wrong." The vast majority of the time, it /is/ the
code that's wrong. To ignore a diagnostic is a serious step for me.
> But a
> warning is not an ERROR.
A diagnostic is a diagnostic.
> Portability to other systems is not a high
> priority with me.
Then your code is not going to be widely adopted, so it's not worth
analysing.
> Getting code to work on the machine I use is. Hell
> when I worked for the US gorvernment
I don't believe you ever worked for the US Government. People who work
for the US Government may be incompetent, but there is a limit.
> I don't like to change
> compiler versiions even in C. I would not be surprised in the next
> release of GNU C for DJGPP it may not work.
Wouldn't it be less work just to do it properly first time?
> But it does for the current version.
Sure about that? I got a diagnostic even from a vanilla compile, let
alone from a rigorous compile...
> One could chase portability issues for ever but you never
> really know the code is portable until you test it on the machine.
That, sir, is incorrect; it /is/ possible and indeed relatively easy to
write code that is portable to the vast majority of machines and
compilers, and still possible (though less easy) to write code that is
universally portable.
> My fun is getting it to work on the machine I have access to with the
> tools I have. I figure if some one wants to use it in another machine
> or compiler of there choice they have to get it to work.
Why should they bother? It all comes down to whether you want people to
use your stuff or not. If you don't, your attitude toward portability is
fine, but don't expect people to analyse your work. If you do want
people to use your stuff, you're going the wrong way about it.
> However
> since I am retired I would be willing to work for CASH to get it to
> work on another machine and or version of a compiler.
Forget it. Why should anyone use your non-portable crypto when they can
use portable crypto by pretty well anyone else? Why should anyone even
bother to analyse your stuff?
> C was not designed for portability.
You really are a barrel of laughs, aren't you? C has been designed
extremely carefully to maximise the portability of well-written C
programs.
> It was designed to make programing
> easyer on NEW machines without having to rely soley on machine language
That too.
> it is a tool to help nothing more.
Right; and like all tools, it needs to be used properly or it could do
some damage. In this case, the damage is purely to whatever shreds of
reputation you might have managed to gather around yourself in the past.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
Date: Tue, 24 Oct 2000 08:21:55 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > Maybe the 19x19 bit S tables are bigger than what most people are
> > use to.
>
> Yes I would say a 19x19 table is not only crazily large but terribly
> inefficient. Sure I could make a secure block cipher (Bruce Schneier
> like rant comming up...) out of 128 rounds of a simply stupid round
> function.... however.... good crypto is about doing good things with
> less and faster. Using a 19x19 table is hardly a sign of "doing things
> with less or faster"
Tom - How secure do you mean by "secure"? I'd appreciate an example,
because my crypto strategy tends to be about doing bad things with more
and slower :-) so I wouldn't have any particular problem with 128 rounds
if it genuinely increased security. I'd also appreciate an example of a
secure but simply stupid round function...
If your sarcasm filters are on, please take them off for a moment. The
previous paragraph should be read and interpreted literally. :-)
<snip>
> > since I am retired I would be willing to work for CASH to get it to
> > work on another machine and or version of a compiler.
>
> Not only is your thread (with Richard) off-topic (move to comp.lang.c
> please)
Sorry about that. I think we're done, anyway. Sending Scott to
comp.lang.c is just too cruel. :-)
<snip>
>
> Also I use "void main(void)" quite a bit, I know it's wrong,
Then why do it? :-)
> and not at
> all portable. I really should be carefull.. You're right that in all
> honesty it doesn't matter,
It does matter on some machines. Really. You can hang a batch on MVS
like this. I'm told you can even crash a Vax - bring it right down.
That's why it's important to get it right. It's not (just) that I'm
pedantic - it actually matters.
<snip other C discussion in the interests of sci.crypt topicality>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Tue, 24 Oct 2000 00:34:30 -0700
Richard Heathfield wrote:
> > Not only is your thread (with Richard) off-topic (move to comp.lang.c
> > please)
>
> Sorry about that. I think we're done, anyway. Sending Scott to
> comp.lang.c is just too cruel. :-)
To the good folks on comp.lang.c?
DS
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Tue, 24 Oct 2000 10:50:21 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > Suppose one encrypts many double blocks (u, v, u, v) in
> > a very long message
> [...]
> > I am afraid
> > that, by going through 8 cycles it would be extremely
> > hard to identify a path like (u,v,u,v)-->(x,y,x,y)-->
> > (e,f,e,f) .... --> (j,k,j,k) (say) by examining the
> > frequency distribution alone.
>
> I think we've established that the above is a
> misunderstanding of the attack. In the first part of the
> attack, a single block (two words) constitutes the entire
> message. In the second part, the entire message is two
> blocks (four words) in size. The attacker encrypts the same
> short messages many times. He does not concatenate them
> into one long message and encrypt at once.
>
> The probabilities given in the attack description refer to
> encryption of the one-block (two-word) message and the
> two-block (four-word) message.
Thanks. It seems now that I am one step further in
understanding you. Please keep on being patient with me.
In the one block (u,v) case, through encrypting a few
hundred times, one achieves that all possible combinations
of permutations (assumed taking place with equal frequency)
occur in the inter-cycle permutation processes. With 6
such processes one gets 2^6 different kinds of ciphertext
blocks of the type (a,b), each with equal frequency. Is
that right?
BTW, I don't understand why do you want to limit to 6
and don't allow 7 permutation processes which is the
actual situation. Does that cause difficulties to your
attack?
By the same argument, in the two block (u,v,u,v) case
(with the same u and v as above) one gets 8^6 different
kinds of ciphertext blocks of the type (c,d,e,f),
again each with equal frequency. Is that right also?
If both answers are yes, I don't yet see how you can
utilize any frequency information in the ciphertext to
guide establishing any set of equations. Could you please
kindly explain?
Thanks in advance.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A naive question
Date: Tue, 24 Oct 2000 10:55:16 +0200
John Savard schrieb:
>
> On Tue, 24 Oct 2000 00:25:15 +0200, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Is there anything wrong with the following?
>
> >Let there be a master key Q. To send message blocks P
> >with a sufficiently strong algorithm E, we pick a random
> >number R, obtain K = E(Q,R) and send R and blocks E(K,P)
> >to the recipient.
>
> Given that E(Q,R) means "R, encrypted with key Q", there is nothing
> wrong with that, although it is more conventional to send K and blocks
> E(R,P) to the recipient. In that case, Q is called the "key-exchange
> key".
>
> It is a standard practice, and useful in reducing the number of times
> one has to use time-consuming public-key algorithms.
Could one say that in case R, due to practical imferpectness,
is not entirely random, one achieves in the first case
a more random key in doing the encryption of the message
blocks? Or is there absolutely nothing gained? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: My comments on AES
Date: Tue, 24 Oct 2000 10:52:00 GMT
On Mon, 23 Oct 2000 21:39:39 -0500, Bruce Schneier
<[EMAIL PROTECTED]> wrote, in part:
>Indeed. It is an "academic discount," but not a discount that has any
>practical meaning. Sort of like the difference between an academic
>break of a cipher and a break that actually makes a difference in
>practice.
I might note that, although it seems to make sense to prefer the
cipher without an academic break to the one with one, the current
emphasis on this to the exclusion of other measures of security (what
other measures, someone might ask) can create one problem.
Given the goal of designing a cipher against which any attack is to
have complexity 2^512, it might be easier to design one with a
4096-bit key that has that property than one with a 512-bit key. In
the latter case, for example, one might be required to have an
elaborate key schedule, while one could get by with less (but not with
nothing) in the former case.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Date: Tue, 24 Oct 2000 13:45:36 +0200
John Savard wrote:
> Given the goal of designing a cipher against which any attack is to
> have complexity 2^512, it might be easier to design one with a
> 4096-bit key that has that property than one with a 512-bit key. In
> the latter case, for example, one might be required to have an
> elaborate key schedule, while one could get by with less (but not with
> nothing) in the former case.
It might be easier to design, but (if I understand you correctly) you
just dump the responsibility of the key expansion at the door of the user.
IMHO it's likely that any saved design time will result in a lot of weak keys.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Tue, 24 Oct 2000 11:44:49 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > > Maybe the 19x19 bit S tables are bigger than what most people are
> > > use to.
> >
> > Yes I would say a 19x19 table is not only crazily large but terribly
> > inefficient. Sure I could make a secure block cipher (Bruce
Schneier
> > like rant comming up...) out of 128 rounds of a simply stupid round
> > function.... however.... good crypto is about doing good things with
> > less and faster. Using a 19x19 table is hardly a sign of "doing
things
> > with less or faster"
>
> Tom - How secure do you mean by "secure"? I'd appreciate an example,
> because my crypto strategy tends to be about doing bad things with
more
> and slower :-) so I wouldn't have any particular problem with 128
rounds
> if it genuinely increased security. I'd also appreciate an example of
a
> secure but simply stupid round function...
Well take a simple round function such as
F(x) = (x <<< x) + k
There are wickedly bad differentials with a prob 27/32. If you
itterate it enough it could be secure. For example in a 64-bit Feistel
with 300 rounds would have a differential of probability (27/32)^300=2^-
73.53. While this function is secure against linear cryptanalysis
after only a few rounds if you change it to
F(x + k) = x<<<x
Where the key is added before the rotate. Each linear approximation
(i.e the rotation amount) holds with prob 1/32 and after 16 rounds this
is (1/32)^16 = 2^-80.
So given 300 rounds with independent round keys that simple round
function is in fact secure.
> If your sarcasm filters are on, please take them off for a moment. The
> previous paragraph should be read and interpreted literally. :-)
Sarcasm was dutifully removed :-)
> <snip>
>
> > > since I am retired I would be willing to work for CASH to get it
to
> > > work on another machine and or version of a compiler.
> >
> > Not only is your thread (with Richard) off-topic (move to
comp.lang.c
> > please)
>
> Sorry about that. I think we're done, anyway. Sending Scott to
> comp.lang.c is just too cruel. :-)
>
> <snip>
> >
> > Also I use "void main(void)" quite a bit, I know it's wrong,
>
> Then why do it? :-)
Because it's a bad habit and my ms-dos machine can take it. Honestly
though if I release source code (i.e on my website) I will not take
offense to critism and suggestions (hint hint).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 24 Oct 2000 13:55:10 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > >
<big snip>
> > > Also I use "void main(void)" quite a bit, I know it's wrong,
> >
> > Then why do it? :-)
>
> Because it's a bad habit and my ms-dos machine can take it. Honestly
> though if I release source code (i.e on my website) I will not take
> offense to critism and suggestions (hint hint).
I'll be happy to check over it at the weekend if I get time, but only
from a C point of view, not from a crypto point of view!
[I presume, by the way, that <<< means either 'rotate left' or 'left
shift a LOT* :-) ]
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: BUGS, New Documentation
Date: Tue, 24 Oct 2000 13:13:10 GMT
Hi,
[info]
BUGS is an original dynamic private key algorithm. It is open source and
FREE. The description of this algorithm has already been posted here and
is available on: http://www.bcrypt.com
[info]
Thanks for all the useful feedback I received regarding the BUGS
cryptography algorithm. Here is the result of it:
- A new documentation is now available.
. Correction of many errors (technical, english grammar, etc)
. Much more info regarding the current BUGS algorithm.
http://www.bcrypt.com/crypto/doc/index.html
- New Library and UNIX version: BUGS v3.5.3
A new algorithm has been designed to create an ASCII "cipher text"
(hexadecimal), this version is more stable and efficient.
http://www.bcrypt.com/crypto/bugs-3.5.3.tgz
- New Windows version: bcrypt v3.1
This version includes the new library/doc and corrects lots of bugs.
There is still few known bugs but they are not in the library and are
minor.
http://www.bcrypt.com/crypto/bcrypt_31.zip
- The cryptography contest is still running, nobody has managed to
crack the BUGS algorithm yet. About 2000 people have now downloaded
the contest data.
http://www.bcrypt.com
For more information I invite you to go to the official web site (cf
above). I am sorry about my poor english, but I am french and I tried my
best to produce a good documentation. If you have any questions please
feel free to contact me.
Regards,
Sylvain.
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
--
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "ajd" <[EMAIL PROTECTED]>
Subject: Rijndael file encryption question.
Date: Tue, 24 Oct 2000 12:15:05 +0100
Hi,
I've written a rijndael implementation (128 bit key, 10 rounds) and got it
working with the test vectors. I now am trying to encrypt files with it.
Say I have a text file msg.txt conatining:
oh I do like to be beside the seaside.
Oh I do like to be beside the sea.
where the brass band pl
This file is 99 bytes long. I want to encrypt it but the Rijndael block
cipher requires blocks of 16 bytes, so I append the final block with
gibberish (lets call this gibberish the 'carry'). Running this through my
encryption algorithm gives an encrypted file of 112 bytes.
Now here I could either
a) chop off the carry before sending it to 'Bob' so my encrypted file is
back to the original 99 bytes. The problem here is that to decrypt you need
the same encrypted gibberish that the carry produced (which Bob doesn't
know) result in losing the entire final block
e.g decryption produces
oh I do like to be beside the seaside.
Oh I do like to be beside the sea.
where the brass bandQL�
We have lost the block which contained " pl"
Or
b) Save the entire final encrypted block before sending to Bob (so we save
112 bytes of encrypted data instead of 99). The problem here is that Bob
doesn't know how long the original encrypted file was. When he decrypts he
then gets:
oh I do like to be beside the seaside.
Oh I do like to be beside the sea.
where the brass band pl�������������
We have the whole original method but some extra stuff as well. For non-text
files this could prove to be a problem. Do I use this method and send the
file length to Bob as well or is there another way to get around the
problem?
Thanks for any help
Andrew
------------------------------
From: "George Gordon" <[EMAIL PROTECTED]>
Subject: Entropy and Blowfish
Date: Tue, 24 Oct 2000 09:32:36 -0700
Hi group,
Explaining why the last four initial subkeys should not be filled with
unique key material, the author of Blowfish notes the .06 probability
that any one S-box affects a given block.
I question whether or not this is very important when the S-boxes are
key dependant and random as in Blowfish. If the keys's entropy is
distributed evenly throughout the S-boxes, why are the value of the
subkeys themselves that important?
Some algorithms like Khufu, RedocIII, or even Diamond, NSEA, etc don't
even have real subkeys. Yes, I know of some attacks, but any based on
this lack of concrete subkeys? (I'm not refering to lack of round
dependence)
Specifically, if each key produces a different set of output blocks for
a given set of input blocks, why would it matter if a subset of input
blocks map to the same output blocks for a particular subgroup of keys?
If so, at what threshold would this become vulnerable? Vulnerable to
distinguishing type attacks?
Also, in ciphers like Blowfish, it seems to me that when *both* the
S-boxes and the linear part (the subkeys) are variable and change
randomly with respect to each other, they might interact in some unknown
way to actually reduce the amount of entropy transferred to the
input-to-output mappings.
George
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Huffman stream cipher.
Date: 24 Oct 2000 13:40:13 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>Tom St Denis wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> Richard Heathfield <[EMAIL PROTECTED]> wrote:
>> > Tom St Denis wrote:
>> > >
>
><big snip>
>
>> > > Also I use "void main(void)" quite a bit, I know it's wrong,
>> >
>> > Then why do it? :-)
>>
>> Because it's a bad habit and my ms-dos machine can take it. Honestly
>> though if I release source code (i.e on my website) I will not take
>> offense to critism and suggestions (hint hint).
>
>I'll be happy to check over it at the weekend if I get time, but only
>from a C point of view, not from a crypto point of view!
>
>[I presume, by the way, that <<< means either 'rotate left' or 'left
>shift a LOT* :-) ]
>
I have not seens Tommy email but assuming your making fun of his
the synbol "<<" you would be right it could mean either "rotate left"
or "shift left" it is one of the machine dependent features of good
old C. So maybe in your proper dream world it should not ever be used.
When I get on a new machibe I play with it to see what it does,
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Huffman stream cipher.
Date: 24 Oct 2000 13:34:03 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
snip
>>
>> I guess you don't realize that warning is not the same as error.
>
>I guess you don't realise that they're the same thing - diagnostics. A
>diagnostic is something which prompts you that all might not be well
>with your program. Ignore them at your peril.
>
>C requires implementations to provide diagnostics for syntax errors and
>constraint violations, and permits them in all other circumstances.
>(Fortunately, most compiler-writers tend to warn only about important
>stuff.)
>
>> I use to get warning from compliers all the time. It just means becare
>> or use at you on risk which really goes with all software.
>
>It is a message from the compiler-writer, and it means: "I think there's
>something wrong with this code. Check it very carefully, because the
>code probably /is/ wrong." The vast majority of the time, it /is/ the
>code that's wrong. To ignore a diagnostic is a serious step for me.
It may be serious for someone who lacks experience like you. But
they don't call it a warning for nothing.
>
>> But a
>> warning is not an ERROR.
>
>A diagnostic is a diagnostic.
>
>> Portability to other systems is not a high
>> priority with me.
>
>Then your code is not going to be widely adopted, so it's not worth
>analysing.
>
Then you don't have to use it. Its free and you
may lack the intellegence to make it work on your system
>> Getting code to work on the machine I use is. Hell
>> when I worked for the US gorvernment
>
>I don't believe you ever worked for the US Government. People who work
>for the US Government may be incompetent, but there is a limit.
>
Then again you are a fool and and idiot.
>> I don't like to change
>> compiler versiions even in C. I would not be surprised in the next
>> release of GNU C for DJGPP it may not work.
>
>Wouldn't it be less work just to do it properly first time?
>
When one codes there really is no such thing as proper the
first time since C is a moving defination. Like English once
gay was the proper word to use meaing something close to happy
know there is no subsiture for what gay use to mean,
C at one time was for ease and convenice. THe pointer had more
power. and you could use "9" when describing the value of octal
numbers. THen assholes decided the hell with old code following
the rules. We will make new rules so old code will not work.
That is how it is. I use to get argumetns fromm assholes all the
time at work when the fortram compliers would change and then
code would not work the same. I would fix it for them since they
were like you they would bitch and be unhappy. Expecailly when I
tell them I we see them when we get the next version of fortran,
Nothing stays the same. If you want ot done properly use assembly
but even them they system software can change and then your
screweed again.
>That, sir, is incorrect; it /is/ possible and indeed relatively easy to
>write code that is portable to the vast majority of machines and
>compilers, and still possible (though less easy) to write code that is
>universally portable.
I do not think it is possible to write a scott19u version of
C that runs on most machines. You may think it is easy but your
wrong and lack the real world experience. It just can not be
easily done.
>
>Why should they bother? It all comes down to whether you want people to
>use your stuff or not. If you don't, your attitude toward portability is
>fine, but don't expect people to analyse your work. If you do want
>people to use your stuff, you're going the wrong way about it.
>
I guess assholes that want everything handed to them don't have
to look at it. I don't think you can or should like at it. Thank
God not everyone is like you. Seem people actually can think for
themselves.
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: "George Gordon" <[EMAIL PROTECTED]>
Subject: Using DH
Date: Tue, 24 Oct 2000 09:51:05 -0700
In using DH, if you:
a) create a random 160-bit key, then
b) expand that to 2K+ bits using RC4 or something,
c) create a shared key using DH, then
d) hash that to a 160-bit key using SHA1, and
e) use that as your symmetric key.
Is that OK??
Also, does anyone know where I can find some tested *safe* parameters
for DH >1024-bits??
Thanks,
George
------------------------------
From: "George Gordon" <[EMAIL PROTECTED]>
Subject: AES
Date: Tue, 24 Oct 2000 09:56:04 -0700
Rijndael chosen as AES. OK, is Twofish in the public domain then? What
of the Hitachi patent regarding Twofish?
George
------------------------------
From: "George Gordon" <[EMAIL PROTECTED]>
Subject: Rijndael and PGP
Date: Tue, 24 Oct 2000 09:52:57 -0700
Rijndael and PGP. What's the word on this?
------------------------------
** 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
******************************
