Cryptography-Digest Digest #761, Volume #10 Sat, 18 Dec 99 12:13:01 EST
Contents:
Re: Conditional (keyed) bidirectional hash function ? ("Gary")
Analogue encryption ("Gary")
Re: DES key safety (CLSV)
question (Atcherem)
Re: Analogue encryption (Amily Nerko)
Re: First step in finding primes (Terje Mathisen)
Re: 8192bit Encrypt >> Snake Oil, another one. (Amily Nerko)
Re: RSA, how to calculate big numbers ("Olaf Dokter")
Re: Are thermal diodes as RNG's secure (Tim Tyler)
Re: More idiot "security problems" (JPeschel)
First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Re: question (Tim Tyler)
MY WEB PAGE (SCOTT19U.ZIP_GUY)
Re: First Bijective Arithmetic Compression ("Gary")
Re: The 20 years periods did apply to 2 of the 3 patents. Why not for (Kent Briggs)
Re: Analogue encryption ("Gary")
Re: The 20 years periods did apply to 2 of the 3 patents. Why not for
([EMAIL PROTECTED])
Re: question ("Gary")
----------------------------------------------------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Conditional (keyed) bidirectional hash function ?
Date: Sat, 18 Dec 1999 12:28:11 -0000
>How important is hashing the original serial number A ? Would leaving
>it sequential weaken the authentication ?
>
> ... Niall
Theoretically signing the original serial number is no problem.
Reasons to hash:
A)Hashing is used as signing large messages is slow.
B)Most SDKs and libraries are set up to hash and verify messages.
C)Exporting can sometimes be allowed of very secure signing systems IF the
message is always exposed and the system can't be reversed easily to encrypt
messages. Governments agencies don't mind very secure signing, but they are
generally uneasy about secure cryptography used on messages.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Analogue encryption
Date: Sat, 18 Dec 1999 12:34:52 -0000
In old B&W films telephone conversations were scrambled.
Since digital modems weren't around then what did they do?
Did they overlay waveforms over the voice?
How did they synchronise? Did they have a tracking control on the phone?
If a pseudo one time pad is used to generate a wave form that overlays a
voice could this ever be as percievably secure as digital encryption?
Gary :)
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: DES key safety
Date: Sat, 18 Dec 1999 13:47:19 +0000
David Wagner wrote:
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > One question that would be nice to resolve is whether a single
> > 64-bit block of corresponding plain and ciphertext always
> > determines a *unique* 56-bit DES key. (It's not obvious.)
I am busy with a similar problem for 128-bit key/block
block-ciphers. If the cipher is random what is the probability that
using 2 different keys a plaintext block maps to the same
crypttext block. This is a sort of advanced birthday problem.
> However, it would be extremely surprising if the answer is `yes'.
> Here's a counting argument which suggests that the answer should be
> `no', for a random cipher. Fix any 64-bit plaintext and ciphertext,
> and let X be a random variable that counts the number of 56-bit DES keys
> that encrypt the plaintext block to the ciphertext block. We have
> Pr[X=0] = (1 - 2^{-64})^{2^{56}}
> ~ exp{-1/256} ~ 1 - 1/256, and
> Pr[X=1] = 2^{56} * 2^{-64} * (1 - 2^{-64})^{2^{56} - 1}
> ~ exp{-1/256} / 256 ~ 1/256 - 1/65536.
> Consequently, Pr[X>1] = 1 - Pr[X=0] - Pr[X=1] ~ 1/65536.
> So, for any fixed plaintext/ciphertext pair, we have about a 1/2^16 chance
> that the DES key fails to be uniquely determined. This is quite low.
> But there are 2^{128} different plaintext/ciphertext pairs in all.
How about this argument:
Encryption by DES on the plaintext elements
0 1 2 3 ... 2^64-2 2^64-1 can be seen as a permutation on
those elements. Given one such permutation the size of the largest
set of encryptions with exactly no element on the same place is
2^64 - 1 (i.e. all rotations minus the original one). However,
having a 56-bit key, DES can at most choose 2^56 of these 2^64-1
permutations. The number of ways in which this can be done is:
(2^64-1)!
=================
2^56!*(2^64-2^56)!
The total number of permutations to choose from is 2^64!-1 so the chance
that DES (if it were random) would define the set of
permutations with no element in the same place is:
(2^64-1)!
==========================
2^56!*(2^64-2^56)!*(2^64!-1)
Which is approximately
1
======================
2^56!*(2^64-2^56)!*2^64
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (Atcherem)
Subject: question
Date: 18 Dec 1999 14:05:36 GMT
I'd like to know whether there exist ciphers where the length of the ciphertext
is LARGER then the length of plaintext (with factor 2 or 3, for instance)?
Serguei Tcherem.
University of Orleans
France
------------------------------
From: [EMAIL PROTECTED] (Amily Nerko)
Subject: Re: Analogue encryption
Date: Sat, 18 Dec 1999 14:08:50 GMT
"Gary" <[EMAIL PROTECTED]> wrote:
>In old B&W films telephone conversations were scrambled.
>Since digital modems weren't around then what did they do?
>Did they overlay waveforms over the voice?
>How did they synchronise? Did they have a tracking control on the phone?
>If a pseudo one time pad is used to generate a wave form that overlays a
>voice could this ever be as percievably secure as digital encryption?
>Gary :)
One old fashioned way to scramble speech is to "invert" it. If you've ever
used a single sideband radio receiver, such as a shortwave radio, amateur
transceiver, or SSB CB radio, you might know what it sounds like to tune in
a signal on lower sideband that is being transmitted on upper sideband (or
vice-versa). The effect is to translate each frequency component, N, to a
frequency of roughly (3000 - N) hertz. It sounds very odd and is fairly
unintelligible. Circuitry that performs this inversion can be used to
scramble phone conversations. Doing the inversion again restores the sound
to normal. It's sort of like ROT13 for speech and is about as secure.
--
"Amily Nerko" is actually [EMAIL PROTECTED] (1286 504397).
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: First step in finding primes
Date: Sat, 18 Dec 1999 15:03:49 +0100
Scott Fluhrer wrote:
> In addition, gcd(n, x) for small x can be computed *quite* rapidly.
> [Ask me for details if you don't know how].
My initial idea would be to generate a table of reciprocal values, and
then use these iteratively to generate the remainder.
It seems like you could do this at a rate of 32 or 64 bits/iteration, so
it would take maybe 300 cycles for a 2048-bit number.
If you have some more clever way, I'd love to learn about it!
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (Amily Nerko)
Subject: Re: 8192bit Encrypt >> Snake Oil, another one.
Date: Sat, 18 Dec 1999 14:18:13 GMT
[EMAIL PROTECTED] and others wrote
(about http://www.glen-bridgland.co.uk/Project/Crypt.htm ):
>Snake Oil, another one.
Hey come on you guys! We've seen a lot worse here. Now that he's run the
gauntlet, give him a chance to read the FAQ and learn more about
cryptography. There's a chance that he'll eventually come up with something
really valuable, so long as he can accept the fact that he'll have to
publish his source code and the program is not going to make him any money.
--
"Amily Nerko" is actually [EMAIL PROTECTED] (1286 504397).
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: "Olaf Dokter" <[EMAIL PROTECTED]>
Crossposted-To: alt.security
Subject: Re: RSA, how to calculate big numbers
Date: Sat, 18 Dec 1999 12:05:26 +0100
try it with java !
in java, you have the java.math.biginteger package which allows you to do
calculations with very large numbers ( like you have to do it) !
i calculated primes for the dsa with a length of 1024 bit with these
packages and it worked perfectly. the package supports you also with
functions like modulo, modulo power, a primetester according to the
nist-specifications and so on.
ciao, olaf
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Sat, 18 Dec 1999 14:45:01 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
: In <[EMAIL PROTECTED]> Tim Tyler <[EMAIL PROTECTED]> writes:
:>The comparison with pseudo-random number generators still seems
:>appropriate to me:
:>PRNG output has a lower entropy than a real random stream. The entropy of
:>the stream is only that of the original seed.
:>Similarly, hashes based on pseudo-random functions - rather than genuinely
:>random ones - will not do as good a job of concentrating the entropy as
:>they could do.
:>The original data is patterned (that's why we're using a hash in the
:>first place - to introduce more randomness).
: No, it is NOT why we use the hash. We use the hash to take say 150 bits
: of input which however only have 128 bits of entropy to produce an
: output of 128 bits which still has that same 128 bits of entropy.
No hash is good enough to produce 128 bits of entropy from a biased
source. I know of no practical way of getting 128 bits each with
entropy 1.
: The hash function is NOT assumed to introduce any randomness whatsoever.
You're taking what I wrote too literally. The resulting bits *are* more
random than the bits in the input stream. They have greater entropy. I'm
not trying to say the hash is somehow adding information that's not in
the input.
: A has is a many to one function. The question is whether the many to one
: mapping has any correlation with the regularities in the data.
Yes, this was the issue I was trying to raise originally, IIRC.
: For example one could imagine a hash which took 256 bits of input with 128
: bits of entropy and produced that same output for all of th epossible
: inputs. This would be perfect correlation between the input and the
: hash. However the probability that say MD5 is correlated with the biases
: in the output of a zener diode is negligible.
I doubt it. A zenner diode undoubtedly has a large number of types of
regularity. MD5 also has many types of regularity. Until I see some
demonstration that the regularities do not interact, I will remain
sceptical.
:>The hash itself is also patterened (as it's made up of a relatively small
:>function, rather than a huge random LUT). If the types of pattern happen
:>to be anything other than completely orthogonal, that might cause
:>problems for the ability of the hash to concentrate the entropy from the
:>message.
: Yes, but are those "patterns" of any relation to the "patterns" in the
: data being distilled? (Ie, is the hash a valid theory for the biases in
: the noise source.)
It doesn't have to be very much of a "valid theory" for it to fail to do
as good a job as a huge genuinely random LUT would.
Note also, that /even/ a hash composed of a huge genuinely random LUT will
not /necessarily/ produce 128 bits of entropy in a 128 bit hash - /even/
if you feed it 2 million bits of entropy in 3 million bits. There's
simply no known way to remove *all* bias from a physically generated
random stream using /any/ sort of hash.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
All that glitters has a high refractive index.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: More idiot "security problems"
Date: 18 Dec 1999 14:54:53 GMT
[EMAIL PROTECTED] writes:
>The listed case was the password is in the program (like storing
>your mail login password so you don't have to type it in every time),
>trivial work to go in the program and find how it encrypts your
>password for storage. Then you just write another program to decrypt
>the encrypted password, it might as well be plain text if you can get
>a copy of the stored encrypted password.
Thanks. I guess I misunderstood Green. I thought he
meant that any program that had some sort of
password-checking mechanism was insecure since
an entered password would be compared to stored encryption
or hash of that password.
(Some encryption programs, not all, that run such
a password check are insecure.)
If all he meant was storing a password so you don't have to type it
in every time, then it's insecure. You can, as you say, go into
the program and discover the encryption method, or, under Windows,
just run a program to read "behind" the asterisks.
You mention it might as well be plain text -- sometimes it is!
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: First Bijective Arithmetic Compression
Date: Sat, 18 Dec 1999 15:45:24 GMT
I know readers of sci.crypt know this is my favorite posting spot.
But I see that there is more good compression on the way. Many are
not of a high IQ to see the advatanges of good compression that does
not add information to a file. While Matt appears to have solved the
problem for Arithmetic compression. It can easily be solved with
many other schemes. I have solved it with RLE encoders and am
working on LZ schems. For those who want to compress stuff before
they encrypt there are at least 2 different compressors out there so
that you don't have to weaken the code my using the kind inferior
compression that PGP uses or that you would get from the BS
crypto Gods. The choice is yours.
There appears to be another compression scheme based on the principle
one should not add information to compression. Mine is the first that I know
about. Matt T. who posts out here has a version of what he is calling
bijective arithmetic compression. It appears to have the property that
decompress(compress(X))=X and compress(decompress(X))=X for any
real file X. so those that do compression have another choice. I assume
that many others will follow. You may wish to check with him for further
info.
I just want others to know I did some very preliminary tests and it
appears to work as advertised. But I do wish if any one finds a file
that fails. Less than a megabyte in size to meet the above two tests
in either his code or my version h2com.exe to let me know.
So people who use compression and emcryption know have a choice.
I would suggest any body interested in writting better compression
programs to look at my code and his. They are a different beast than
what you will find in published lterature. They are far superior if one
is to use crypto since they do not add information into a file as compression
occurs. This is ultimitely what all good compression should strive for
anyway.
Mabe the next european breed version of PGP could have a compression
that does not aid the NSA in breaking the code as the current versions of
PGP have. Though I am sure bad compression is only one of many PGP
weaknesses.
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: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: question
Reply-To: [EMAIL PROTECTED]
Date: Sat, 18 Dec 1999 14:55:29 GMT
Atcherem <[EMAIL PROTECTED]> wrote:
: I'd like to know whether there exist ciphers where the length of the
: ciphertext is LARGER then the length of plaintext (with factor 2 or
: 3, for instance)?
Yes, there are.
Consider the case of sending two messages, one containing the message
encrypted with an OTP, and the other containing the key to the OTP,
(both of which are encrypted by conventional means).
It's hard to decypher the message containing the random data using
cryptanalytic techniques - since the plaintext has pretty flat frequency
distrubution. You have to work from the fact that the other message has
the same data EORed with a message. However this message is encrypted
under a different key - perhaps even using a different cypher. To add
security, add more multiple messages and more OTP stages.
This system gets mentioned in textbooks.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
All's well that ends.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: MY WEB PAGE
Date: Sat, 18 Dec 1999 16:45:21 GMT
I think my site was the first to really look at how compression
should be done if one is going to encrypt the data immediately
afterwards. Most people have no idea why that is a good thing.
One can in my humble opinion thank the NSA and the phony
crypto gods who help spread disinformation. But the fact remains
that if you don't want to have your compression add information
to a file so that the NSA can find an easier break basied on
cipher text only. One needs to do a compression that does
the following for any file X then Compress(Decompress(X))=X
and Decompress(Compress(X))=X for any file X.
I have upated my website to contain pointers to the sites
of people who seem to understand what compression and
encryption is. I know my site layout sucks so here is the
relavent page with the links
http://members.xoom.com/ecil/compres1.htm
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: "Gary" <[EMAIL PROTECTED]>
Subject: Re: First Bijective Arithmetic Compression
Date: Sat, 18 Dec 1999 16:00:03 -0000
Compression and encryption are seperate subjects and mixing the 2 just
creates a headache when analysing the security of such a scheme.
For instance I noticed in your original decompression scheme rules were
introduced to get around illegal decompression.
Do you randomly introduce anamolies during compression to set off these
rules when decompressing? If you don't an analyst would home in on the non
rule breaking decompressions.
Also mixing the 2 affects the efficient implementation and development of a
good compressor.
Don't say you can still use another efficient compressor before hand as your
compressor then just becomes a dubious all or nothing transform.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply to 2 of the 3 patents. Why not for
Date: Sat, 18 Dec 1999 16:49:49 GMT
[EMAIL PROTECTED] wrote:
> The 3 most known patents in the encryption area are :
>
> Name Number Filed Expires
> ----------------------------------------------------------------
> Diffie-Hellman 4,200,770 Sept. 6, 1977 Sept. 6, 1997
> Hellman-Merkle 4,218,582 Oct. 6, 1977 Oct. 6, 1997
> RSA 4,405,829 Dec. 14, 1977 Sept. 20, 2000
>
> The 20 years periods did apply to 2 of the 3 patents.
> Why it is not applicable to the last one ?
> --
> Thanks, Richard
When the rule changed in 1995, it said that existing patents would get
protection 17 years after they were granted or 20 years after they were
filed, whichever was longer. So you need to find out the grant date for
each of these to see the difference.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Analogue encryption
Date: Sat, 18 Dec 1999 16:47:32 -0000
Isn't this insecure as the inverse transform can be found by guessing that
alot of the voice will have silence?
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply to 2 of the 3 patents. Why not for
Date: Sat, 18 Dec 1999 12:03:53 -0500
Thanks,
it does make sense.
--
Thanks, Richard
=========================================================
Kent Briggs wrote:
> When the rule changed in 1995, it said that existing patents would get
> protection 17 years after they were granted or 20 years after they were
> filed, whichever was longer. So you need to find out the grant date for
> each of these to see the difference.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: question
Date: Sat, 18 Dec 1999 17:01:50 -0000
Chaff and winnowing proposed by Rivest is one example.
In fact there are also alot of relatively new public key systems that have
expansion.
------------------------------
** 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
******************************
