Cryptography-Digest Digest #105, Volume #9 Fri, 19 Feb 99 02:13:04 EST
Contents:
Re: Telephone Encryption ([EMAIL PROTECTED])
Re: Telephone Encryption (Paul Rubin)
Re: Block ciphers vs Stream Ciphers ([EMAIL PROTECTED])
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Re: Bruce's Feb. "CRYPTO-GRAM" (JPeschel)
Re: Double-DES, DESX, and instinct
Re: Randomness of coin flips (Nicol So)
Re: True Randomness ("Trevor Jackson, III")
Re: Bruce's Feb. "CRYPTO-GRAM" (JPeschel)
Another algorithm with Hexits (wtshaw)
Re: Bruce's Feb. "CRYPTO-GRAM" (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Telephone Encryption
Date: Thu, 18 Feb 1999 20:05:48 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Rubin) wrote:
> Software (programs that use PC's with audio hardware to encrypt speech):
> Nautilus, http://www.lila.com/nautilus.html
> PGPFone (www.pgp.com)
> Speak Freely (url?).
> Others?
>
> I'm most familiar with Nautilus (I worked on it). It comes with
> source code and has speech coders down to 2400 bps (good for cellular
> phones). Also, it can work either with modems or over IP. I think
> the other two are IP-only and don't ship source.
PGPfone is modem-to-modem (over a regular analog line) *and* IP to IP.
PGPfone will work Mac-PGPfone to Windows-PGPfone. Nautilus is PC only.
But there is not public source code for PGPfone.
============
About 60 or 70 percent of NSA were smoking pot -- a lot of them while on
duty. It's very relaxing, particularly when you're bored with the
Russian or East German traffic that is coming through.
http://jya.com/nsa-40k.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Telephone Encryption
Date: Fri, 19 Feb 1999 01:54:38 GMT
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Thu, 18 Feb 1999 19:33:46 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>>If you're looking to buy high quality secure phones I probably can put
>>you in touch with a guy who has been making some very nice ones at
>>about $1000 each. Email me if you want this.
>
>My interest is only passing - I wanted to see where the state of the
>art was today.
These aren't real high tech devices by today's standards.
They could be a lot less expensive if there was enough volume.
>>If you're looking for something cheap for occasional use, try one
>>of the software programs.
>
>I suppose you could build a single board computer from industrial
>grade parts and implement the software on it in a dedicated fashion.
This is basically what the $1000 devices mentioned above are.
>Put it in a very small brief case and it would look very cool,
>especially with some randomly blinking lights and maybe a small
>display panel spitting out messages like "secure uplink engaged now"
>or some such techno babel.
The box looks like an a small external modem or 2-way radio, with an
LCD display. It says "going secure" during the modem handshake and
key exchange phase, if I remember correctly. After that it shows a
checksum of the key agreement so you can authenticate by voice that
there's no MITM attack taking place.
>It sure as hell would impress the ladies, eh. Used to be you could
>attract turned-on women with just a Captain Midnight Decoder Ring, but
>women are getting much more demanding these days.
The boxes are extremely well built and VERY sexy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Block ciphers vs Stream Ciphers
Date: Fri, 19 Feb 1999 02:20:30 GMT
<[EMAIL PROTECTED]> wrote:
> Whatever anybody could do with a stream cipher can as well be done with a
> block cipher in OFB or CFB mode.
... if your block cipher has suitable cycle properties when used with
these "modes".
> But how could I implement CBC mode in a stream cipher?
Why do you want to? The purpose of CBC is to cover up patterns in the
plaintext [foiling code-book collection and/or traffic analysis] -- patterns
which will be covered up just fine with a stream cipher worthy of the name.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Fri, 19 Feb 1999 03:12:37 GMT
In article <[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> > Bryan Olson wrote:
>
> > > More or less. Compression doesn't help against known plaintext
> >
> > Yes, and it does not help even against ciphertext-only attack -- see
> > http://www.mcg.org.br/unicity.htm, with a Huffman coding example.
>
> Of course you know I've seen it. In your post of 16 Jan 1999 you asked
> if I could refute a proof you use in that document. On Jan 19, I
> responded:
>
> | Fair enough. The first major error is the incorrect assertion
> | of how Shannon defined unicity distance. Shannon in fact defines
> | it as "the number of intercepted letters" (page 692) such that the
> | equivocation of the key becomes nearly zero. Ed's text assumes
> | the analyst has one or two 8-byte blocks that decrypt into
> | 8-byte English strings. He the claims a unicity distance less
> | than the amount of intercepted text, which is wrong since the
> | unicity distance is, by definition, the amount of intercepted text.
>
> I never saw a reply,
;-) Of course you saw my reply ...as it was done here ... and it was 100%
negative to the same opinions of yours on several counts, so that is why I do
not believe I have to reply yet once more now.....but, please see the
archives.
You can even see that your text above is totally incoherent -- such as when
you write your "definition":
|"unicity distance is, by definition, the amount of intercepted text."
which leads nowhere since you forgot to include "least" before "amount" and
"that can be uniquely deciphered" after "text". But given the style and
content of your writings these mistakes do not make a difference at all when
one tries to appraise what you wrote -- so, don't bother.
>and the "unicity.htm" document still asserts:
which is correct,
>
> : Shannon [Sha49] defined "unicity distance" (hereafter, "n") as the
> : least amount of plaintext which can be uniquely deciphered from the
> : corresponding ciphertext -- given unbounded resources by the attacker.
>
> That's false,
No, but I am glad you disagree with me ;-)
>but you did add,
It was there all along, Bryan...
>
> : In few words, "unicity" is the least message length that can be
> : uniquely deciphered.
>
> Which is basically true, provided we understand that remaining key
> entropy must be nearly zero for a solution to qualify as "uniquely
> deciphered"
;-) change "nearly" for "" and you will at least have said an obvious truth --
instead of an obvious falsity as it stands.
> Unfortunately, the definition you actually use is the
> false one.
>
Given your mistakes above, I am again very glad you disagree! I would be
worried otherwise, judging from your post history.
> Both of us are referring to:
> [Shannon, Claude E. "Communication Theory of Secrecy Systems". /Bell
> Systems Technical Journal/, vol. 28, pp. 656-715, 1949.]
I am, at least.
>
> There are, incidentally, a number of other errors.
Thanks again. I am glad you do not agree -- see below.
> The unicity distance
> of English without any key is zero. Proof: see Shannon's proof in the
> same paper that the equivocation of a cryptogram is never greater than
> the equivocation of the key. Thus the point at which the equivocation
> becomes zero is at zero letters.
>
If I were to believe your "proof", then a unicity of zero for English means
that you need to receive zero English characters in order to uniquely decide
what I have written... surely, you can save a lot of money $$$$ on phone
bills and Internet access if you reaally apply that "discovery" to your own
profit!
Go 100% for it and pls just send telephatic messages also, from now on...
Now, if you really want to *understand* this -- please try again to answer the
same question you "answered" above: if plain English is your message without
any encipherment, what is the key entropy?
--> Hint 1: Shannon already answered this in the case of Telegramm messages.
--> Hint 2: The answer is NOT zero.
> We cannot distinguish the correct DES key based on recognizing the
> first three letters of a trial decryption.
Well, I must finally agree with you! And, please note that I never said
otherwise -- but since I sense a note of disapproval from your phrase
(sigh!!), please note that you are perhaps confusing "three-letter
frequencies" in my paper with "three letters" in your comment, no?
>For a randomly chosen
> ciphertext block, we should be able to find about four billion DES
> keys that decrypt our ciphertext block to a candidate plaintext
> beginning with the ASCII characters "The".
Four billion DES keys ... hmmmm... can you please tell me how you arrived at
this number in that exact situation you describe? Can you provide your full
assumptions and calculations, and error bars for the "about" you used?
Or, is this going to be another "contrived example"?
Finally, please tell me what your "example" above has to do with three-letter
frequencies -- or, you assume to get three-letter frequency measurements from
those three letters?
>
> If the plaintext language allowed us to distinguish the correct key
> with just one block of DES ciphertext (as does known plaintext), this
> does not speed up exhaustive attack significantly over, say, random
> ASCII. The unicity distance of random ASCII under DES is about seven
> blocks,
:-) if you say so...but that is not correct, right? BTW, there are at least
TWO basic things wrong in your last phrase above.
I will await for your calculations ... four billion DES keys you say ...and
its significance to three-letter frequency analysis. I will also wait for the
TWO corrections (at least) in your last phrase above.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Bruce's Feb. "CRYPTO-GRAM"
Date: 19 Feb 1999 04:50:13 GMT
> [EMAIL PROTECTED] (John Savard) writes that:
>[EMAIL PROTECTED] (JPeschel) wrote, in part:
>>> [EMAIL PROTECTED] (John Savard) enigmatically writes:
>
>>>He names other names in that issue too, and those are names one is
>>>less likely to have heard before...
>
>>What point, if any, are you making?
>
>Nothing too terrible. Just that while naming the names of some
>companies producing cryptographic snake-oil, while it may indeed be
>quite helpful to some, isn't really revealing anything surprising.
>
>
My, John, for a layman, you seem awfully
smug about this.
Even some of the best, except for you,
of course, can be confused when trying to
discern snake-oil from strong crypto.
While some of the products mentioned in
the newsletter could be dismissed,
without inspection, as snake-oil by most
regulars of this newsgroup, one product,
UBE fooled a lot of people here and in
coderpunks. You, I believe, later even
offered advice on how to fix UBE, without
having looked at the thing, or having
read the relevant posts concerning the
product's problems.
Additionally, one sci.crypt regular maintains
a link to GenioUSA from the "Crypto
Products" page of his web site. Does he
believe the GenioUSA product is strong? I
suspect he does, as he is a "professional
cipher designer," and, so should have
the cryptanalytic skills to make an
assessment -- but GenioUSA's CrypEdit was
broken in InfoWorld a few yearsago.
Again, some of the best, except for you,
of course, can be confused when trying to
discern snake-oil from strong crypto.
Even worse, some people without your skills
will pay real money for products like
these. True, those people ought to read
the Snake-oil FAQ. Some of them, however,
need to have the truth of the FAQ demonstrated
for them.
I believe they all live in Missouri; I live
in South Dakota and haven't designed my own
unbreakable cipher, yet. Someone slap
some crypto-sense into me if I decide to.
-- Joe (another layman -- and a grouchy one, at
that...)
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Double-DES, DESX, and instinct
Date: 19 Feb 99 04:43:14 GMT
John Savard ([EMAIL PROTECTED]) wrote:
: However, it seems to me that this encryption method *does* gain
: resistance to a differential cryptanalysis attack...
Upon further reflection, while some resistance might be gained, it
wouldn't be that much; any "characteristic" wouldn't be much affected by a
simple XOR, even if it would change the blocks for which the
characteristic was manifested.
Of course, a better manipulation, like byte substitution, would do more.
But it doesn't seem I've found a simple example to prove a suspicion I've
had - that doing something extra in the middle, or at the ends, each have
their own values.
John Savard
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Randomness of coin flips
Date: Thu, 18 Feb 1999 23:53:45 -0500
Patrick Juola wrote:
>
> In article <[EMAIL PROTECTED]>,
> R. Knauer <[EMAIL PROTECTED]> wrote:
> >On Wed, 17 Feb 1999 20:06:05 -0500, Nicol So <[EMAIL PROTECTED]>
> >wrote:
> >
> >>...
> >
> >What do you mean by "don't seem to be the way it would be were
> >successive coin flips truly indenndent of one another"?
> >
> >If coin flips were truly independent of one another, what would you
> >expect to happen that is any different from what you observed?
>
> Well, *IF* -- and I'm cheerfully hypothesizing in blissful ignorance
> here -- *IF* Ms. So's coin flipping technique tends to put an even
> number of flips on the coin, then she will observe that the bigrams
> HH and/or TT tend to dominate over HT and TH. This means that
> she'll see longer than expected runs.
Patrick, the person you referred to is a "he", not a "she". :)
The way I flip coins, it *seems* that successive flips are equal with
greater than 50% probability, which would have been the case if the coin
flips were truly unbiased and independent. If successive coin flips are
positively correlated, the expected length of runs will be longer than
if the flips were independent.
Nicol
------------------------------
Date: Thu, 18 Feb 1999 23:57:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: True Randomness
R. Knauer wrote:
> There is something special about quantum processes, however - they are
> proveably indeterminant without further testing. Now all you have to
> do is couple such a quantum process to a generator that is capable of
> producing all possible finite strings in an equidistributed manner
> (like a uniform Bernoulli Process), and you have a TRNG.
>
Repeating this ad nauseum does not make it true. Quantum processes produce
output in the form of experimental results. If you can prove that (generated)
data "truly random", then I can use the same technique to prove data generated by
an RNG to be "truly random".
When you can show me the design notes, implementation log, and ECO revision
history for the universe, then I'll believe you can "prove" QM indeteminant.
And don't try to feed us crap about experimental proofs again. Instead reread my
first paragraph above and try to grasp the equivalence of the proof methodology.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Bruce's Feb. "CRYPTO-GRAM"
Date: 19 Feb 1999 05:58:38 GMT
[EMAIL PROTECTED] (wtshaw): writes:
> Perhaps he is trading
>on a well established reputation on purpose, maybe he just doesn't know
>better.
Perhaps, you are jealous, maybe you are just being silly -- does
anyone care? :{<)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Another algorithm with Hexits
Date: Thu, 18 Feb 1999 22:30:04 -0600
This one is a bit more complicated than the last.
7 or 14 characters in Base 100 are converted to 14 or 28 digits.
Each 14 digits is converted to 18 hexits which can be transposed by a key.
Each 6 hexits are converted to 4 base 15 characters using 6^6=46656, 15^4=50625.
Output allows the addition of random nulls from remaining 11 alphabetic
characters.
(I simplified the null key structure I used before, so I'll put it on the
list of updates for the earlier applications dealing with bases 13 to 22.)
The application is called Chainet 18/36, a town in the orient near 100 E
and 15N, actually in the same neighborhood I have found names before. It
could be a French name?
Default keys are as follows for Chainet 36:
Subs(Ch): abcdefghijklmno pqrstuvwxyz
Trans(Ch): abcdefghijklmnopqrstuvwxyz0123456789
It has some small common structure with Canadian that output in Base 36.
The next application planned also uses hexits, with base 100 input.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Bruce's Feb. "CRYPTO-GRAM"
Date: Thu, 18 Feb 1999 22:36:11 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> He names other names in that issue too, and those are names one is
> less likely to have heard before...
>
Speaking of names, he could use an original title for his rag instead of
one that has been used for many decades elsewhere. Perhaps he is trading
on a well established reputation on purpose, maybe he just doesn't know
better.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
** 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
******************************
