Cryptography-Digest Digest #496, Volume #9 Mon, 3 May 99 19:13:02 EDT
Contents:
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Terry Ritter)
Re: A challenge for you ! (Bob Silverman)
Re: SCOTT19U contest update (David Hamilton)
Re: Stream Ciphers and Quantum Computer Resistance (David Hamilton)
Re: Stream Ciphers and Quantum Computer Resistance (David Hamilton)
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Re: A challenge for you ! (John Savard)
Re: Factoring breakthrough? ("Christian K�nig")
Re: Random Number Generator announced by Intel (Daniel James)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: function help ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Mon, 03 May 1999 19:09:50 GMT
On Mon, 03 May 1999 17:31:14 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>If
>>users confine themselves to one piece of information per message (not
>>continually recounting the past), this would seem to be superior to
>>normal security compartmentalization.
>
>I would think that people using a cipher program in a normal civilian
>environment, while they wouldn't repeat the past, would supply lots of
>context and phrase their messages in a normal conversational style. Even in
>the military environment, where users are made aware of the need to limit
>context in enciphered messages, some leakage in this fashion is
>unavoidable.
We would surely prefer to have both strength and independent messages.
But since we cannot know strength, we must look to the consequences of
weakness: If we have a plethora of ciphers and use new ones for each
message, each cipher break exposes one message. If we just use one
cipher, a cipher break potentially exposes all messages over all time.
Breaking the cipher in a one-cipher system will expose future use of
that cipher. But breaking the current cipher in a many-cipher system
exposes only the current message and not future messages. Which do we
prefer?
>While I thought that Bryan Olson's objection was a legitimate one to the
>cipher system he _thought_ you were advancing, I had thought you would have
>already addressed this concern; essentially, multi-ciphering is what is
>needed, including encipherment by a cipher from a small group that users
>"know" to be secure as well as one from a larger pool of ciphers that
>*seem* secure, and make problems for the cryptanalyst by their profusion.
Huh? Yes, I guess.
>It may also be noted that your plan has one major benefit: Kerchoff's
>dictum notwithstanding, it is no longer true that the adversary knows what
>algorithms have been used on a particular message. Ensure that a known
>plaintext attack can only recover a session key, and not the key-generating
>or key-exchange keys, and another whole avenue is closed.
There *is* no known-plaintext or defined-plaintext attack on the
individual ciphers in a multi-cipher stack. That, in itself, should
be sufficient reason to make multi-ciphering standard practice.
"Session keys" are generally the wrong term, unless of course we send
multiple messages per session. But we want to avoid that. OF COURSE
we use a new random message key for every message sent.
But none of this prevents an attack on the structure of a cipher.
Since we cannot know when such an attack is applied, the only way we
can terminate it is to frequently change ciphers. The ideal is to
change ciphers with every message.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: A challenge for you !
Date: Mon, 03 May 1999 19:39:25 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > No one ever tries to crack programs without source code.
>
> It's the encryption that wants cracking, not necessarily the
> original program used to perform the encryption
And doing that is IMPOSSIBLE. Under any circumstances.
I can give plaintext that corresponds to this ciphertext.
The plaintext starts:
"Four score and seven years ago, our fathers...."
I can give the key that corresponds to this plaintext/ciphertext pair.
With ciphertext ONLY, it can decode to ANYTHING. And one can always give a
key which makes that decoding correct.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: SCOTT19U contest update
Date: Mon, 03 May 1999 20:21:08 GMT
=====BEGIN PGP SIGNED MESSAGE=====
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> I have just updated the next partial anwser to the contest.
>Even someone with a 386 if he uses his brains can be the first
>to crack the contest.
> The contest is not the kind that could be run with weak AES
>type of encryption systems.
Have you cracked any 'weak AES type encryption systems'? By the way, have you
cracked IDEA yet ... as you said you would?
>This is because they lack the all
>or nothing nature of the fine scott19u cipher.
99.9 recurring percent chance that your fine ciphers are all weaker than PGP
etc etc.
(snip)
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBNy31hMo1RmX6QSF5AQHvVgf/dzndvgRdpoOjAYK3qptgzL63B6DP61wN
xDUcnhDSoaZXrkB5zw2ZCH6aYmq9NzMKg0Mxcq7TC9Bu5NGWnNH4C1ZkehJdXWtU
35wTao8suaqzAeqpm8MqUWZIgvexsF6vi8QZ6OlPZTcsmqXa2bu7RaTyAXI1Gqi2
ySlE0/BG4V8ZWru97TlQ0VmmeSfFP+PbJnAx5LcOLEPDEMx7MmXLCJe/KDdb2Gbf
4JgyVYddlYJGYrtjMQJ/aa/9hHPxznVmGebAiFkZyg6/22+iHD4We/pgv9tQG/Lz
PRJ3vDfZAchhIAi4Qg+rGUhXD4ttj5HJOF9+ZftDWaUYHHA9cyXWlg==
=28AR
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Stream Ciphers and Quantum Computer Resistance
Date: Mon, 03 May 1999 20:20:56 GMT
=====BEGIN PGP SIGNED MESSAGE=====
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
(snip)
> If you read some of the literature from 1997 you can see that the
>advantage of quantum compters is that they can try more than one
>solution at a time. I word things the way I want to if you want to
>word differently do so. But only a fool would think that research
>since then has not gone BLACK and that the NSA does not already have
>very cool quatum compters that you may lack the mental ability to
>understand.
1) What does 'BLACK' mean in the above?
2) How powerful are the 'very cool quatum compters' that you claim the USA
NSA has? (eg How long to factor a 1024 bit asymmetric key? How long to brute
force a 128 bit symmetric key?)
(snip)
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBNy30wso1RmX6QSF5AQGILggAkoIqghm+HWHYzXwgXyy8dzfKjVSNeMb3
Nx50Cbu//XH2T0CsoZbOzzeFpBOp64Sz+lvqjA6cXhU+9eeeMp3HSZQ6JmQhC/MW
0hfz/56VnRZldUWh1JFTu8jmpKdFZONTHpGK0R/ICa6as8zQvxmrv1VVgBL27I+H
BVZrsk1WFKSLXSB8pOBoEkuXzcM7g4qWJgpNSxAZ5sKQNmssZgW6eEv3S70YI357
3Rk4RQwXHHS6idDNMKfASteb3/rSNlS73EwTeFAIMiTeVAcK2UbJFiLZ+OI1pHOg
RL5wFmA7+yVtRht5vGCXIFQ1mgroKLlcJIkE76nH61/acpG61FXPkg==
=zKaN
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Stream Ciphers and Quantum Computer Resistance
Date: Mon, 03 May 1999 20:21:01 GMT
=====BEGIN PGP SIGNED MESSAGE=====
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> David Crick <[EMAIL PROTECTED]> wrote:
>... most of his CRAP deleted
>
>>
>> "Besides a mathematical inclination, an exceptionally good mastery
>> of one's native tongue is the most vital asset of a competent
>> programmer."
>> -- Edsger W.Dijkstra
>
> I am glad you quoted the guy above. If he is what you think programming
>is all about. Then you are well on the road to the great dumbing
>down of America.
>
> I am the kind of guy Youron and Dijkstra brain washed programmers call
>when they actually want to cut throught the crap and get code to work.
>Yes they like you dislike me.
You (David A. Scott) seem to think programming is all about code - you are
wrong. Your poor native (English) language skills are another reason for your
likely poor programming ability. As Douglas Gwynn said 'The connection
between skill in one's native language and skill in a programming language
would be more through the common pathways in the mind that are involved in
concept symbolization, organization, relation, logic, and expression. These
are pretty much independent of linguistic details.'
I also see that you are still trying to deal with your own lack of success by
hitting out at others.
(snip)
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBNy31Lco1RmX6QSF5AQF7TggAoyh51Ro0ZqlEFgm7zY4w1qfw0DbiZpiH
VKmXnTcq3wBgdxwdlp/cZYppKS8g6GlR2xMSQtcH0BRVPI1mju9c7sjf8GfI+2U1
bg0W3EVWJSOBy7Fe7IFE/gcsIqqSLbjajeC5hIw/ioYjQPCHDW8EH5XZx/Yn+a6D
fr6vfPdW6rmT9Fkeu26E8jmVjT8bN6o4MshR2hoghGUcFixm9K34EqvTn93FbCp7
Qdc4obTgoFvI4venzp/0EeILPRtvTRdA59B1E6FdzovbJaMlFoU128jjBebyOCvo
2Sgdr4aMN5OD+HL7VhkeWaK17E/F6lYyt1eDQj8zcvwlACcttHqpEw==
=FX7u
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 26 Apr 1999 19:04:43 GMT
"R. Knauer" wrote:
> On Mon, 26 Apr 1999 05:52:11 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >No, what the document says (thanks for posting the URL) is that
> >for Level 3 or 4 security, this is one of a handful of tests that
> >will put the system into the "error state" (preventing its use
> >until reset) whenever one of the tests detects a pattern whose
> >a priori probability is below some tiny threshold (something
> >like 1 in 1,000,000).
> Once again you are falling into the trap Feller warned us about,
> namely attempting to infer the ensemble average from the time average.
No, the FIPS-140 tests don't care about the "ensemble average";
they are checking just the *one* actual instance of the system.
Note that they are not -- repeat, *not* -- *validation tests*
for the algorithm used in the system, but rather are *operational
checks* on a particular piece of equipment (identified by its own
unique serial number).
5 For every sequence of 20,000 bits that fails the Monobit Test, there
> is a complementary sequence in the ensemble that offsets it, which
> means that the TRNG is performing to specification.
Now you seem to be using "ensemble" to mean average behavior
over time, the very thing you were objecting to. An "ensemble"
is a (hypothetical) collection of identical instances of the
system having the same relevant macro parameters.
If the test fails too often on a *particular* device, odds are
that that device is malfunctioning, independently of what any
other similar devices might be doing.
> I recognize the need for alarms, but I do not think the Monobit Test
> as presented is the proper way to go about it. That is not to say
> that much tighter restrictions would not be useful, like 20,000 1s
> or 0s.
*******************************************************************
* Okay, here is a nice cryptomathematical problem for everyone: *
* Given that you have to make a decision whether or not a *
* sequential flat-random bit stream generator is malfunctioning *
* within 20,000 bits of the point at which it first malfunctions, *
* what tests would you perform? The generator must be treated *
* as a "black box"; no knowledge of its inner workings is *
* available; consequently, the tests must be performed on its *
* output stream. The upper limit for the likelihood of *
* malfunction being reported when it isn't present shall be *
* 10^-6. The goal is to maximize the likelihood of reporting a *
* malfunction when one in fact is present. *
*******************************************************************
> OK, let's say we go along with that. You get a "bust", so you stop
> the TRNG for inspection and find nothing wrong with it. What do
> you do with that "bust" sequence? Do you use it as part of the
> keystream when you start back up or do you discard it?
> If you keep it, you have violated your beloved specifications for
> statistical testing.
No, if you have truly demonstrated that the generator had not
faulted, then the stream is usable *and should be used*.
But I wonder how you demonstrate that the apparent bust was
spurious.
> >(As a matter of historical record, such "busts" have been
> >instrumental in cryptanalyzing a variety of machine systems.)
> Then the TRNG was broken. The "busts", as you call them, are
> not the reason for cryptoanalytic weakness themselves.
I cannot make any sense out of that. Surely, to take an
extreme example, XORing the plaintext with a key stream
that is all 0-bits produces an easily cryptanalyzable
ciphertext. It is not the design algorithm that was broken,
but it was the specific encoder device at that specific time.
> I said I was suspect of using simplistic small sample statistical
> tests, like the FIPS-140 Monobit Test, on the output sequence of a
> TRNG, even for warning purposes. There are better tests for
> generating warnings, tests which are designed to alert you to a
> specific hardware malfunction.
FIPS-140 does not specify a particular encipherment algorithm,
and given that encipherment is normally accomplished by a
collection of 2-transistor gates, any failing transistor of
which can produce an exploitable bust, what could you do to
look for a "specific hardware malfunction"? If you do it with
more transistors, you just add more opportunities for failure.
> The Monobit Test, as it stands in FIPS-140, does NOT "detect"
> anything regarding "brokenness".
Oh, yes, it does. It is a *probabilistic* detection, not an
absolute certainty; the latter is not realizable in practice.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A challenge for you !
Date: Mon, 03 May 1999 21:47:29 GMT
Russell <[EMAIL PROTECTED]> wrote, in part:
>This is a simple version of an encryption program im making. 35 people
>have tried it, no one has cracked it. Give it a go and see if you can!
>Please email me if you do try to decrypt it.
Other people already have noted that if your encryption were any good at all,
and even in many cases if it isn't, it's unlikely anyone could do much with
one example of sample ciphertext.
>W�UEi� �m
I will go one step further, and note that, if you *must* defy convention, and
post ciphertext by itself, in hopes someone will trouble to investigate it,
you could at least make things convenient for them by posting it in
hexadecimal...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: "Christian K�nig" <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Mon, 3 May 1999 11:14:45 +0200
<[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
7g6voq$2j$[EMAIL PROTECTED]
> In article <[EMAIL PROTECTED]>,
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> > Rumor has it Adi Shamir will announce factoring breakthrough soon.
> > Increasing efficiency by orders of magnitude and breaking keys 100-200
> > bits longer than current state of the art.
> >
> > Anybody confirm/deny?
Maybe, this NYT-article is of interest?
http://search.nytimes.com/books/search/bin/fastweb?getdoc+cyber-lib+cyber-li
b+11455+0+wAAA+Shamir
(I think you have to register before you can get it?)
Chris
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator announced by Intel
Date: Mon, 03 May 1999 22:19:29 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, wrote:
> A recent quote from some Russian "Rocket Scientists" turned commercial
> software developers. "Rocket science is nothing, all you need is a
> container with one end cut off and an explosion."
>
While we're off-topic like this ...
I read somewhere that some wise soul had interviewed a lot of people in
highly-skilled to discover how difficult they considered their
occupations to be.
You're right, the rocket scientists said that they thought anyone with
the right training and experience could do their work. The brain
surgeons, however, said "well, this stuff is really quite hard..."
So, I probably meant "Not brain surgery" (which, of course, CPU design
/is/, in a sense).
Cheers,
Daniel
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 03 May 1999 22:51:54 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> SCOTT19U.ZIP_GUY wrote:
>
> > Know to beat a dead horse. Take any file "A" uncompress it get a
> > file "B". Take this file "B" compress it file "C". Then the method
> > to compress decompress is suitable for use with encryption if "A" = "C".
> > That is assuming the method used actually compresses text. Look
> > at my website. Can you even write C code or not? I am truely
> > sorry the concept is to difficult for you to understand.
>
> First, we were discussing the use of an EOF symbol, say, #. I claim that
> one can use your program OR any correct compression program to process
> a user file to which such a symbol is added to its end. Can we
> do it or not? If yes, then what has you argument of A = C have
Yes you can add an eof mark or symbol to any compression program.
But it would give the attacker valuable clues about decrypting
messages. Example (repeated several times) the enemy gets your messaage
tests a key by whatever means. Now at this point the enemy exaims the
file. If its sturcture is such that there is no EOF of the type you
seem locked into using. The enemy knows that he had the incorrect key
and guesses again. That in a nutshell is why one should not do this
for encryption.
> to do with the functionality of EOF? The point is only whether
> the introduction of an EOF is advantageous or not. Adding an EOF
> would never cause a correct compression program to be incorrect!
>
AGAIN IT IS DUMB TO HAVE AN EOF FOR COMPRESSION since the attacker
can rule out many keys since only the one that lead to your EOF would
be the correct ones. IS THIS TO HARD FOR YOU TO GRASP? YES OR NO?
> Second, I believe I can code C sufficiently well. But you want me to
> read you code, or what? Let me remind you that I am not in US and I am
> not supposed (and I don't like) to break the law to illegally fetch
> crypto codes from US, be these yours or others. A minor point is that
> it is no fun to read any C code from other people unless that is well
> documented. (And your 16u, for example, is apparently not well
> documented.)
>
YOu can read my code or not it is up to you. I also supply examples
and executables that you can play with. Also compression is not
encrytion so the code is legal. As for documentation I make no
appolages you get the SOURCE code what the heck can be better than
that. I can't hold your hand forever. Your going to have to stand
on your on two feet by yourself.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: function help
Date: Mon, 26 Apr 1999 19:13:40 GMT
[EMAIL PROTECTED] wrote:
> does this function have an inverse?
> A' = A + B xor C + D
> Without changing A,B,C or D.
> Originally I though 'C - D xor B - A' but that doesn't work.
Your question is confusing!
If you're mapping 4 bits into 1, then of course that's noninvertible.
If you're mapping 4 bits into 4 bits, then what are the other 3 rules
(for B', C', D')?
If you don't actually mean, inverse function, then what *do* you
mean?
Is "xor" supposed to have precedence over "+", or vice-versa, or
are the operators evaluated left-to-right, or right-to-left?
Why do you say "without changing A, B, C, or D" -- why would we
think they are not constant?
------------------------------
** 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
******************************
