Cryptography-Digest Digest #753, Volume #12 Sat, 23 Sep 00 13:13:00 EDT
Contents:
Looking for a CSPRNG ("Cristiano")
Re: winace encryption algorithm (correction) (Nomen Nescio)
Re: CDMA tracking (was Re: GSM tracking) (Craig Paul)
Re: Software patents are evil. (SCOTT19U.ZIP_GUY)
Re: Big CRC polynomials? ("bubba")
Re: Big CRC polynomials? (Paul Schlyter)
Re: Maximal security for a resources-limited microcontroller (Runu Knips)
Re: Software patents are evil. ("Paul Pires")
Re: Big CRC polynomials? (Tom St Denis)
Re: Tying Up Loose Ends - Correction ("Trevor L. Jackson, III")
Please verify (JAMES LANKTON)
Re: Big CRC polynomials? (Runu Knips)
Re: Please verify (SCOTT19U.ZIP_GUY)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: What make a cipher resistent to Differential Cryptanalysis? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Looking for a CSPRNG
Date: Sat, 23 Sep 2000 12:17:01 +0200
I have implemented BBS generator as suggested by Thierry Moreau in his paper
"A practical "perfect" pseudo-random nember generator", but for p and q of
length greatest than about 200 bits the program setup is terribly slow.
I'd like to implement a cryptographically secure PRNG by using an hashing
function like SHA-1 or ripemd160. Can I take the whole 160 bits of output?
Some suggestion?
Cristiano
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: Re: winace encryption algorithm (correction)
Date: Sat, 23 Sep 2000 13:30:05 +0200 (CEST)
David Hopwood wrote:
> It's based on SHA-0, not SHA-1 (the difference is the 1-bit
> rotation). The key scheduling is equivalent to using the output of
> SHA-0 as a 160-bit Blowfish key (this depends on SHA-0 and
> Blowfish both being big-endian). I.e. excluding the possible
> errors described below, the algorithm is Blowfish in CBC mode with
> the 160-bit key SHA-0(byteswap(password))), where 'byteswap' swaps
> the byte order of each 32-bit word (treating the last word
> slightly differently).
Thanks for your comments. You might be right, I compared it to SHA-1
and didn't look at SHA-0.
> However, if the reverse engineering is correct then there is a bug
> in the SHA-0 implementation: the array holding the SHA-0 input is
> not fully initialised to zero; only the first word is initialised
> ("u32 w[80] = { 0 };" in the code). This bug would cause incorrect
> (nondeterministic) operation, unless that area of memory happened
> to be initialised to zero. The initial Blowfish S-boxes also have
> some errors (although that wouldn't affect security).
IMHO "u32 w[80] = { 0 };" initializes the entire array to zero. See
Bjarne Stroustrup - The C++ Programming Language - Second Edition -
R.8.4.1. If I'm wrong, use memset.
> My advice would be not to use Ace/WinAce: there is no salt, and no
> attempt to slow down the hash, so dictionary attacks are much more
> feasible than they should be.
I don't know if there's some sort of delay in the ace32 executable.
I didn't continue examining it, after I had a working version of the
algorithm. Anyway, there's no essential need for such a delay, since
my implementation works without it. A dictionary attacks would be
easy to implement.
------------------------------
From: [EMAIL PROTECTED] (Craig Paul)
Subject: Re: CDMA tracking (was Re: GSM tracking)
Date: 23 Sep 2000 07:26:22 CST
In article <O3Xy5.2918$[EMAIL PROTECTED]>, "Lyalc" <[EMAIL PROTECTED]> writes:
> Unless the safe's case forms an integral, seamlessly conductive surface and
> is grounded, the safe's skin can act as a coupled antenna to an internal
> transmitter in some circumstances.
>
> Needing the safe's skin to be electrically seamless and of low impedance at
> the particular frequencies is the first major challenge.
>
> Even is the safe offers say 30db of attenuation, the 1 watt power ouput of
> the phone (ie 30 dbm) means the signal outside the safe would be around
> 0dbm.
The CDMA carrier will be max 200 mW.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Software patents are evil.
Date: 23 Sep 2000 12:27:26 GMT
[EMAIL PROTECTED] (Trevor L. Jackson, III) wrote in
<[EMAIL PROTECTED]>:
>I seem to have missed the preceding couple of messages. Usenet in
>action I suppose.
>
>There are a couple of observations worth making:
>
>1. Patents are not monopolies. They protect intellectual property not
>business entities. Trade secrecy would seem to be a better target for
>monopolistic claims in that the life of a trade secret is unbounded.
>
>2. Using the USSR as a foundation for attacking the patent system is
>silly. The dominant characteristic of the economy of the USSR was the
>lack of incentives. The patent system is by design an incentive system.
> Thus the existence of the patent system is for precisely the opposite
>of the reasons for the economic failure of the USSR
>
>3. The USSR was not an attempt to set up a fairer economic system,
>although that claim has been widely spread. It was a tyranny. Check
>the official definition of the term pravda (truth). It means "whatever
>will foster success". This is fairly orthogonal to our concept of truth
>as a relationship between axioms and theorems (math) or reality and
>statements (science).
>
This hits hard. I know maybe Russia failed due to things like above.
But where does this leave us today. Just what is the defination of
"TRUTH" today in the U.S. government. Has not Clinton changed forever
the meaning of truth as nothing more than "whatever is politically
exspedient". Aren't we fast heading to the state of affairs that lead
to the Russian collapse.
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: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sat, 23 Sep 2000 13:38:40 GMT
I must disagree.
Say you have many files, each 2^20 bytes in length and you are going to use
256 check bits.
The set of files of length 2^20 consists of 2^8388608 unique files but
there are only
2^256 check codes. So each check code, weather sum of CRC, is share among
2^8388352
files. So many, many files have the same check, and that why neither check
scheme is perfect.
The superiority of either check scheme depends on the differences in the
files. In the case
of my unstated assumption of random data, I believe that I can demonstrate
(perhaps with
a smaller example) that neither is better. But if the files are all almost
identical, and
the differences are limited to a single burst of 256 bits or less, the CRC
is better because
it will always distinguish the files.
"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> On Fri, 22 Sep 2000 22:46:34 GMT, in
> <ejRy5.2094$[EMAIL PROTECTED]>, in
> sci.crypt "bubba" <[EMAIL PROTECTED]> wrote:
>
> >May I suggest an XOR checksum. A CRC is advantageous only when you
> >are trying to detect burst errors (aligned, contiguous differences in
> >otherwise
> >identical files in your case) of less that 128 or 256 bits in length (for
> >the
> >polynomials you mentioned).
>
> While both a 256-bit CRC and a 256-bit XOR would detect a single bit
> difference, in general, a CRC is *vastly* more likely to catch
> arbitrary differences than XOR. For example, if the same wrong block
> repeats any even number of times, XOR will not find it, no matter how
> many differences that block contains. In contrast, CRC is insensitive
> only to patterns which are factors of the CRC polynomial.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Big CRC polynomials?
Date: 23 Sep 2000 15:57:25 +0200
In article <8qgg1h$pmc$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> I'm seeking good 128- and 256-bit CRC polynomials. I've done a bit of
> searching about on the net and have only been able to locate commonly used
> polynomials of 32 and fewer bits. My intention is to use either a 128- or
> 256-bit polynomial for the purpose of uniquely identifying large numbers
> (millions) of binary files; consequently, a 32-bit CRC is probably a bit too
> small for this purpose.
>
> Can anybody point me in the direction of some big polynomials to use for this
> purpose? I could just randomly generate a polynomial for this purpose but if
> somebody has/knows a "good" polynomial of this size it would be most helpful.
> I unfortunately don't have the expertise nor the time necessary to develop
> sufficient expertise to write polynomial generation routines which will pick
> "good" polys.
Why not use MD5 or SHA instead? They produce hashes of 128 resp 140 bits,
they're very well tested, and they would be excellent for this purpose.
Free C source for MD5 and SHA are available from many places on the Net.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Date: Sat, 23 Sep 2000 16:25:44 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Maximal security for a resources-limited microcontroller
Sagie wrote:
> One more question:
> When selecting a key for the SkipJack algorithm, should I use a big
> prime or may I use any random 80-bit constant? Is there any difference?
It should only be unpredictable.
You mix symmetric and asymmetric ciphers.
Symmetric ciphers use some random bits (the key) for both encryption
and decryption. Skipjack is an example for a symmetric cipher, there
are also many others (DES, IDEA, Blowfish, RC4, RC5, Seal, the AES
candidates: Twofish, Serpent, Rijndael, and many others). Symmetric
ciphers are either stream ciphers (RC4, Seal) or block ciphers (all
others from the list above).
Asymmetric ciphers use some hard to break formula, such as factoring,
to create a private key and derive a public key from it. The public
key is published and then used for encryption, the private key is
secret and can decrypt. The trick is that it is very hard to compute
the private key from the public key.
In the case of, for example, RSA, you need two very big prime
numbers to create the public/private key pair.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Date: Fri, 22 Sep 2000 18:18:39 -0700
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:8qgfir$gim$[EMAIL PROTECTED]...
> In <VzMy5.1023$[EMAIL PROTECTED]> "Paul Pires"
<[EMAIL PROTECTED]> writes:
> ]> seems to me to fly in the face of all evidence. The software industry
> ]> took off with no patents. patents as a corporate tool in software has
> ]> really only taken ahold in the past few years, and is being used to
> ]> stifle not enhance competition and innovation. As in a criminal court,
> ]> the evidence should be there beyond a reasonable doubt that the monopoly
> ]> is essential befor any such monopoly should be granted.
>
> ]A trial to grant a patent? If you want to kill it, get out your gun i.e.
>
> No, not a court trial, a standard of proof.
Hehehe... Guess what, Invention is like random or secure crypto.
No proof is possible. Just screens to filter out most of what it is not.
>
> ]A constitutional ammendment against this task as a role of our (US)
government
> ]don't offer reasonable compromise to leave it castrated but in place.
>
> ?? I do not understand this sentence.
>
> The referents to "it" and "this" are unclear.
Bad snipping. Let me re-assemble it.
> ]A trial to grant a patent? If you want to kill it, get out your gun i.e.
> ]A constitutional amendment against this task as a role of our (US) government
> ]don't offer reasonable compromise to leave it castrated but in place.
"It" is the patent process. "This task" is the task of granting patents.
The power to grant patents is provided in the constitution. If you don't like
patents,
you can amend the constitution or "Fix" it in a regulatory fashion so that they
become
meaningless. Just about every suggestion I have heard for Fixing the patent
process
is in fact a way of abolishing it by regulation.
Paul
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sat, 23 Sep 2000 15:00:07 GMT
In article <An2z5.3775$[EMAIL PROTECTED]>,
"bubba" <[EMAIL PROTECTED]> wrote:
> I must disagree.
>
> Say you have many files, each 2^20 bytes in length and you are going
to use
> 256 check bits.
>
> The set of files of length 2^20 consists of 2^8388608 unique files
but
> there are only
> 2^256 check codes. So each check code, weather sum of CRC, is share
among
> 2^8388352
> files. So many, many files have the same check, and that why neither
check
> scheme is perfect.
>
> The superiority of either check scheme depends on the differences in
the
> files. In the case
> of my unstated assumption of random data, I believe that I can
demonstrate
> (perhaps with
> a smaller example) that neither is better. But if the files are all
almost
> identical, and
> the differences are limited to a single burst of 256 bits or less,
the CRC
> is better because
> it will always distinguish the files.
I strongly disagree. Try this math "1 xor 1 xor 1 xor 1 = 1 xor 1".
So four differences are the same as two differences...A CRC has the
property that even/odds errors will not always result in the same
checksum.
At either case, if you need a 128-bit checksum use MD4 or MD5 or alike.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 23 Sep 2000 11:32:53 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Tim Tyler wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> :> ... David is discussing the effect of adding an additional section
> :> of known plaintext to the end of the file. This normally has the
> :> effect of decreasing the keyspace by almost exactly five bits -
> :> provided the effective keyspace doesn't go negative, of course.
>
> : With all due respect, this is complete nonsense.
>
> : When we talk about "reducing the keyspace", that means reducing the
> : size of the set of keys that need to be considered at all; it does
> : not mean finding a test that will eliminate keys by testing them one
> : by one.
>
> I try to use the term "effective keyspace", when discussing this type of
> rapid elimination of whole classes of keys - I used the word "effective"
> in the section quoted above - though I see that Icould have used it again
> where I did not, and gained some clarity.
>
> The technique can reduce the time taken to deal with specific keys,
> and can /sometimes/ speed up the process of a keyspace search.
>
> I'm reasonably happy with describing the effect as "a reduction in the
> effective keyspace" - despite the fact that the keys still exist, and may
> still require /some/ consideration.
>
> If you have better terminology that you think I should be using,
> I'd be happy to hear about it, I would like to be able to concisely say
> that some volume of keys can be rapidly and certainly ruled out.
>
> Currently, I would normally describe this as ``a reduction in the
> effective keyspace of "n" bits.'' If this is going to rub people up the
> wrong way, how would they like me to put it.
Diffidently I suggest the awkward phrase "partial keyspace work factor reduction".
------------------------------
From: [EMAIL PROTECTED] (JAMES LANKTON)
Subject: Please verify
Date: Sat, 23 Sep 2000 15:37:12 GMT
Reply-To: [EMAIL PROTECTED]
I saw this post in another forum, and if possible some feedback would
be welcome
James Lankton
"hi, there,
a few years ago i bought a book about encryption/decryption and security. it
said that a brute force attack on a pgp code would take quite long (some
years i think) even if all internet computers would be connected to a
cluster.
but now a friend told me, he had tried a brute force attack on his own key
using a cluster with four athlon 1 ghz and each 1 gb of ram (linux of course
;) ) and it took about 17 hours to get the 4096 bit key.
of course this cluster has not the performance the whole internet would have
about 3 years ago, so someone has to be wrong.
what do you know about that?
it may sound like paranoia but i think of the nsa for example, who can use
more powerful clusters of course. i do not have any information which is
_that_ important, but i don�t like the thought my coded messages could be
read by unautorized persons, even if i don�t do anything wrong on security.
bye,
tobi"
------------------------------
Date: Sat, 23 Sep 2000 18:23:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Paul Schlyter wrote:
> In article <8qgg1h$pmc$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > I'm seeking good 128- and 256-bit CRC polynomials. I've done a bit of
> > searching about on the net and have only been able to locate commonly used
> > polynomials of 32 and fewer bits. My intention is to use either a 128- or
> > 256-bit polynomial for the purpose of uniquely identifying large numbers
> > (millions) of binary files; consequently, a 32-bit CRC is probably a bit too
> > small for this purpose.
> >
> > Can anybody point me in the direction of some big polynomials to use for this
> > purpose? I could just randomly generate a polynomial for this purpose but if
> > somebody has/knows a "good" polynomial of this size it would be most helpful.
> > I unfortunately don't have the expertise nor the time necessary to develop
> > sufficient expertise to write polynomial generation routines which will pick
> > "good" polys.
>
> Why not use MD5 or SHA instead? They produce hashes of 128 resp 140 bits,
(160 bit, not 140)
> they're very well tested, and they would be excellent for this purpose.
> Free C source for MD5 and SHA are available from many places on the Net.
Tiger from Eli Biham (http://www.cs.technion.ac.il/~biham/) should also
be mentioned at this place. According to Biham, it is as fast as SHA-1
on 32-Bit machines, and faster in all different environments, especially
on 64 Bit ones.
Tiger produces 196 bits of output. It is very young but I think for this
case it doesn't matter, because even if someone would break it it will
still fit the requirements for that purpose.
However, IMHO a cryptographically hard hashsum is a little bit too much
for this purpose.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Please verify
Date: 23 Sep 2000 16:17:30 GMT
[EMAIL PROTECTED] (JAMES LANKTON) wrote in
<8qiin9$svl$[EMAIL PROTECTED]>:
>
>I saw this post in another forum, and if possible some feedback would
>be welcome
>
>James Lankton
>
>"hi, there,
>
>a few years ago i bought a book about encryption/decryption and
>security. it said that a brute force attack on a pgp code would take
>quite long (some years i think) even if all internet computers would be
>connected to a cluster.
I don't think at the time the books was sritten all the computers doing
a dumb blind brute force seach could even find the key for Enigma. Which
was broken in WWII before the PC of today. Quoting how long a blind search
we take is meaningless.
>but now a friend told me, he had tried a brute force attack on his own
>key using a cluster with four athlon 1 ghz and each 1 gb of ram (linux
>of course ;) ) and it took about 17 hours to get the 4096 bit key.
>of course this cluster has not the performance the whole internet would
>have about 3 years ago, so someone has to be wrong.
>what do you know about that?
>
You friend was not doing a blind search since it would take much
longer. He and his friends may have stumbled on some weakness in the
key generation. If he is still alive you should get him to post here.
>it may sound like paranoia but i think of the nsa for example, who can
>use more powerful clusters of course. i do not have any information
>which is _that_ important, but i don�t like the thought my coded
>messages could be read by unautorized persons, even if i don�t do
>anything wrong on security.
>
>bye,
>
>tobi"
I too think the NSA can easily break PGP the question is which way
is faster breaking the public key portion or the symmetric cipher
portion.
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Sat, 23 Sep 2000 19:10:59 +0200
"SCOTT19U.ZIP_GUY" wrote:
> If your "STATIC HUFFMAN TREE IS SECRECT" then having
> a EOF symbol still sucks. I am not saying finding the tree is
> easy it may be very hard. But still the EOF symbol is likely
> to be the longest symbol and the last symbol. Why use it at
> all. But if you can't see a reason then by all means you can
> use it.
Since the whole tree is unknown, how does the opponent
identify the eof, even if he knows it is longer than
the rest? (Note that there are random filling after it
too in general.) I used eof in my secret scheme to
cater for the general case where one may have to meet
word boundary, even block or record boundary, instead of
byte boundary. As Benjamin Goldberg pointed out, for
meeting byte boundary, it is in most cases sufficient
to use part of one of the longest symbol for that
purpose, if it has at least 8 bits.
BTW, does your program deals with also word or block
boundary in addition to byte boundary?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Sat, 23 Sep 2000 19:11:13 +0200
"SCOTT19U.ZIP_GUY" wrote:
> I am surprised you took back anything it must be a trick.
> But the answer above is obvious. when he said 32 he was referring
> to a afactor of 32 which for 5 bits is 32 = 2*2*2*2*2 in short
> two to the the power 5. But you must known that just as you must
> know that haveing an EOF symbol in a compresson of huffman or
> arithmetic type before the file is encrypted is a mistake.
It was indeed my error in employing the zero fill in
the argument I gave, for that provides known information.
If I had written '5 random bits' instead, then everything
would have been o.k.
Using eof in a secret Huffman scheme is not a mistake, as
I argue in a parallel follow-up.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sat, 23 Sep 2000 19:10:54 +0200
"David C. Barber" wrote:
>
> DES, for example is considered resistant to Differential Cryptanalysis,
> particularly in its selection of S-boxes. What about them, or any cipher,
> makes it DF resistant?
I believe that one good way is to arrage to have the
S-boxes of the cipher be all different and to have
them either key-dependent or fixed but having their
ordering dependent on the key. I like to know references
to analysis results for such situations, if any.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
