Cryptography-Digest Digest #467, Volume #9 Mon, 26 Apr 99 16:13:04 EDT
Contents:
Re: RSA-Myth (Anonymous)
Re: choosing g in DH (DJohn37050)
public-key management and distribution ("Anthony King Ho")
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Banner Exchange 981 ([EMAIL PROTECTED])
Re: Radiation/Random Number question (Medical Electronics Lab)
Papers on RC4 key size ([EMAIL PROTECTED])
Re: Double Encryption is Patented! (from talk.politics.crypto) (John Savard)
Re: Double Encryption is Patented! (from talk.politics.crypto) (John Savard)
Re: Double Encryption is Patented! (from talk.politics.crypto) (John Savard)
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Easy identity-proof (NOT Fiat-Shamir) (Christian Geuer-Pollmann)
----------------------------------------------------------------------------
Date: Mon, 26 Apr 1999 15:34:04 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: RSA-Myth
Scott wrote:
>Mahlzeit
>
>
>Anonymous ([EMAIL PROTECTED]) wrote:
>
>> PGP are such that generator with source code and send that the public
>> will never with out code and an RSA PGP. Think.
>
>> But this is RSA approach? How many times send that the public primes
>> it is RSA approach? At baud, even the weaknesses that generator with
>> a probability, that the Spooks may have to think just because the same
>> algorithms is RSA PGP cannot!
>
>> ...
>
>Are non-English/US people supposed to understand this?
>
Are English/US people supposed to understand this? What language is it
in anyways?
Seriously, this passage does resemble random computer-generated text to
some extent, although it does have more internal coherence than most...
<end quote>
Okay, I hate to spoil it now... I'd rather have left it hanging. But I
guess I'm obligated. I'm generally very tolerant of poster's language,
after all I know what learning a second language is like. But when I
see YET ANOTHER stoopid panic-subjected message, written in
truly incomprehensible babble, making preposterous claims, and showing
a complete and utter lack of intelligence. And then the scott19u.zip
guy (what a dorky name. I think I'll name my product after a the
dossy filename of a dorky dossy denigration of my name, then name myself
after it), anyway, then that scott19u.zip guy, who ostensibly is a native
speaker, chimes in with his equally idiotic, almost-as incomprehensible
reply... well, suffice it to say this is the worst one I've seen in a
long time...
I've got this mimic function. It's a zero-knowledge mimic-function--
given any text, it will try to mimic the word-stream based only on the
patterns within that text, at the word level. It has no vocab, no grammar
knowledge, nothing. Anything it says it has learned from the "trainer"
text. It does an amazingly good job at spewing babbling, parodied nothings.
In this case, I just HAD to see what would happen if I fed it the
aernst guy's post, and scott19's reply. And the result was, babble just
like aernst and scott19s posts. With each subsequent reply, I added
the previous post to its knowledge.
I don't know anything about Piso's posts. I'm guessing his uses sentence
patterns in a advanced Mad-Libbish way... it's obvious that it has prior
knowledge. Plus it uses lots of crypto-babble not referenced in these posts
anyway. And some of it tempts me to think he hand-tuned it, but who knows.
The mimic function I used is a program called "dadadodo", do a search for
it. I have some lousy teachers-- I've actually written whole REPORTS using
nothing but dadadodo and pretty-printing the results.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: choosing g in DH
Date: 26 Apr 1999 14:00:13 GMT
IEEE P1363 gives ways to choose g. Also, the use of a prime order g was first
mentioned I believe by Scott Vanstone at the first PKS.
Don Johnson
------------------------------
From: "Anthony King Ho" <[EMAIL PROTECTED]>
Subject: public-key management and distribution
Date: Mon, 26 Apr 1999 10:42:04 -0500
Thanks for reading this post.
Is there a convenient, user-friendly, and secure way to run my own
certificate agent, for public-key management and distribution on the
Internet? I was thinking of this: user goes to a web page and uses his/her
e-mail address to request a password, a random password will be generated
and sent to that e-mail address. The user then uses this password he/she
received to log a secure web page, the system remembers the e-mail address
from the password, the user then inserts the public-key. But as you see,
this is quite insecure, as e-mail is easy to intercept and spoof and the
password is sent in plaintext. On the other hand, I want this to be more
convenient than using fingerprint or driver license... Do you have any
suggestion?
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 26 Apr 1999 14:08:19 GMT
Reply-To: [EMAIL PROTECTED]
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.
The time average does NOT tell you anything about the process. Only
the ensemble average can do that. Only until you analyze a
sufficiently large number of sequences can you decide with reasonable
certainty that the process is failing to conform to the specifications
for a TRNG, by for example not obeying the p = 1/2 specification to
within reasonable certainty.
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.
The fact that such an offsetting complementary sequence does not
appear in the test sequence has nothing to do with its existence in
terms of the capability of the TRNG to generate all possible finite
sequences equiprobably. Wait long enough and it will turn up sometime,
proving that the TRNG is not malfunctioning.
>Notice the tests are not totally
>independent, so in case of a catastrophic malfunction several of
>them might trigger the error state at the same time.
According to FIPS-140, failure of any one of the tests, including the
Monobit Test, is sufficient to trigger an error at those levels. If
the test is not really any good, then it is not really any good no
matter what the level of alert it is used for. If anything, all it
will do is generate false alarms.
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.
But then it would be the Long Run Test.
The fact is that the Monobit Test is too weak as it stands. And all
the statistical snake oil in the world is not going to cover that up.
>It all seems fairly sensible if one wants to halt the system
>shortly after it starts generating "busts", rather than letting
>inadequately secure key streams compromise a lot of traffic.
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. If you discard it, you have violated the
specification for the TRNG. You have given your adversary a reason not
to consider "abnormal" sequences. We have already discussed the
mistake that is.
>(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.
>> Define "consistently" in analytic terms.
>> Define "suitable" in analytic terms.
>These are English words; look them up in a dictionary.
As much as I am a proponent of the dictionary, I wanted to make sure
you did not have some arcane meaning for those terms.
BTW, one does not usually rely on the dictionary for the definition of
mathematical terms - and I did say to define then in *analytic* terms.
>> 2) The TRNG subsystems are shown experimentally to operate within
>> specifications.
>You have never said *how* you could do this, without in effect
>applying one or more statistical tests.
You are as bad as Mok-Kong Shen.
I never said I was against the use of statistical methods in general.
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.
That distinction should be wide enough to drive a truck thru, yet you
guys consistently get it wrong. That tells me that you are not really
reading what I am writing, but just interpreting what I say based on
your personal bias about the matter.
You are like a religious fundamentalist who is absolutely convinced
that the earth was created from nothing 6,000 years ago because it
says so in the Bible. You would not give up that dogmatic position if
the Pope himself told you that it was just a myth.
Pope Feller, along with Cardinals Li & Vitanyi, have tried in vain to
tell you that simplistic small sample statistical tests applied
directly to output sequences tell you nothing about the mathematical
characteristics of the underlying generation process, but you
consistently ignore even infallible pronouncements from such
authorities and continue to beat us over the head with the Statistical
Heresy.
>What if it is computing the wrong thing?
The simple answer to your question is that a quantum computer cannot
compute the wrong thing - it is either computing the right thing, or
it not computing anything at all.
You might benefit from reading that book on quantum computing by
Williams & Clearwater.
>That's the kind of
>brokenness we're concerned about (and that the FIPS-140 tests
>are intended to detect).
The Monobit Test, as it stands in FIPS-140, does NOT "detect" anything
regarding "brokenness".
If anything, I would be far more inclined to use the Long Run Test,
since it is testing for specific hardware errors, like a floating or
shorted output stage.
Ask yourself exactly what the Monobit Test is testing for, and whether
it is adequate to do the task with reasonable certainty, even under
relaxed conditions. If you will do that, you will come face to face
with the meta-mathematical problem here, namely an attempt to infer
the properties of a sequence generation process from the time average
of its output. That assumes that the time average of a given sequence
has something to do with the ensemble average, the latter which does
characterize the process.
But as Feller warns, the time average of a given sequence has
*nothing* (his word, not mine) to do with the ensemble average, and
therefore by implication the time average of a sequence has nothing to
do with the proper characterization of the generation process itself.
Attempting to characterize a sequence generation process from the time
average of a given output is pure snake oil, no matter how many
statistics bibles you thump on the table.
Bob Knauer
"A fear of weapons is a sign of retarded sexual and emotional maturity."
-- Sigmund Freud
------------------------------
From: [EMAIL PROTECTED]
Subject: Banner Exchange 981
Date: Mon, 26 Apr 1999 17:20:57 GMT
Has anyone seen that new banner exchange out there. Its called VirtualBanner. They are
giving away 25000 free impressions just for signing up. They also have a FULL TIME 2:1
exchange ratio and do banner promotion. Check them out at http://www.virtualbanner.com
upwsvswvtqmiswulgwjfqtruqkujiurtdpecixotronpkdxkdsfnivvyehficojseprxlizuowpdqcejkrbbqltdsdvtswrdgtz
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Radiation/Random Number question
Date: Mon, 26 Apr 1999 12:27:46 -0500
[EMAIL PROTECTED] wrote:
> Hmmm. Your paper describes a gain of a million -a sound card microphone
> preamp can't do that, I think. Your circuit is a very well shielded
> multistage lab/instrumentation amplifier, with some digital stuff on the
> outputs. When I've tried to use my soundcard as an audio-rate 'scope, I notice
> limited gain problems with small signals. FWIW.
Like Terry says, all you need is 10mV and you can plug into a
mic jack. Getting up to 10mV needs amplification of ~10^4. I
fed the data direct to an 8 bit A/D, so I wanted the signal to
be in the 5 volt range. That's another factor of 100 or so.
Shielding is important for both lab work (so you know what you're
getting) and for random bit generation. You really want to be
sure you *know* the source of your noise. Having some kind of
RF attack is not something you want to worry about. By generating
the signal and amplifying it in a shielded system you make any
external attack nearly impossible.
I would think that for most purposes, a simple amplifier getting
a gain of 1000 after the buffer amp would work perfectly well into
the mic input of any sound card. An instrumentation amp is pretty
easy to build, just make sure the power is clean!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Papers on RC4 key size
Date: Mon, 26 Apr 1999 18:40:17 GMT
Does anyone know of any papers that discuss the RC4 key-size? Any scientific
account of relative strengths would be extremely usefull. Primary interest is
the relative strengths of 40-bit and 128-bit keys, for SSL of course.
Daniel
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Double Encryption is Patented! (from talk.politics.crypto)
Date: Mon, 26 Apr 1999 18:58:28 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>Oh, my. This patent sounds like it covers a technique I was planning to
>use, although, as someone else noted, it isn't double encryption.
There is a chance that the claims of this patent were just slightly too
narrow, but if so, that may mean the technique I was planning to use is
covered by another patent. All the claims refer to the case where the
message hash is a _keyed_ hash; I envisaged using an unkeyed hash, and
encrypting it later...there are other detail differences, but it seems to
be the same general technique.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Double Encryption is Patented! (from talk.politics.crypto)
Date: Mon, 26 Apr 1999 18:50:35 GMT
"." <none@nowhere> wrote, in part:
>Can anyone believe that simple CBC
>double-encryption is PATENTED????
>(if input filesize=output filesize)
>A method for encrypting a plaintext string into ciphertext begins by cipher
>block chaining (CBC) the plaintext using a first key and a null
>initialization
>vector to generate a CBC message authentication code (MAC) whose length is
>equal
>to the block length. The plaintext string is then cipher block chained
>again,
>now using a second key and the CBC-MAC as the initialization vector, to
>generate
>an enciphered string. The CBC-MAC and a prefix of the enciphered string
>comprising all of the enciphered string except the last block are then
>combined
>to create the ciphertext. The described mode of operation is
>length-preserving,
>yet has the property that related plaintexts give rise to unrelated
>ciphertexts.
>Inventors: Bellare; Mihir (New York, NY); Rogaway; Phillip W.
> (Davis, CA)
> Assignee: International Business Machines Corporation (Austin,
>TX)
Oh, my. This patent sounds like it covers a technique I was planning to
use, although, as someone else noted, it isn't double encryption.
I was going to take all but the first 160 bits of a message, and get the
hash of it via SHA-1. Then, I would XOR that hash with the first 160 bits
of the message, and use the result as a "zero-randomness" key for
encrypting the rest of the message.
Finally, I would encipher the 160 bit session key, plus as much of the
beginning of the encrypted message as possible, as a single block under
RSA.
Although I'm using SHA-1, instead of a block cipher in CBC mode, and for
the encryption afterwards I would use an unrelated cipher method in any
mode, this patent does sould like it covers that basic technique.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Double Encryption is Patented! (from talk.politics.crypto)
Date: Mon, 26 Apr 1999 18:55:27 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>Oh, my. This patent sounds like it covers a technique I was planning to
>use, although, as someone else noted, it isn't double encryption.
I should have mentioned that it's U.S. patent 5673319, and it's from 1997.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 26 Apr 1999 19:27:04 GMT
> > >Notice the tests are not totally
> > >independent, so in case of a catastrophic malfunction several of
> > >them might trigger the error state at the same time.
"Trevor Jackson, III" wrote:
> Irrelevant. ...
It's not totally irrelevant, because it means that the combination
of 3 or 4 tests doesn't improve the overall test coverage as much
as we would think if we assumed that the tests were independent.
> Stop complaining about the features of the tests as if they were
> defects.
*I* wasn't complaining, just noting a feature of the test battery.
------------------------------
Date: Mon, 26 Apr 1999 19:44:50 +0200
From: Christian Geuer-Pollmann <[EMAIL PROTECTED]>
Subject: Easy identity-proof (NOT Fiat-Shamir)
Hi, cryptography community
I need a system used for authentication. Systems like Fiat-Shamir have a
balance in the computation power: The proof is a little bit hard, the
verification is easier. For my project, I need a system with an easy
proof and a harder verification. The proof must be done on a very lousy
hardware (less computing power than a smartcard and much faster like 1/2
second).
Do there exist such systems / protocols?
Greeting, Christian
------------------------------
** 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
******************************
