Cryptography-Digest Digest #167, Volume #10 Fri, 3 Sep 99 14:13:06 EDT
Contents:
Re: RC4 or IBAA or ISAAC to generate large random numbers (Paul Crowley)
Re: IDEA- safe? (Paul Crowley)
Re: RC4 or IBAA or ISAAC to generate large random numbers (John Savard)
Re: Message Digest Algorithms (Tom St Denis)
Re: One to One Compression updated (Tom St Denis)
MD5 source code in VC++ or asm? ([EMAIL PROTECTED])
Re: http://www.tmechan.freeserve.co.uk/wincrypt.html ("Daniel Roethlisberger")
Re: How Easy Can Terrorists Get Strong Encrypt? (Lincoln Yeoh)
Re: Alleged NSA backdoor in Windows CryptoAPI (SCOTT19U.ZIP_GUY)
Re: One to One Compression updated (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: RC4 or IBAA or ISAAC to generate large random numbers
Date: 3 Sep 1999 09:05:43 +0100
Gaston Gloesener <[EMAIL PROTECTED]> writes:
> What is the correct way to generate larger random numbers (>64 bits):
Any CPRNG can be considered as a stream of random bits; the boundaries
between words are just an artifact of the way they're generated. If
the CPRNG is good then you can take as many bits at a time as you need
and use them as random. I know of no biases or flaws in IBAA or
ISAAC; there's an incredibly tiny bias in RC4 but I don't suppose
it'll affect your work (see http://www.hedonism.demon.co.uk/paul/rc4/ ).
You might also consider using Joan Daemen and Craig Clapp's PANAMA,
which I believe is faster than any of these: see
http://www.esat.kuleuven.ac.be/~rijmen/daemen.html
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: IDEA- safe?
Date: 3 Sep 1999 09:32:36 +0100
[EMAIL PROTECTED] writes:
> Jim Butcher wrote:
>
> > has anyone heard of a successful cryptanalysis of the IDEA algorithm? 128
> > bit key, 64 bit block size
> > for that matter Blowfish 256 bit key?
No. The worst result against IDEA is that a very tiny proportion of
the keys (1 in 2^96) are easily detected, making cryptanalysis very
slightly faster.
> As I have learned in the past few months on this newsgroup...as long as the
> key size is of sufficiant length (lets say 64 bits+), the keysize is really
> irrelivant. There are other types of attacks on algorithms than brute force.
There are no other attacks known on the *algorithms* than brute force,
though there can be other attacks on entire cryptosystems that use
them (such as rubber-hose cryptanalysis). And your figure 64 bits is
too short: I'm confident that the RC5 challenge will soon break a 64
bit key. I'd put the figure at, say, 112 bits (triple-DES) or
greater.
256-bit keys are only needed to defend against immensely advanced
aliens with quantum computeres.
> As long as you stick with the tried and true algorithms, you should be
> ok. Blowfish, IDEA, CAST-128, 3DES, RC4, RC5, or any of the AES candidates.
The AES candidates don't really count as "tried and true".
RC4 is a stream cipher and doesn't apply. IDEA and RC5 are
patent-encumbered; I can't remember whether CAST is or not. 3DES is
slow. Use Blowfish.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: RC4 or IBAA or ISAAC to generate large random numbers
Date: Fri, 03 Sep 1999 15:30:21 GMT
Gaston Gloesener <[EMAIL PROTECTED]> wrote, in part:
>What is the correct way to generate larger random numbers (>64 bits):
>1. Handle large integers inside the algorithm,
>2. Compute a set of results (r-array) and use consecutive 32-bit values
>to fill-up the resulting random number.
(1) is better, in the sense that it will not make the algorithm any
worse, and so if one is using a poor generator, such as linear
congruential, it would be mandatory, but (2) can be used with any
random number method of sufficiently high quality.
In either case, the random number generator must have an internal
state at least as big as the large pseudorandom number you are trying
to generate.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Message Digest Algorithms
Date: Fri, 03 Sep 1999 14:52:23 GMT
In article <[EMAIL PROTECTED]>,
"Daniel Roethlisberger" <[EMAIL PROTECTED]> wrote:
> I have previously used MD5 in all the code I wrote. Now I am looking
for a
> replacement, and have found several algorithms. Now I am unsure which
one to
> use. Hence my question: has anybody an idea where I might get info on
> message digest algo's? Some of the algorithms that I have considered
lately
> are RipeMD, Tiger and SHA1. Has anyone got some good piece of
information on
> their advantages and on their strength?
>
> Any suggestions? Pointers? Hints?
Tiger is a good idea for 64-bit machines, SHA-1 has been used for quite
some time. HAVAL might be a good idea as well.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: One to One Compression updated
Date: Fri, 03 Sep 1999 15:04:02 GMT
In article <7qjgko$mpu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Tom I really don't know why you ask such questions. You sound
frustated
> you might as well ask why did the chicken cross the road. Or what came
> first the chicken or the egg.
> But I did spend a great deal of time on the BWT (burrow wheeler
transform)
> and for a while I was hoping and predicting that I could use it as
the
> front end to a "one to one" type of compression. But I failed I just
could not
> do it. It is a beautiful clever method but the problem was that any
file could
> be transformed by the method (plus the added postion information) But
i could
> not find a way to do the reverse transfrom for an arbitrary file. If
you just
> make up data you can run into inconsetances during the reverse process
so
> in essence the sturcture of the thing you are trying to reverse may or
may not
> be reversable. The transofrm itself is not one to one. I looked for
added
> rules to make it such and thought I was getting close but in the end.
It is on
> the back burrner of my brain. If you find a way so that "any file" can
be un
> BTWed by a few added rules let me know.
> Yes I have used bzip2 also. It is very nice and for general file
compression
> it is a winner. But in my mind as it stands it is very weak for
encryption.
> The reason is this. Suppose I have a file that is used as a key to
> scott19u.zip And all I want is to send the file encrypted to some
one.
> (I know it in general would not compress so don't ask just go with
> the flow for a minute) so they can use my program. He currently has
> a program like QHQ ( i made this up PGP plus 1) it uses a wizz bang
> bzip2 like compression on all input files simalar to PGP is it not. IT
then
> encrpyts it with some wizz bang AES method. It is even user firendly
> so that many keys are eliminated since it has the nice feature of good
> ole PGP approved export crypto that the key is used for a parital
qucik
> and dirty check sum of some type to do a quick check to see that
> the key has a good chance of being the correct key.
> we use this to send my
> soctt19u key. Since scott19u can really use any file and I pick rather
> randomly and since I have not yet sent a message using my porgram
> with this ket to my new friend. You would think it is 100% safe. But
is
> it. First the NSA using information theory may imiititaly eliminate
all
> keys that don't pass the convinent quick and dirty check. You say this
> may at most reduce the key space by 16 bits or so. Then it looks at
> this random set of remaining bytes. It then analzyse what keys lead to
> files that can be decompressed by this compression method. Don't
forget
> bzip2 is multistaged. IT can do this at every stage. know we get to
the
> last stage and they look to see if the file is a valid output from BTW
itself
> they check the index value to see if it makes sense. They may try to
> do the reverse table. I am not sure if it this point with all the
friendly
> checks and "nice" features in the variuos stages of compression that
the
> NSA may find only a very few possiblitys left for this "random key"
that
> has never been used. But of course in your young mind you can't see
> that as even a remotely real possiblirty.
I doubt your position is really that scientific. You state that since
any file can be decompressed with your huffman code it makes it harder
to brute force. I am saying that's wrong. Brute forcing a single ECB
block or several CBC blocks are proportionaly as difficult to solve as
the keyspace and work involved to decrypt.
I would rather use BWT, Deflate or even LZ77 (straight) if it meant
getting a higher ratio. If I can send message 4 times faster I will
want to.
How do you argue against brute forcing a 160-bit key for example?
What is the inherant security provided by having a
all-compress-decompress-magic program?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: MD5 source code in VC++ or asm?
Date: Fri, 03 Sep 1999 14:12:29 GMT
Hello all,
Does anyone know where to find MD5 source code in VC++ or asm?
Thanks alot,
Sean
------------------------------
Reply-To: "Daniel Roethlisberger" <[EMAIL PROTECTED]>
From: "Daniel Roethlisberger" <[EMAIL PROTECTED]>
Subject: Re: http://www.tmechan.freeserve.co.uk/wincrypt.html
Date: Fri, 3 Sep 1999 16:02:07 +0200
> This is the _source_, right? If not, nobody with a clue will
> give it a second (or even first) thought.
Was going to mention exactly the same thing... the whole thing appears to be
very unprofessional, thus I'd never trust it my secrets without reading the
source first.
The description is pretty uncertain, it doesn't mention how it processes the
passwordto the 128 bit key for IDEA, and it even says it would store the
passwords locally. But are the stored passwords protected by any means?
Seems to be pretty insecure. Nothing I would place my trust in, and
certainly not pay 70 dollars for it.
/Dan
--
[EMAIL PROTECTED]
PGP Key ID 0x326DA8BA
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: Fri, 03 Sep 1999 16:55:13 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 28 Aug 1999 21:02:36 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>John Savard wrote:
>> - Terrorists are often fanatics; perhaps people with the intelligence
>> to program a computer are seldom found in terrorist movements.
>
>Terrorists sponsored by governments or rich backers, or large criminal
>organizations, can simply *buy* sufficient technical expertise.
Of course depending on what "Strong Encrypt" means, terrorists can always
grab pirated CDs of stuff. I'm sure Unauthorised Distributors use different
merchandise declaration procedures during exports ;).
Cheaper I bet.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI
Date: Fri, 03 Sep 1999 17:23:18 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Geoffrey
Simmons) wrote:
>I found no references to this subject under sci.crypt in Dejanews, so I'd
>like to ask if anyone knows of or can render an opinion about this:
>
> <http://www.cryptonym.com/hottopics/msft-nsa.html>
>
>CryptoNym claims to have uncovered a back door for the NSA in Microsoft's
>CryptoAPI for Windows (NT at least, and possibly for all current
>versions). The main evidence is that in Service Pack 5 for NT4, some of
>the debug symbols were left in the library, apparently by accident. One of
>the symbols is "NSAKEY". The surmise is that MS, in cooperation with the
>NSA, has seen to it that an RSA key known to the NSA is surreptitiously
>substituted for the user's key (if I've understood correctly).
>
>I first read about it at Slashdot, where it has raised quite a furor, but
>also a lot skepticism, since the evidence is not entirely conclusive:
>
>
> <http://slashdot.org/article.pl?sid=99/09/03/0940241&mode=thread&threshold=0>
>
>Would someone with more expertise in crytography care to render an opinion?
>
I am not considerated an expert since I don't wear a tie. But I think if it
is based on PGP it automatically has Back Doors. The back doors are hidden
in plain site. Which is the best way to hide them ( assuming they don't have
a mathematiclly break) The best back doors are weak chaining methods.
Or if there are compressors that are not "one to one" or anything that adds
error recovery or error checking. These terms are used to turn the brain off
when such features built in to the encryption methods are really nothing more
than backdoors in plain site.
Sure there should be error dectection when communication packets are sent
over the line and there is error detecting and correctting in the packets that
are sent over the internet. But these methods are out side of the encryption
package and that is where such functions should stay unless one wants to
make it easy to break.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: One to One Compression updated
Date: Fri, 03 Sep 1999 17:12:55 GMT
In article <7qoo0o$gsj$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <7qjgko$mpu$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> Tom I really don't know why you ask such questions. You sound
>frustated
>> you might as well ask why did the chicken cross the road. Or what came
>> first the chicken or the egg.
>> But I did spend a great deal of time on the BWT (burrow wheeler
>transform)
>> and for a while I was hoping and predicting that I could use it as
>the
>> front end to a "one to one" type of compression. But I failed I just
>could not
>> do it. It is a beautiful clever method but the problem was that any
>file could
>> be transformed by the method (plus the added postion information) But
>i could
>> not find a way to do the reverse transfrom for an arbitrary file. If
>you just
>> make up data you can run into inconsetances during the reverse process
>so
>> in essence the sturcture of the thing you are trying to reverse may or
>may not
>> be reversable. The transofrm itself is not one to one. I looked for
>added
>> rules to make it such and thought I was getting close but in the end.
>It is on
>> the back burrner of my brain. If you find a way so that "any file" can
>be un
>> BTWed by a few added rules let me know.
>> Yes I have used bzip2 also. It is very nice and for general file
>compression
>> it is a winner. But in my mind as it stands it is very weak for
>encryption.
>> The reason is this. Suppose I have a file that is used as a key to
>> scott19u.zip And all I want is to send the file encrypted to some
>one.
>> (I know it in general would not compress so don't ask just go with
>> the flow for a minute) so they can use my program. He currently has
>> a program like QHQ ( i made this up PGP plus 1) it uses a wizz bang
>> bzip2 like compression on all input files simalar to PGP is it not. IT
>then
>> encrpyts it with some wizz bang AES method. It is even user firendly
>> so that many keys are eliminated since it has the nice feature of good
>> ole PGP approved export crypto that the key is used for a parital
>qucik
>> and dirty check sum of some type to do a quick check to see that
>> the key has a good chance of being the correct key.
>> we use this to send my
>> soctt19u key. Since scott19u can really use any file and I pick rather
>> randomly and since I have not yet sent a message using my porgram
>> with this ket to my new friend. You would think it is 100% safe. But
>is
>> it. First the NSA using information theory may imiititaly eliminate
>all
>> keys that don't pass the convinent quick and dirty check. You say this
>> may at most reduce the key space by 16 bits or so. Then it looks at
>> this random set of remaining bytes. It then analzyse what keys lead to
>> files that can be decompressed by this compression method. Don't
>forget
>> bzip2 is multistaged. IT can do this at every stage. know we get to
>the
>> last stage and they look to see if the file is a valid output from BTW
>itself
>> they check the index value to see if it makes sense. They may try to
>> do the reverse table. I am not sure if it this point with all the
>friendly
>> checks and "nice" features in the variuos stages of compression that
>the
>> NSA may find only a very few possiblitys left for this "random key"
>that
>> has never been used. But of course in your young mind you can't see
>> that as even a remotely real possiblirty.
>
>I doubt your position is really that scientific. You state that since
>any file can be decompressed with your huffman code it makes it harder
>to brute force. I am saying that's wrong. Brute forcing a single ECB
>block or several CBC blocks are proportionaly as difficult to solve as
>the keyspace and work involved to decrypt.
>
>I would rather use BWT, Deflate or even LZ77 (straight) if it meant
>getting a higher ratio. If I can send message 4 times faster I will
>want to.
>
>How do you argue against brute forcing a 160-bit key for example?
>
>What is the inherant security provided by having a
>all-compress-decompress-magic program?
>
>Tom
Tom I thought my example was clear. I don't think brute forceing is
the end all. But it is a measure. As to why one should use something
like a "one to one" compression is based on information arguments. If
you fill that your AES protects you from everything then fine use it.
IF you think the compressuin method you may use conveys no information
to some one trying to break your message fine. Use one of your choice.
All I am saying is that if some one guesses the WRONG key and it is
known that you used compression. Why use one that tells the attacker
immediately that he has the wrong key. This does not mean this is the only why
the attacker got to this point was by a wrong key. But it does mean that
the compression technique can add data that the attacker can use
if you feel that the information added is of little value fine. I prefer to
use methods that do not give any information to the attacker. Why argue
about how little is given to attacker when one can strive to give no
information to the attacker.
I think the whole point of encryption is to make it hard for some one else
to read the message. IF one can make it harder then do so. You apparently
are under the common school of thought that little things that leak
information are of no importance. I don't think that way and I am not saying
that you have too.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
