Cryptography-Digest Digest #567, Volume #10 Sun, 14 Nov 99 20:13:02 EST
Contents:
Re: Codebook examples on Web?
Re: Patent on general public-key concept? ("Roger Schlafly")
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! ([EMAIL PROTECTED])
Another random number generator... (CoyoteRed)
EncryptedChat V2 Dead ? ([EMAIL PROTECTED])
Re: Codebook examples on Web? (Quisquater)
Re: Proposal: Inexpensive Method of "True Random Data" Generation
([EMAIL PROTECTED])
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (JPeschel)
Re: Another random number generator... (Scott Nelson)
Re: Codebook examples on Web? (RREYNARD)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Codebook examples on Web?
Date: 14 Nov 99 20:43:14 GMT
HJS ([EMAIL PROTECTED]) wrote:
: On 14 Nov 1999 04:54:52 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
: >Are there any examples of famous codebooks on the net? I want to see how the
: >Gray code and other historical diplomatic codebooks were constructed.
: There's a little material on commercial/shipping/banking codes, but I've
: been unable to turn up anything else.
: Please post here if you find anything.
One of the few places where some pages from military code books did turn
up was, of course, in David Kahn's book, The Codebreakers. Since it seems
to be little known, I'll note that in the July 1966 issue of Scientific
American, his article contained a _different_ part of Cypher SA from the
one that appeared in the book.
John Savard
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Patent on general public-key concept?
Date: Sun, 14 Nov 1999 12:04:13 -0800
Charles Blair <[EMAIL PROTECTED]> wrote in message
news:80me4b$8ic$[EMAIL PROTECTED]...
> At one time, I was hearing a lot about a patent (in some
> cases attributed to ``Public Key Partners'') that claimed the
> idea of a public-key system, regardless of the specific way
> in which it was implemented.
>
> Was there ever such a patent? Did it expire or was it
> disqualified in some way?
There were 2 such patents awarded to Hellman, Diffie, and
Merkle at Stanford. They are now expired. I had a lawsuit over
them. You can find lawsuit info at:
http://bbs.cruzio.com/~schlafly/pkp/pkp.htm
The patents were primarily used to stifle competition to RSA
Data Security Inc., which was a partner in Public Key
Partners. Things got nasty when it turned out that Jim
Bidzos and RSADSI was cheating its partner and Stanford
out of royalties on the Stanford patents.
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 14 Nov 99 20:50:36 GMT
Trevor Jackson, III ([EMAIL PROTECTED]) wrote:
: This confusion exists because within your definition of randomness as
:incompressibility you
: are using the term randomness with a different meaning, specifically, that of being
:selected
: or generated unpredictably.
I should join in, since in another branch of this thread, I made a similar
suggestion.
Of course, randomness means what you say: generated unpredictably.
However, there is a general intuition that an incompressible sequence is
random-looking. (Assuming it's being compared to something random with a
uniform distribution, of course.)
And that intuition has some validity.
An incompressible sequence can be safely used as the key for a
one-time-pad...because if it is incompressible, that means that it can't
be "easily guessed". Actual random means of generation are simply used to
ensure incompressibility...because a sequence can be compressible without
that being easy to determine.
14159 26535 89793... compresses to "the decimal part of pi", but any
sequence of numbers can compress to "the contents of the one-time-pad that
I secretly photographed"...
There _is_ a sense in which true incompressibility means "as good as
random", since it does mean haphazard, not generated by a simple rule.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: Sun, 14 Nov 1999 21:19:19 GMT
>
> He has, however, found a pretty good attack, one that I think
> can be developed so that is requires only one ciphertext. When
> he does I hope he is willing to share it.
>
> Joe
Yes, but because it's time consuming, i prefer only prove that the
softs are insecure. Why create a crack soft for encryptor 4.0 if
encryptor 4.0 is dead ?
Regards,
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Another random number generator...
Date: Sun, 14 Nov 1999 21:21:35 GMT
Reply-To: this news group unless otherwise instructed!
I've noticed a few postings about generating random numbers. Some
require specialized equipment, TVs, video encoders, etc., other's rely
on inconsistencies of the operating system's in relation to the
hardware on which it's running, while others rely on active input from
a user (mouse movement, key presses, etc.)
Forgive me if this has already been discussed, but I believe this
should be of crypto-quality of randomness...
I had an idea that was sparked by the discussion of the TV picture
concept, but, instead of video, use audio.
The vast majority of modern desktops have sound cards with "microphone
in." Nowadays, most even come with a microphone. While this is not a
device designed for cryptography, we should be able to take advantage
of it. And even if the machine didn't come with a sound card it
should trivial to add one.
Now, sound is fairly structured. If we know two samples, we can just
use a vector to guess the next sample. So we can't just use raw PCM
as our random number. We need to take the predictability out.
First, we need raw 16 bit, 44khz PCM and confirm that the sound card
is not digitally altering the signal.
(We will use MONO so we don't induce any similar information into the
stream. Or if we do, we make sure that the signal is truly stereo and
we ask the user to start sampling each signal in turn to get a
variable offset between the signals.)
We need to test that the first 5 bits of a sample are changing. This
shouldn't be a problem seeing that we are only using the first 32
steps of 65535, quiet ambient room noise should suffice.
(Alternatively, we could use a completely blank audio cassette in a
cheap player with the volume turned up and sample the "tape hiss.")
We sample and capture the LSB of a sample, this we add to our random
number. The next 4 bits we will invert ( bit two of our sample will
be our MSB and bit five will be our LSB) and use as the number of
samples (plus one) we skip to go to our next sample. We will skip 1
to 16 samples.
So, as an example we have a sample that is
1001101001101110
The bit that we capture and put in our random number is "0".
The next four bits 0111 (seven) we will invert (or reverse if you
want) to give us 1110 or fourteen. We skip the next fourteen samples.
We invert to get our skipping more spread out if we have a low signal
strength.
We continue until we have the desired number of bits.
By my calculation, we capture at least 366 bytes a second and we
should average about 732 bytes a second, double that if using stereo.
(We may be able to increase the speed by capturing the first 2, 3, or
4 bits if we have enough signal strength, but beyond that we may be
tipping our hand to a analyst.)
By pulling bits out of a sample and then skipping samples, we should
completely eliminate predictability if we assume the following:
- We have a sound source to capture.
- We don't capture a pure tone, tones, or it's harmonics.
- The gain on the analog side of the A-D converter is turned up enough
to get a good signal.
All of the above we should be able to test for and give a warning if
something is amiss.
Advantages, as I see it.
- The attacker has no idea of where on the slope he is or which
direction it is going.
- If we induce the slightest amount of noise into the signal,
predictability will be thrown off so much, so fast, that it would be
nearly impossible to follow.
- We don't need exotic sources or hardware. Any room noise should
suffice including talking, background music, etc. How loud the noise
is really doesn't matter as long as it's loud enough to change the
first few bits of a sample.
- Even if someone was bugging our room (or use the same recording),
they would have to start sampling at the exact 0.0000227 second to get
the same random number. Because if they start /anywhere/ else on the
slope of the signal than we did, they would get a different number. (a
different LSB and different skip-ahead number and thus sampling a
different sample than we are on the very next sample.) Then, their
sampling rate would have to match our's exactly.
- Doesn't have an inherent periodic rate, therefore there is nothing
to which an attacker could sync his signal.
- With monitoring ambient room noise, it's something that can go on in
the background. We could capture /huge/ amounts over time while doing
other things.
- It doesn't rely on any complex math that can be reversed, user input
to be waited for, or inconsistencies in hardware that may not be
there.
Disadvantages, as I see it.
- Slow. If we need a lot of random numbers in a hurry we can't use
this. (But, we could have been sampling and have them ready to go.)
- The quality of randomness is dependant on the sound card and it's
setup by the user.
So, there you go. Criticisms welcome. (on the theory, that is)
BTW: How would the above compare, crypto-quality randomness wise, to
simply XORing all the bits together of a sample and using the result
as a single bit and not do any skipping? I know you could capture
bits faster.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED]
Subject: EncryptedChat V2 Dead ?
Date: Sun, 14 Nov 1999 21:31:31 GMT
Neuralabyss Software claim to use RSA encryption ( with a logo in the
soft ) in his internet chat soft : Encrypted Chat V2
can be found here :
http://www.users.bigpond.com/annex31/Downloads/index.html
I've installed a LAN sniffer on my LAN and i found two packets to
exchange the key ( it seem to be prime numbers ):
COMPUTER 1 send to computer 2, one packet with this inside :
110358302195623472832716817864879473 //
1679255177848752162851143387478689891
The // are in the packet. ( two numbers in each packet )
Could someone tell me if they are prime ?
COMPUTER 2 send to computer 1, one packet with this inside :
1935778852695641963616421814534998273 ::
3294171656609397704278174186334516191
The :: are in the packet
Are these two numbers prime ?
If i disconnect and reconnect the numbers will be always different
After this packet exchange the data are encrypted with an unknown
algorithm
The problem that each prime number seem to have ONLY 122 bits !!!
If it's correct and if RSA is used, then EncryptedChat V2 is dead !!
Neuralabyss Software has others crypto soft on his web site : SecurePad
and dozeCrypt, but i think if EncryptedChat has a backdoor, the other
softs have backdoors too !
Thank you the National Security Agency :)
November 14, 1999
Alexander PUKALL
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: Codebook examples on Web?
Date: Sun, 14 Nov 1999 23:27:46 +0100
Jim, you're right (I said a beginning ...) but
I didn't find more (and I'm interested). By the way
why nobody is using a good scanner?
Jean-Jacques,
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sun, 14 Nov 1999 22:16:15 GMT
Coen Visser
> [EMAIL PROTECTED] wrote:
> > Coen Visser wrote:
> >
> > > It is a definition: call a string random when
> > > it is incompressible.
> > > I am talking about (all) finite strings, using
> > > a fixed Universal Turing
> > > Machine, compressibility defined + O(1).
> >
> > In another strand of the thread I argue that this
> > definition doesn't make sense. We cannot use a
> > notion of compressibility that ignores constant
> > differences because for "a string", the numbers
> > we want to compare _are_ constants.
>
> I was not ignoring the constant. That is what the
> O(1) is for. Maybe I don't understand your objections,
> if so please explain.
I'm not saying you forgot the constant; I'm
saying that the + O(1) means that in this
description of complexity, addative constants
are not significant.
> Maybe you did not understand
> my explanation, if so please say so.
Let me ask: what do you mean by a fixed universal
Turing machine? Do you mean you have a specific
machine in mind, and just left out its desciption
to make the definition shorter? Or do you mean,
as in the Kolmogorov complexity notion of
compressibility, that the machine is arbitrary but
fixed?
If you have a particular machine in mind, you don't
need the "+ O(1)". A shortest representation of
a string is also a string, and comparison of their
lengths defines whether the string is compressible.
But the definition is incomplete without naming
the machine, so it doesn't yet define whether a
string is compressible.
If you mean arbitrary but fixed, then the + O(1)
term does need to be there, and it means "plus
some constant". The definition fails to define
whether a particular string is compressible,
since for any two lengths x and y, all of the
following are true:
x > y + O(1)
x = y + O(1)
x < y + O(1)
We cannont use a description in which additive
constants are not significant to describe things
that are constants.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sun, 14 Nov 1999 15:56:19 -0500
Reply-To: [EMAIL PROTECTED]
Coen Visser wrote:
>
> "Trevor Jackson, III" wrote:
>
> > Coen Visser wrote:
>
> > > All I have claimed in my very first posting in this thread that it is
> > > usefull to define random strings that way. It is a definition with a
> > > solid mathematical foundation that has many uses. I think it is the
> > > responsibility of a writer to make clear what (s)he means when writing
> > > "random string".
>
> > And I have pointed out two instances of your use of the phrase "random string"
>wherein
> > the meaning was mangled. This is the opposite of useful.
>
> Hmm, I thought I only defended the definition of the
> randomness of a string and did not make use of the
> definition of random generator in the same context. I
> did refer to the (statistical) link between strings generated by
> random processes and incompressible random strings. If this
> was unclear than that was my fault. However Patrick Juola,
> who supports your point of view I think, did write a reply
> (which I'm quoting in part below) on my posting showing knowledge
> of what I was talking about. So I assumed what I wrote was
> not totally unclear.
>
> > You keep asserting, without substantiation, that your definition is related to the
> > classic definition. I keep pointing out that your assertion is false. When will
>you
>
> Ok, here is an excerpt from what I wrote earlier:
> 1 It happened to be proved that a string that passes all statistical
> 2 tests within the required confidence level is incompressible
> 3 (and random because it passed the tests).
> 4 So our definitions start to look dangerously equivalent.
>
> Now to prove that a random generator is random you need to
> put its output through all effective statistical tests, so that
> is the connection. I must admit that I was a bit too eager to
> convince my oponents with 4.
>
> Patrick Juola pointed this out:
> 1 *HOWEVER*, the output of a random coin-flipper is not necessarily
> 2 random in the Kolmogorov-Chaitin sense
> 3 (it's random with probability one, but that's *NOT* equivalent,
> thanks).
> 4 Nor is it the case that a number random in the Kolmogorov-Chaitin
> sense
> 5 was generated by the output of an appropriately random process
> 6 (although, again, it's true with probability 1 in the infinite case).
> 7 Unfortunately, any finite approximation will yield a finite
> probability of
> 8 disagreement.... and even in the countably infinite case, there
> 9 are still an infinite number of potential counterexamples.
>
> What I failed to respond to (1,2,3) was that for even a relatively
> small number of finite coin flips the two definition converge
> extremely fast: If you are testing a random generator and it produces
> (consecutively) 10000 "0" bits wouldn't you reject it on the basis that
> it could be dangerously biased. Although the source of the bias may not
> be
> known.
No. You shouldn't reject strings because they "look" suspect.
The 10000 "0" bits strings may not be appropriate for
cryptographic purposes, but that has nothing to do with the
probability distibution of the generator.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: 14 Nov 1999 23:05:53 GMT
[EMAIL PROTECTED] writes:
>Yes, but because it's time consuming, i prefer only prove that the
>softs are insecure. Why create a crack soft for encryptor 4.0 if
>encryptor 4.0 is dead ?
Because Rocky and Bullwinkle want to be able to read all
of the Encryptor 4.0 files on Natasha's hard-drive even
if she used different keys for each file. They don't have
much time since she'll be back soon from lunch with Boris.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Another random number generator...
Reply-To: [EMAIL PROTECTED]
Date: Sun, 14 Nov 1999 23:03:59 GMT
On Sun, 14 Nov 1999, [EMAIL PROTECTED] (CoyoteRed) wrote:
>Forgive me if this has already been discussed, but I believe this
>should be of crypto-quality of randomness...
>
[use the input of a sound card]
Yes, it's been discussed. I don't see anything in the
FAQ on it, so I suppose I can forgive you for bringing
it up again.
>
>So, there you go. Criticisms welcome. (on the theory, that is)
>
First, never throw away the most significant bits of a sample.
Even if most of the entropy is carried the LSB,
there's no reason to throw away the rest.
Second, if there's no automatic gain on the sound card
(and these days, there usually isn't) then there's
actually more noise, not less, when sampling a signal.
Thus sampling a pure tone is probably better than sampling
silence, or room noise.
Finally, instead of using some new, unproven technique of
distilling entropy, it's probably better to use a secure
hash like MD5, or SHA1. Not only does it do a better job,
it means you don't need to figure out which bits have the
most entropy. Some '16' bit sound cards are actually
14 bit sound cards with interpolation (or even 0)
on the 2 least significant bits. You can of course
correct for any known defect in the sound card, but
with a secure hash, you don't have to. Just take the
whole sample, and hash it. i.e. rand = MD5(rand+sample)
This also has the advantage that it gets harder and
harder to predict the output the further you go.
>BTW: How would the above compare, crypto-quality randomness wise, to
>simply XORing all the bits together of a sample and using the result
>as a single bit and not do any skipping? I know you could capture
>bits faster.
Well, a secure hash is better than either, so in that
sense, they're about the same.
Without skipping, an enemy can start at any point and
determine (to some accuracy) all the samples from that
point on. But with skipping, it only takes few samples
to get in phase. There are only 17 possible places
you can be in, so the enemy can simply collect all
the samples and try each of the 17 possible combinations.
Worse, he might even be able to refine his sampling
based on how bad his results are. So the net effect is
that we have less security, and we get bits 8 times slower.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (RREYNARD)
Subject: Re: Codebook examples on Web?
Date: 14 Nov 1999 23:06:33 GMT
There is, of course the Zimmermann telegram decode. It reveals the actual
codebook substitutes and the German word equivalents. I have a .jpg of that
text and it is probably out on the web somewhere (search on Zimmermann, etc.).
Although it is far from a codebook, since it only reveals the particular
entries for the telegram text itself, it is illustrative of the homophonic
technique, showing multiple codegroups for the same German word.
I illustrate that in Chapter IV of my latest Secret Code Breaker book. There is
also a Codebook simulator (computer program) that accompanies the chapter that
uses a word list and a five digit additive to superencipher the codetext. The
simulator uses a 'spelling' algorithm to encode words not found on the word
list, but does not use homophones.
Also in Secret Code Breaker III, with Chapter II, which describes the some of
cryptographic techniques used in the American Revolutionary War, there is a
Dictionary Code simulator that creates coded messages using a 'dictionary.' It
also has a superencipherment capability, In the chapter there is a description
of the methodology used to 'break' a superenciphered Dictionary Code along with
some real coded messages from the Revolutionary War for the reader to 'break.'
Regards,
Robert Reynard
Author, Secret Code Breaker series of crypto books for young readers (8-16
yr.).
------------------------------
** 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
******************************
