Cryptography-Digest Digest #777, Volume #10 Tue, 21 Dec 99 11:13:02 EST
Contents:
Re: firmware encryption? (Volker Hetzer)
Re: QPK (Mok-Kong Shen)
Re: firmware encryption? (Paul Rubin)
Re: US Patent Office: How Stupid? Look Here... (Alan Braggins)
Re: compression & encryption (SCOTT19U.ZIP_GUY)
Re: How do you know if you found a key? (SCOTT19U.ZIP_GUY)
SEE THIS ("frank arache")
Re: Attacks on a PKI (Timothy M. Metzinger)
Re: How do you know if you found a key? (David A Molnar)
Re: How do you know if you found a key? ("Gary")
UNADULTERATED RLE COMPRESSION (SCOTT19U.ZIP_GUY)
Re: DES as pseudo random number generator (Eric Lee Green)
Re: firmware encryption? ([EMAIL PROTECTED])
Re: Q: transcendental pad crypto ("Tony T. Warnock")
Re: DES as pseudo random number generator ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: firmware encryption?
Date: Tue, 21 Dec 1999 09:17:09 +0000
[EMAIL PROTECTED] wrote:
> 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?
Have a look at the AES candidates. The finalists are all more than adequate for
your job and are designed to be implementable on small controllers
(among other things).
See http://www.nist.gov/aes for details and specifications.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: QPK
Date: Tue, 21 Dec 1999 10:17:55 +0100
Medical Electronics Lab wrote:
>
> There are 2 ways to do something like this. One is just
> straight forward "probablistic encryption", which gives
> you multiple possible outputs. They don't necessarily mean
> anything, only 1 will be the useful answer. Another idea
Sorry that I have not been following discussions in this thread.
But I do like to know what is your definition of 'probabilistic
encryption'. Do you mean a process where at some step a decision
is made depending on the output of a (deterministic) pseudo-random
generator or else on a truly random event which even the legitimate
receiver of the encrypted message can't know/predict? The first
case would only be an application of PRNG (I used it in one of my
schemes), while in the second case the receiver has no easier job
than the analyst, or do I miss something?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: firmware encryption?
Date: 21 Dec 1999 09:26:42 GMT
In article <83nbee$9e0$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>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?
Blowfish needs 4k of ram. Try Skipjack, which needs just a few bytes.
Note that if someone really wants the code, they will attack the hardware
and get around the encryption. You really can't prevent this without
making your device very expensive.
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: US Patent Office: How Stupid? Look Here...
Date: 21 Dec 1999 12:04:48 +0000
[EMAIL PROTECTED] (Ian Goldberg) writes:
> It's time to play "stupid patent of the day". Here's an entry:
>
> http://www.patents.ibm.com/details?&pn=US05443036__
>
> Method of exercising a cat
>
> A method for inducing cats to exercise consists of directing a beam of
> invisible light produced by a hand-held laser apparatus onto the floor
[...]
> (Luckily, the claim only covers "a beam of invisible light". All the
> handheld lasers I've seen clearly produce _visible_ light, so they'd not
> be covered.)
Presumably the author intended to say that the beam was invisible
(i.e. using the laser in a smoky or dusty atmosphere is not covered),
not that the light was invisible. (Using an IR laser powerful enough
to produce a glowing red spot where it hits the floor does seem an
unsafe method of exercising a cat). Anyone here qualified to give an
opinion on how a court might interpret it?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: compression & encryption
Date: Tue, 21 Dec 1999 13:48:37 GMT
In article <83n8ga$cdu$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Ken Lamquist) wrote:
>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.
I don't think that compression is the anwser to every thing.
Like I state over and over correct compression just does not add
information to a system. But if done correctly you are correct if
an attacker has a an "exact copy" of the plaintext and the encrypted
file he can just compress the file and then use it as he would have
used the plain text in a a system with out compression and test
all the keys. SO WHAT. It was never said that correct compression
would do every thing it was said it would not add information to the
system. However if one does not have a complete copy of the plaintext
and one does not compress the attacker attacker could look for that
fragment in the decrypted guess. So compression of almost any kind
can slow attack against this since the attacker has to decompress each
guess ( if it can be decompressed) to check for a match. But if you
know nothing at all about the message and non one-one compression used
the attacker can see if the guessed key goes to a file that could have
been compressed with the method used if you don't use proper compression
it is very likely only one soultion exists and that is the what the attacker
could find. If you used 1-1 compression any key the attacker guesses could
lead to a valid file that was compressed. This means the attacker must
use some extra knowledge to break the system. Something he does not
have to do if the user was dumb enough to use bad compression like PGP.
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] (SCOTT19U.ZIP_GUY)
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 13:56:26 GMT
In article <83n5js$1bd$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
>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?
I think by random he means that the file encrypted could be any possible
valid binary file that fits in the space he is encrypting. And in such a case
not knowing anything else about the file. It is impossible to find the file
that was encrypted since each of the 2^56 keys leads to what is as likely
as any other to a possible solution.
However if the cyrpto gods confused the poor man and he was dumb enough
to always run the same bad compressor as in PGP and then encrypt the file.
One can easily find the so called random file (or any file) that was encrypted
since it is likely only one key can lead to a file that could have been
compressed by the method used.
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: "frank arache" <[EMAIL PROTECTED]>
Crossposted-To:
sci.astro.amateur,sci.astro.seti,sci.chem.analytical,sci.electronics.misc,sci.electronics.repair,sci.energy,sci.engr,sci.engr.lighting,sci.geo.meteorology
Subject: SEE THIS
Date: Tue, 21 Dec 1999 09:13:38 -0800
Are you thirsty for america`s culture knowledge?
Have you ever wondered what south America and the
Caribbean forms of culture and expression means?
We take you on a trip into the Arts of this
Cultures, without the hassle of ticket buying,
migration troubles and all the expenses that a Trip
represents, bringing you the art at home.
We offer you a WIDE LIST of handmade arts, paintings
and all kind of cultural expresion from latin america.
So, if you like, collect or are simply curious about
how the South America and Caribbean people express es
their beliefs, ask for our catalag and find out the
beauty of their art.
For a complete full listing just reply this mail with your e-mail and tell
us your home country name.
------------------------------
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: Attacks on a PKI
Date: 21 Dec 1999 13:48:56 GMT
In article <83mcv6$lf8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>Dear Timothy,
>
>Please enlighten us by telling the 'lots' of reasons to look forward to
>PKI other than e-commerce.
>
>If a CA key in a PKI is compromised (doesn't have to be a root), you
>still think that stong authentication would hold?
>
>Many certificates these days are about as strongly authentic as a
>hotmail address - anyone can get one.
CA compromise of course invalidates everything below that CA in a PKI. But
that wasn't the question. The question was "what other uses besides e-commerce
is a PKI good for?" I mentioned authentication. here are some more. Digital
notarization, document archival, paperwork reduction, software maintenance of
critical systems.
A PKI's "web of trust" is dependent on CA policies and certificate practices.
Securing your CA is a very important piece.
I agree that lots of certs out there are bogus, but there ARE some standards
being formed on CA security requirements based on the use of the certs. Canada
has a pretty good model.
Timothy Metzinger
Private Pilot - ASEL - IA!!!! AOPA Project Pilot Mentor
DOD # 1854 '82 Virago 750 - "Siobhan"
Cessnas, Tampicos, Tobagos, and Trinidads at FDK
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: 21 Dec 1999 13:31:42 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> I think by random he means that the file encrypted could be any possible
> valid binary file that fits in the space he is encrypting. And in such a case
> not knowing anything else about the file. It is impossible to find the file
> that was encrypted since each of the 2^56 keys leads to what is as likely
> as any other to a possible solution.
OK. I wondered if that were the case, in which case I think you're right.
It's just that I'm trying to figure out when such a thing might actually
happen.
> However if the cyrpto gods confused the poor man and he was dumb enough
> to always run the same bad compressor as in PGP and then encrypt the file.
> One can easily find the so called random file (or any file) that was encrypted
> since it is likely only one key can lead to a file that could have been
> compressed by the method used.
This would be one thing - also he'd have to make sure that his encryption
program didn't append some kind of checksum in a known position in the
file. Because I expect the chances of having the rest of the data
match such a checksum or hash are pretty small when the key isn't right.
Thanks,
-David
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 14:17:33 -0000
If you encrypted a credit card number (with the checksum removed) by simple
repeated xor of a key then the key can't be found as there is no indication
to successful decryption.
However most plaintext has headers such as "dear sir" or file type
indicators. These are present even in the streams of compressors and can be
picked up by an analyst.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: UNADULTERATED RLE COMPRESSION
Date: Tue, 21 Dec 1999 16:14:57 GMT
Many of you know that I specialize in compression that
would be useful for a first pass before encryption since
unadulterated compression has no added information
that could be used by an attacker. This type of compression
might be useful for those who want to squeeze more out of
a compression. As far as I know the standard Run Length
Encoders Suck becase most are of the form
aaa gets replaced by *a3 so that *a3*a3 could uncompress
to aaaaaa and so could *a6
What I have is an RLE encoder that is such that
for any file X then decompress(compress(X))=X and
compress(decompress(X))=X so that any file can
be uniquely treated as a compressed file or an uncompressed
file in a unique way. In short it is "unadulterated compression"
If you wish to test it out get the file
"http://members.xoom.com/ecil/test.zip"
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Date: Tue, 21 Dec 1999 08:38:51 -0700
UBCHI2 wrote:
> 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!!!!
If the idea is "randomness", running your fingers "randomly" over the keyboard
ain't so random. Various statistical predictions can be made based on knowing
that this is what you did. For example, the sequence "asdf" is likely to occur
multiple times in the input. I would suggest keying the DES by using the time
jitter between keystrokes as the input to your random entropy pool, then, if
you wish to use DES as your PRNG, key DES from your random input and then run
DES in CFB/counter mode. This will give you a cycle time of 2**64, but that's
still better than most PRNG's. Better yet, use 3DES, and occasionally toss a
random number into your keypool (prior to the time that you'd start to cycle).
See Bruce Schneir's "Yarrow" paper at http://www.counterpane.com for more
info.
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: firmware encryption?
Date: Tue, 21 Dec 1999 15:49:47 GMT
Depending on the level of security you need you could try XORing it with
the code you are replacing. This would require the code to be kept
secret (instead of just a key). There may also be problems updating
firmware if several versions exist in the field. You would require a
method to prevent it being loaded into the a chip with the wrong
firmware version and a method of knowing what firmware is in a chip.
Also you would need to have some means of recovery if a download failed
half way (i.e. an address register that stores up to what address has
been changed and a copy of the old value stored at that address in case
the download failed in the process of writing to the location).
You biggest problem will be management of different firmware versions.
Although this could be manageble if only a small number of versions is
envisioned. (A firmware update file would consist of the firware XORed
with all previous versions, the download program interigates the chip to
get the current firmware version and downloads the relevant coded
version)
The solution isn't perfect but it is simple to code and it is very fast
to run.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Q: transcendental pad crypto
Date: Tue, 21 Dec 1999 09:01:21 -0700
Reply-To: [EMAIL PROTECTED]
dls2 wrote:
> "Tony T. Warnock" 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?
> >
> > How do you pick a transcendantal number at random? If one could
> > pick an object at random, the problem would be solved.
>
> Again, how does one pick anything at random?
> Is any selection really random?
>
> Derrick Shearer
> [EMAIL PROTECTED]
That's exactly the question. How do you intend to pick your transcendental
number. This is where all the problems occur. If you had a method for picking
numbers, the method would be itself suitable as a key generator. Quantum
mechanics is the only really random thing around so far.
------------------------------
Date: Tue, 21 Dec 1999 11:08:24 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Eric Lee Green wrote:
> UBCHI2 wrote:
> > 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!!!!
>
> If the idea is "randomness", running your fingers "randomly" over the keyboard
> ain't so random. Various statistical predictions can be made based on knowing
> that this is what you did. For example, the sequence "asdf" is likely to occur
> multiple times in the input. I would suggest keying the DES by using the time
> jitter between keystrokes as the input to your random entropy pool, then, if
> you wish to use DES as your PRNG, key DES from your random input and then run
> DES in CFB/counter mode. This will give you a cycle time of 2**64, but that's
> still better than most PRNG's.
You are overstating your case here. 64 bits is small for most reasonable PRNGs.
Marsaglia's PRNG library consists of a bunch of one-line PRNGs and I believe they are
all much larger than 64 bits..
------------------------------
** 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
******************************
