Cryptography-Digest Digest #776, Volume #10 Tue, 21 Dec 99 03:13:01 EST
Contents:
Re: DES as pseudo random number generator (UBCHI2)
Re: An attack on the WTLS SHA_XOR_40 MAC algorithm (Markku-Juhani O. Saarinen)
How do you know if you found a key? (Greg)
Re: RST discovers defective crypto in Netscape mail password saver (Ken Lamquist)
Re: AES and MATTS COMPRESSION ("Matt Timmermans")
Re: Q: transcendental pad crypto ("dls2")
Re: Q: transcendental pad crypto ("Trevor Jackson, III")
Re: How do you know if you found a key? (David A Molnar)
WEBPAGE UPDATED (SCOTT19U.ZIP_GUY)
Re: compression & encryption (Ken Lamquist)
Re: Keystrokes monitored/encryption useless (Guy Macon)
firmware encryption? ([EMAIL PROTECTED])
Re: US Patent Office: How Stupid? Look Here... (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: DES as pseudo random number generator
Date: 21 Dec 1999 02:11:00 GMT
It's not a bad idea at all. Just run your fingers randomly over the keyboard.
Then encrypt with des. Then you pull out the numbers out of the encrypted text
and use those as a one time pad. Neat Idea!!!!
------------------------------
From: Markku-Juhani O. Saarinen <[EMAIL PROTECTED]>
Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm
Date: 21 Dec 1999 02:18:15 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> David Wagner wrote:
> > Good catch. Yeah, I agree: the so-called WTLS 'XOR MAC' is seriously
> > flawed, and definitely should be eliminated with all possible haste.
> > Submitting your result to WAP might be useful, to keep them honest.
> I have done; I'll also point them to Saarinen's paper and outline your
> repeated ciphertext attack.
The WAP security group is aware of the results presented in my paper [1].
I have received the usual telecom-industry "doesn't work in practice" type
of note regarding the results presented in my paper :-)
> Has anyone checked whether the elliptic curves that do not have seeds given
> for them are of any special form, BTW?
They appear to be ok as far as I can tell. My guess that they were
actually computed by Certicom (Certicom is selling a WTLS toolkit).
I am currently updating and expanding the original paper [1]. Now that WAP
and WTLS implementations are becoming available (Nokia, Siemens, Microsoft
/ Benefon, etc.) the issue of security bugs resulting from implementation
detail is an interesting one.. I hope that I can get some funding for that
line of research.
- mj
Markku-Juhani Saarinen <[EMAIL PROTECTED]> University of Jyväskylä, Finland
[1] Markku-Juhani Saarinen, "Attacks Against the WAP WTLS Protocol,"
Secure Information Networks: Communications and Multimedia Security
'99, Kluwer Academic Publishers, Boston, 1999, pp. 209--215
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: How do you know if you found a key?
Date: Tue, 21 Dec 1999 04:15:08 GMT
If you take random data, and you encrypt it with DES, then
you search for the key using any and all known attacks, how
do you know when you found the right key?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Ken Lamquist)
Subject: Re: RST discovers defective crypto in Netscape mail password saver
Date: 21 Dec 1999 04:32:52 GMT
Gary McGraw writes that "the encryption algorithm used by Netscape to
scramble [E-mail] passwords is exceptionally weak." Encryption normally
refers to encoding data in such a way that it is computationally
infeasible to decode the data unless you know a secret key. Netscape
does not do this with E-mail passwords. It does use a form of
security through obscurity: the way that E-mail passwords are stored
on disk is not documented. If security through obscurity worked
perfectly in this case, it would mean that people would only be able
to use the E-mail password by running netscape. Accessing E-mail
using the password would still be trivial. Actually getting the
password would be harder. Allowing for the inevitable MS Windows
crash, it might take a pair of knowledgeable people a few hours to run
netscape and capture the E-mail password it sends out.
"Security through obscurity" is insecure, so McGraw's report that it
took a pair of people eight hours to figure out how netscape stores
E-mail passwords on disk is no big surprise. Since this is longer
than the expected time to obtain the password just by running the
program, it appears that in this case, security through obscurity has
provided the (minimal) level of security expected of it.
According to the RST web page, RST does consulting for firms which
want to improve the security of their software. I have no way of
knowing the quality of this consulting work. If their advice to
companies relying on security through obscurity is simply to make the
software more obscure--even if the software contains other holes so
that penetrating the existing obscurity is not the most efficient
course of action for an attacker--then the risks are obvious.
Kenneth Almquist
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: AES and MATTS COMPRESSION
Date: Tue, 21 Dec 1999 04:34:54 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote in message
news:83inb5$1t5g$[EMAIL PROTECTED]...
> [...] But Matts seemd to
> go to any bytes size directly. He converts his fintely odd bit stream
> to a nonnegtive integers and than applies a series of %256 to get it
> to byte. If one use a larger base you could go to any byte size in
> a one to one or bijective way.
If anyone would like the URL, feel free to mail me at matt at timmermans dot
org.
Please note that I make no claims for the usefullness of bijective
compression as a pre-process for encryption... The primary contribution made
by the bijective compressor that is available and described on my page is
the new end-treatment for arithmetic and huffman coding that does not waste
bits. The bijective part is cool, though.
David's description was accurate five minutes ago, but I just changed this
final mapping from finitely odd bit streams to files. Now, the arithmetic
encoder, which is a bijection from its input to finitely odd numbers in
[0,1), is follwed by a trivial Huffman decoder (it just maps every byte to
itself) that is a bijection from finitely odd numbers to files.
This new method also has the properties David mentions, and I have added a
switch to the executable to select a block size for the compressed
representation.
------------------------------
From: "dls2" <[EMAIL PROTECTED]>
Subject: Re: Q: transcendental pad crypto
Date: Mon, 20 Dec 1999 23:16:07 -0500
"Pelle Evensen" wrote:
> "dls2" wrote:
> > "John Savard" wrote:
> > > "dls2" wrote:
> > >
> > > >Do transcendental numbers qualify as pseudo-random, or
> > > >as truely-random, for purposes of one-time pads?
> > >
> > > Pseudo-random, since calculating the value of a transcendental
> > > number is a deterministic process. And an inefficient one, for the
> > > level of security provided.
> >
> > If there are an infinite number of transcendental numbers, then I fail
> > to see why. If the transcendental is picked randomly, then doesn't
> > the resulting stream of numbers also qualify as random?
>
> No. The reason being that it's reproducable. I assume your goal is to
> expand a small bit of secret to a large bit of secret. This doesn't help
> entropy at all, that is, the rate of entropy will be the same as the
> entropy of the initial seed, no matter what kind of expansions or series
> you apply with the seed as the starting point.
"We can measure how bad a key distribution is by calculating its
entropy. This number E is the number of `real bits of information'
of the key: a cryptanalyst will typically happen across the key within
2^E guesses. E is defined as the sum of -p_K log_2 p_K, where
p_K is the probability of key K." Cryptography FAQ, 4.9.
Since the seed is one of an infinite number of transcendental choices,
the entropy is great, which is terrific. OK, so what's the problem?
Derrick Shearer
[EMAIL PROTECTED]
------------------------------
Date: Tue, 21 Dec 1999 00:49:18 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Q: transcendental pad crypto
dls2 wrote:
> "Pelle Evensen" wrote:
> > "dls2" wrote:
> > > "John Savard" wrote:
> > > > "dls2" wrote:
> > > >
> > > > >Do transcendental numbers qualify as pseudo-random, or
> > > > >as truely-random, for purposes of one-time pads?
> > > >
> > > > Pseudo-random, since calculating the value of a transcendental
> > > > number is a deterministic process. And an inefficient one, for the
> > > > level of security provided.
> > >
> > > If there are an infinite number of transcendental numbers, then I fail
> > > to see why. If the transcendental is picked randomly, then doesn't
> > > the resulting stream of numbers also qualify as random?
> >
> > No. The reason being that it's reproducable. I assume your goal is to
> > expand a small bit of secret to a large bit of secret. This doesn't help
> > entropy at all, that is, the rate of entropy will be the same as the
> > entropy of the initial seed, no matter what kind of expansions or series
> > you apply with the seed as the starting point.
>
> "We can measure how bad a key distribution is by calculating its
> entropy. This number E is the number of `real bits of information'
> of the key: a cryptanalyst will typically happen across the key within
> 2^E guesses. E is defined as the sum of -p_K log_2 p_K, where
> p_K is the probability of key K." Cryptography FAQ, 4.9.
>
> Since the seed is one of an infinite number of transcendental choices,
> the entropy is great, which is terrific. OK, so what's the problem?
There are at least two issues related to finiteness. First the theoretical
population of transcendental numbers is large. But the number of proven
transcendental numbers is both finite and small. So you cannot pick from an
infinitely large population. Only from a small, finite one. The logarithm of
the size of that population is the effective length of your true key in bits.
Not the keys you wudda, cudda used in theory, but the ones you actually can
use in practice.
Second issue is that when you make a pad out of a transcendental number you
use some finite set of the leading digits (even if you skip some) and truncate
the rest -- the infinite tail. This damages the number in such as way as to
destroy its transcendentalness. In fact no finite string of digits is even
irrational much less transcendental.
There is no magic in the infiniteness of the number of transcendantal numbers
or their non-repeating length. You can't use anything that is infinite in
either sense. So any crypto system you build will not benefit from those
properties.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: 21 Dec 1999 06:10:04 GMT
Greg <[EMAIL PROTECTED]> wrote:
> If you take random data, and you encrypt it with DES, then
> you search for the key using any and all known attacks, how
> do you know when you found the right key?
What does the random data mean? is there something else which depends
on it which can act as a check on your decryption?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: WEBPAGE UPDATED
Date: Tue, 21 Dec 1999 07:43:45 GMT
I added some useful tools for people wanting to convert to
or from finitely odd files. Added pointers to TIms and Matt
pages concerning the study of compression to be used
before encryption.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (Ken Lamquist)
Subject: Re: compression & encryption
Date: 21 Dec 1999 06:59:22 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> lordcow77 <[EMAIL PROTECTED]> wrote:
>
>: Show me a modern block cipher so throughly broken that one can use
>: known-plaintext characteristics of the first two bytes of the block to
>: reduce the keysearch space and I'll show you a block cipher that one
>: should never use. Or better yet, give me an ACTUAL EXAMPLE of such an
>: "attack" on any reasonable block cipher construction, even a badly
>: broken one like FEAL-4.
>
> Brute force against DES qualifies on both these counts, AFAICS.
>
> The known plaintext allows the rejection of > 99.99% of the possible keys
> after decrypting a single block, without even bothering to attempt
> decompression.
>
> The space you subsequently have to apply a /serious/ search to - i.e.
> decrypting (possibly the entire message) and decompressing before
> examining plaintext frequencies closely, is reduced to less than 0.01%
> of its original size.
The question is how much longer a /serious/ search over the entire
key space takes than a search for a known plaintext. You are counting
on compression to make the /serious/ search hard. I don't see any
reason to be confident that this approach works. In general, confidence
that certain things (such as breaking DES faster than a brute force
search) cannot be done in cryptography comes from a lot of smart
people trying to find a way to do it and failing. When the field
doesn't even have standarized terminology to refer to a problem
(the term "serious search" is not a standard cryptographic term), it
is a safe bet that the problem has not received a high degree of
scrutiny.
Furthermore, there is a published attack on using compression to
slow down exhaustive search. Given the encryption of a known
document, the attacker can compress the document once, and then
perform the brute force search against the encrypted form of the
document. This attack requires the attacker to have both the
encrypted and plain text of a document, but it is hard to design
a useful system in which this cannot happen.
If you want to be confident that the /serious/ search is actually
hard, I believe you have to rely on cryptographically strong processing,
and not just compression. An example of this approach is double DES.
The best attack against double DES that I know of is the meet in the
middle attack, which requires looking up the decrypted text in a table
containing 2^56 entries. If you stored this table on a massive farm
of hard disks, a random access would take at least 10 milliseconds.
My guess is that no one today has the ability to perform a brute force
search against double DES.
However, it is only a matter of time before breaking double DES
becomes practical. Computing power has been growing at an exponential
rate. In contrast, a scheme like double DES strengthens the
encryption by a constant factor. Serious attempts to improve on DES
(such as triple DES and AES) increase the size of the space required
to be searched by a brute force attack, rather than trying to increase
the time to test a single key.
Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Keystrokes monitored/encryption useless
Date: 21 Dec 1999 02:39:07 EST
In article <83kdfd$92g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (molypoly) wrote:
>
>
>> I like to run a couple of 30AWG wire wrap wires into the plug on the
>> back of your PC and connect a Basic Stamp [
>http://www.parallaxinc.com/ ]
>> and have it record keystrokes. It's about the size of a postage
>stamp,
>> and there are cool RF transmitter modules available. This allows me
>to
>> get the NT Logon password, which no sniffer program can get. For that
>> matter. there are TX cameras that look through pinholes in your walls
>> or ceiling. I could make a video of your hands on the keyboard and
>> of what is displayed on your screen.
>>
>> If you don't secure your computer physically, I can defeat any
>security
>> system you install with little trouble.
>>
>>
> You're one sick puppy . . . what else do you do with those cameras?
Why keep an eye on my poor sick puppy, of course. Is there some other
use that I didn't think of?
How did you know that my puppy was sick this week?
------------------------------
From: [EMAIL PROTECTED]
Subject: firmware encryption?
Date: Tue, 21 Dec 1999 07:49:35 GMT
Hello All,
I am designing a microcontroller-based system (an 8051) that will be
deployed to a large number of customers. The controller contains on-
chip flash memory, so I wanted to take advantage of it by releasing
controller code (i.e. firmware) updates periodically as needed. The
user would simply download the firmware into the box. The controller
would then read the data and reprogram itself with the new code. BUT
the code needs some security via encryption, so that one cannot simply
disassemble it.
So the system looks like it needs an encryption algorithm with the
following traits:
1. Can run ok on a 8-bit processor
2. Uses little RAM (<256 bytes)
3. Most importantly, can use a single key burned in the chip with no
further key exchange.
I have been looking at Blowfish with modest key sizes. Does this seem
appropriate ... any other suggestions?
Thanks in advance,
Dan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: US Patent Office: How Stupid? Look Here...
Date: Mon, 20 Dec 1999 23:47:44 -0800
Reply-To: [EMAIL PROTECTED]
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> Much like your web site, you seem set to make a lot of emotional
> claims, but provide as little real information as possible. Just for
> example, if you want anybody to make intelligent comments instead of
> just listening to you blow off steam, you NEED to tell us the number
> of the patent you're talking about.
>
> After doing some searching, I'm _guessing_ that you're referring to US
> patent number 5,414,771. I'm not sure of that, but it's about the
> only one I can find with in inventor named "Fawcett, Jr.", that looks
> related to the generation of random sequences.
>
> > Well, of course the invention claims that any hardware and any
> > software can be used to merge these random bit sequences in any
> > way known, imaginable, or heretofore yet to be conceived.
>
><snip>
>
> Your algorithm offers nothing that isn't already done better by freely
> available algorithms, though I suppose a patent might give you a bit
> more grist for the hype mill (aka web page) describing your product.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
Actually there are 19 claims in Fawcett, Jr.: 6 independent claims
and 13 dependent claims.
Claim 1, claim 5, and claim 9 are independent and are further
specified with dependent claims stating the specific use of modulo
two addition, a noise generating device, and modulo two addition
again. Since my method does not use any of these, my method is not
covered by these claims and associated dependent claims. I do not
combine anything and certainly do not combine anything using modulo
two addition. The random number generator cannot produce the
permutation sequences my method requires so the methods are clearly
not the same.
Claim 13 uses quasi-random elemental sequences which is not defined
in the claims nor is the combinational key generation means. But the
specification clarifies these as using random noise generator(s) and
thus the elemental sequences are quasi-random bit sequences. The
specification also states that the quasi-random sequences are read
in sequence. Thus a reasonable expectation is that, again, the method
of Fawcett, Jr. cannot generate the randomly ordered permutation
sequences of the digits 0 - 9 required in my method.
Claim 15, again, states the use of at least one random noise generator
and therefore the method of Fawcett, Jr., again, cannot generate the
randomly ordered permutation sequences of the digits 0 - 9 required
in my method.
The last independent claim is 19. Again it uses random elemental
sequences on multiple disks and combines them. Looking at the
specification we again conclude that random elemental sequences
are just that and my randomly ordered permutations of the digits
0 - 9 are not random elemental sequences. And lastly, my method
does not combine anything. My method merely references the
randomly ordered permutations of the digits 0 - 9 required in my
method.
To understand the meaning of ambiguous terms in a claim the
specification is referred to. If the specification were not
referred to then the term "random elemental sequences" would be
undefined since there is no common accepted meaning of the term
by practitioners of the art, in this case, cryptography.
This is also true for the same reason in order to understand the
terms "combinational key generation means."
"Your algorithm offers nothing that isn't already done better by freely
available algorithms..."
For instance?
(Keep in mind that my described method is just how I generate the
random digit stream. There are other steps before the OTP files
are generated.)
I think you are jumping to conclusions. Email me from my web site
http://www.ciphile.com to get a shareware copy of the software so
you can make informed judgments of OAP-L3.
Do these other methods use mathematical calculations in the
encryption process such as multiplying large primes with the file
to be encrypted?
My method does not multiply using large primes. You cannot attack
my method by attacking the mathematical calculation because there
are none that can be attacked. This is of great benefit for
security.
There are other reasons why OAP-L3 is known to be secure.
Get the software.
(I took some care here but forgive any mistakes. Thanks.)
------------------------------
** 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
******************************
