Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #14 Wed, 6 Jun 01 09:13:01 EDT
Contents:
Re: function notation (injection, bijection, etc..) one last time (Mok-Kong Shen)
Re: function notation (injection, bijection, etc..) one last time (Mok-Kong Shen)
Re: Def'n of bijection (Tim Tyler)
Re: Bow before your new master (Paul Burke)
Re: Def'n of bijection (Tim Tyler)
cheksum on keyfile ("Gisli Sigurdsson")
Re: CTR mode, BICOM, and hiding plaintext length (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding)
Re: fast CTR like ciphers? ("Tom St Denis")
Re: function notation (injection, bijection, etc..) one last time ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding)
Re: cheksum on keyfile (Mats Kindahl)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Def'n of bijection (Tim Tyler)
Re: Bow before your new master (Robert Strand)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 09:44:14 +0200
Tom St Denis wrote:
>
> It seems each time I ask people feud over terminology.
>
> Let me try again :-)
[snip]
Please don't misunderstand me but I think that for such
questions it is best to consult a textbook on algebra.
You would certainly find plenty of them in your local
library. The one that I happen to have at hand and I
find to be quite good is:
L. E. Sieger, Algebra. Springer-Verlag.
M. K. Shen
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 09:57:46 +0200
Mok-Kong Shen wrote:
>
> L. E. Sieger, Algebra. Springer-Verlag.
Shame, I have often typo. The name is Sigler.
M. K. Shen
--
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 08:13:06 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> [EMAIL PROTECTED] wrote:
:>: In other words, you are hoping that false positives are more likely.
[...]
:>: ...some result in that direction is needed for BICOM to provide
:>: any benefit at all. You don't seem to realize that any such result
:>: is needed.
:>
:> This "result" seems unnecessary to me because I see it as being
:> rather obvious.
: Ah! It's true, because it's obvious! Why didn't I see that before!
Well, it's obvious to *me*. I accept that doesn't necessarily mean that
it's obvious to everyone else. Thus my explanations.
: This issue is *central* to any claims of increased security for BICOM.
Note that it applies to any compression program, not just BICOM.
: Therefore, it needs proof, not handwaving.
: And the idea doesn't even ``seem'' obvious, because of one fact you
: keep ignoring: even if BICOM gives a bijection of binary files to
: itself, almost all preimages under BICOM are not in fact plausible
: messages.
Well, if they were it would be really, really obvious - rather than just
obvious.
: There is no a priori reason to believe that potential decrypts will be
: rich in plausible messages; [...]
...except for the fact that compression makes target files smaller, while
increasing the lengths of other files, thus making their density at
small output sizes greater.
: indeed it seems rather unlikely.
Well, you *you*, maybe.
:> You seem to accept already that an "optimal compressor" is likely to
:> make rejecting keys practically impossible. [...]
: No I don't, because it's completely false.
:-(
: It might sometimes prove true, but only by coincidence: if the quantity
: of encrypted information turns out to be close to the quantity of key
: material, then security may be very high.
You can use a three bit key and compress huge files. If all
decompressions look like plausible messages it will be hard
for an attacker to tell which one was intended.
--
__
|im |yler http://rockz.co.uk/ http://alife.co.uk/ http://atoms.org.uk/
--
From: Paul Burke <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
alt.drugs.pot,sci.electronics.design,sci.electronics.repair,sci.environment
Subject: Re: Bow before your new master
Date: Wed, 06 Jun 2001 08:23:22 +
"Mike S." wrote:
> if you take into account the on-purpose attempts
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #13 Tue, 23 Jan 01 18:13:00 EST
Contents:
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re: cryptographic tourism in Russia (Jim)
Re: Some Enigma Questions (Jim)
Re: Some Enigma Questions ("Robert Reynard")
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re:O.T. Corpspeak was (Why Microsoft's Product...) ("Paul Pires")
Re: Why Microsoft's Product Activation Stinks (phil hunt)
Creating a self extracting encrypted exe? ("Ernst")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions ("Douglas A. Gwyn")
Re: Creating a self extracting encrypted exe? ("Paul Pires")
Re: JPEG infidelity for crypto (wtshaw)
KASUMI Analysis? (Was: Re: 3G crypto algorithms) (Kenneth Almquist)
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
Date: Tue, 23 Jan 2001 20:02:32 GMT
"David C. Barber" wrote:
> ... why doesn't the plug board remove, or at least greatly
> reduce this vulnerability e.g. A->R->plug board->A?
Because the plugboard accomplishes just a relabeling of the keys.
> Q2: How did the plug board disconnect the previous straight through
> mapping? Did the process of inserting the plug disconnect the previous
> wiring in the same manner that inserting headphone plugs in some stereo
> systems automatically disconnects the main speakers?
Yes; the jacks are "normally closed" and were quite common in
telephone switchboards.
> Q3: The plugs interchanged pairs of characters, hence there were two plugs
> at each end. Were these plugs keyed to prevent improper insertation?
No need to; they're symmetrical.
> Q4: Is there still a commercial version of the Enigma for sale that is
> essentially the WW II machine?
Not unless somebody is manufacturing them specially for collectors.
> Q5: If properly used (e.g. few messages, good mixing of rotor settings, no
> obvious rotor settings (e.g. QWE), varying messages to avoid obvious cribs,
> having all rotor increment the next rotor at the same position, not sending
> the same message in more than one cipher system, changing of rotors more
> often than once a war, etc), say along the lines of the German Navy, would
> an Enigma today be reasonably secure? Put another way, would it be easily
> crackable today by a single person with some cracking tools and a computer,
> or would it require a high level team like that assembled during the war?
It depends on who is doing the work. A *lot* more is now known
about cryptanalysis of rotor systems in the classified crypto
community than was known when Bletchley Park was operating.
> Q6: How critical is the rotor wiring? While there are some obvious weak
> rotors (e.g. a straight through design, a Caesar cipher rotor, or
> duplicating the same wiring on the second 13 positions of the rotor), is it
> easy or hard to create weak rotors?
This requires a long discussion of cycles, Good diagrams, etc.
which I am not in a position to explain.
> Q7: Did the German Navy's creation of a 4th rotor position that included a
> rotor that in one position made the machine act like 3 rotor machine result
> in a weakened 4th rotor -- even if it hadn't already been compromised
> otherwise? Seems to me what the 4th rotor did was simply create a 3 rotor
> machine with 26 possible reflecting rotors, instead of the previous 1 fixed
> rotor. Right or wrong?
I was under the impression that the additional rotor was a true rotor.
--
From: [EMAIL PROTECTED] (Jim)
Subject: Re: cryptographic tourism in Russia
Reply-To: Jim
Date: Tue, 23 Jan 2001 21:02:25 GMT
On Tue, 23 Jan 2001 10:54:23 +0300, "Vladimir Katalov" <[EMAIL PROTECTED]>
wrote:
>
>Eric Lee Green wrote in message ...
>>Hmm... a point there, given that the government there is now run by a
>>former intelligence officer and that they've a nasty habit of
>>imprisoning Americans that they think are nosing around in the wrong
>>place...
>>
>>A friend of a friend spends time in Russia from time to time (he
>>supposedly is a school teacher, but has this strange habit of turning
>>up wherever things are heating up... e.g. Columbia during the worst of
>>the drug wars, Poland when Solidarity kicked out the Communist
>>government, Russia during the failed coup, ...). The stories I hear
>>are pretty bad -- things apparently got pretty lawless for a while,
>>the old government had virtually collapsed into meaninglessness, and
>>the new government apparently is overreacting by attemptin
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #12 Fri, 25 Aug 00 09:13:00 EDT
Contents:
Re: Serious PGP v5 & v6 bug! (Ian Bell)
PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: The DeCSS ruling (Daniel James)
My encryption algorithm ("Slava K.")
Re: PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: SHA-1 program (cool!) (Mark Wooding)
"Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: How many bits of strength does the ZIP encryption have? (Tim Tyler)
Re: Bytes, octets, chars, and characters (Joona I Palaste)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: "Warn when encrypting to keys with an ADK" ("Michel Bouissou")
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: PGP Vulnerability ("Cheri & Mike Jackmin")
UNIX Passwords ("Martin 'SirDystic' Wolters")
From: Ian Bell <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 12:03:00 +0100
In message <[EMAIL PROTECTED]>, Sam Simpson
<[EMAIL PROTECTED]> writes
>Original from Dr R.Anderson, uk-crypto mailing list.
>The effect is that GCHQ can create a tampered version of your PGP
>public key containing a public key whose corresponding private key is
>also known to themselves, and circulate it. People who encrypt
>traffic
>to you will encrypt it to them too.
Is it possible to put a public key within a public key and for it to
work?
I've tried using PGP6.5.3 to encrypt to a key that had an ADK on it. The
result was that PGP raised an error that I didn't have the ADK's public
key on my keyring and proceeded to just encrypt to the real recipient.
The error message told be that I should ask the recipient for the ADK's
public key.
Therefore it would seem that for GCHQ to exploit the bug, they would
have to add an ADK to Joe Bloggs' key and have to lure people into
downloading the GCHQ public key...
...unless of course, they could put the GCHQ public key _within_ Joe
Bloggs' tampered key and have PGP recognize and use it.
--
Ian BellT U R N P I K E
--
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP Bug: IMPORTANT Personal test report
Date: Fri, 25 Aug 2000 13:20:49 +0200
Well folks,
To be able to diagnose the EXACT behaviour of my PGP 6.5.2 Freeware /
Windows, I made some tests myself which will help understanding how PGP
behaves when encrypting to keys with a forged ADK.
My PGP has the following settings:
- Warning when encrypting to key with an ADK set to ON;
- Display of the ADK column in PGPkeys set to ON.
For this, I imported forged test keys gotten from Ralf's website in the
following way:
1) I imported Key-B1, which is "Billy Clean's" key to which a forged ADK was
added
- This key shows up in PGPKeys with the ADK circle being RED, which
immediately identifies this key as containing a forged ADK.
- The properties of the key shows an ADK tab, in which I see the unknown key
(keyID) being an enforced ADK.
==> FIRST CONCLUSION: It is immediately visible in PGPkeys that the key
contains an ADK, although PGP doesn't detect that this ADK is a forged one.
2) From the explorer, I encrypted a text file to "Billy Clean's" key and
mine as well.
- As soon as I select "Billy Clean's" key in the recipient key selection
box, I get a dialog box that states:
"The user Billy Clean has a missing Additional Decryption Key". Contact the
owner of the key to obtain the additional decryption key"
- I click on OK then see only my own key and Billy's one in the selected
recipients field.
- I encrypt and all goes well.
- Now I try to decrypt the file. The dialog box shows the file was encrypted
to BILLY and MYSELF, no visible trace of another decryption key.
- I can decrypt the file.
3) Now I import Key-C into my keyring, which is the public key of the
"forger" of Billy's key -- The ADK's public key.
- The "ADK" tab in Billy's public key properties box now shows that his ADK
is "control" (the newly imported key).
4) From the explorer, I encrypt again a text file to "Billy's" key and mine
as well.
- As soon as I select "Billy's" key in the recipient selection box, BOTH
BILLY'S KEY *AND* CONTROL'S one drop into the selected recipients field.
- IT IS THUS VISIBLE THAT "CONTROL" WILL BE ABLE TO DECRYPT THE MESSAGE
- NO SPECIFIC WARNING DIALOG BOX HAS BEEN ISSUED BY PGP although the "War
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #11 Wed, 12 Apr 00 06:13:00 EDT
Contents:
Re: Miami Herald article about ATM ripoffs ([EMAIL PROTECTED])
Re: SECAN (Diet NSA)
Re: Introductory Crypto Books ("Joseph Ashwood")
Re: Introductory Crypto Books (Paul Rubin)
Re: Massey-Omura protocol & ECC ([EMAIL PROTECTED])
Re: Compaq invents more efficient RSA?! (Scott Contini)
Re: Skipjack algorithm. (David A. Wagner)
Re: General principles of design (Boris Kazak)
O(...) - Newbie question ("ink")
Dense probabilistic encryption (Claudio Di Flumeri)
Re: O(...) - Newbie question ("Joseph Ashwood")
Re: O(...) - Newbie question ("ink")
RE: Q: Inverse of large, sparse boolean matrix, anyone? ("Manuel Pancorbo")
Non-standard shift register sequences ("Al Grant")
MAA Algorithm source and test values (Jorge Davila Muro)
From: [EMAIL PROTECTED]
Subject: Re: Miami Herald article about ATM ripoffs
Date: Wed, 12 Apr 2000 02:59:57 GMT
In article <8ctu1k$6k5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Narley Okim) writes:
>
> >Today's Miami Herald has an article by David Green
<[EMAIL PROTECTED]>
> >titled, "S. Florida sees new breed of ATM, credit card crooks". In
> >discussing the magnetic stripes on the backs of credit cards, he
says "Each
> >stripe contains a mathematical logarithm necessary to access that
account."
>
> I suspect he meant algorithm. (just a rearrangement of the first four
> letters). But even that is wrong. It contains an offset to get from
teh
> natural PIN created by encrypting various things like the account
number
> by DES with a secret key to the true pin. (See Ross Anderson's
> explanation many years ago here.)
>
Sometimes, and I stress the word "sometimes", Banks would store the on
the Track II of the stripe information such as the Card number, the
expiry Date and the PIN Offset. The way a PIN Is calculated differs
slightly from bank to bank but most bank will encrypt the card number
with what is knows as the PIN Verification Key (PVK) using DES. The
result ( in 16 Hex Chars ) is then Decimilized using a decimilization
Table. The first x number of chars ( where x is the length of the pin )
is known as the "Natural PIN". A modulo-10 addition with the PIN Offset
will give you the PIN.
Knowing only the PIN Offset and the CArd Number will not give you the
PIN.
More and more banks are storing the PIN Offset ( and the Expiry Date )
on a database on the host computer. This is to allow the customer
facilities such as PIN Change, and so that the bank would not need to
re-issue cards.
The practice of storing the PIN Offset on the card is a relic of the
old days where PIN Verification is done at the ATM and not at the Host.
So I guess there is a high probability that the reporter was clueless.
Hope this helps.
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
--
Subject: Re: SECAN
From: Diet NSA <[EMAIL PROTECTED]>
Date: Tue, 11 Apr 2000 20:17:03 -0700
In article <
[EMAIL PROTECTED]>,
Pascal Nourry <
[EMAIL PROTECTED]> wrote:
>Hi,
>I am trying to found some information about SECAN security
evaluation in
>NATO context.
>Is someone can help me ?
>Thanks.
>PN
>
>
There is info available starting about a
third of the way down in this document :
http://nra.nacosa.nato.int/pki/hdocs/
pkiahwg10.htm
BTW, if you talk to NATO you can let them
know that, earlier, I figured out a
relationship between the Podkletnov
experiment and their interest in magneto-
hydrodynamics for aerospace purposes.
I toy with Big Brother, yet He does not share His toys with me :-(
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
--
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Introductory Crypto Books
Date: Tue, 11 Apr 2000 20:13:50 -0700
Applied Crypto, is a very good start, and you could make due
with just that and a few other references from the web to
update the information to include the status of AES. If you
want to learn as much as possible Counterpane has a huge
downloadable library of paper (over 1300 at last check), and
it should cover just about anything you want to know.
Joe
--
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Introductory Crypto Books
Date: 12 Apr 2000 03:34:56 GMT
Josh Tompkins <[EMAIL PROTECTED]> wrote:
>Before I begin, I KNOW that this is a newbie question. Please don't flame me.
No problem with newbie questions. Just don't ask newbie q
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #10 Tue, 9 Nov 99 15:13:03 EST
Contents:
Re: Can the SETI@home client be protected? (Guy Macon)
OT: dates and sigs[Re: PGP Cracked ?] (Jim Gillogly)
Re: Montgomery vs Sqr & Mul -- Specifics (Robert Harley)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: Signals From Intelligent Space Aliens? Forget About It. (SCOTT19U.ZIP_GUY)
Re: What sort of noise should encrypted stuff look like? (Lincoln Yeoh)
Re: Signals From Intelligent Space Aliens? Forget About It. (wtshaw)
Re: How protect HDisk against Customs when entering Great Britain (wtshaw)
Re: What sort of noise should encrypted stuff look like? (wtshaw)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Doug Gwyn
(ISTD/CNS) " <[EMAIL PROTECTED]>)
Re: How protect HDisk against Customs when entering Great Britain (Bill McGonigle)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Self-certified public key.. (Volker Hetzer)
Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed)
ADVIL (wtshaw)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Medical
Electronics Lab)
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can the SETI@home client be protected?
Date: 09 Nov 1999 11:21:52 EST
In article , [EMAIL PROTECTED] (ME) wrote:
>
>Some ideas are below
>Lyal
>
>Guy Macon wrote in message <8087tr$[EMAIL PROTECTED]>...
>>Here is the situation:
>>
>>SETI@home [ http://setiathome.ssl.berkeley.edu/ ] is a scientific
>>experiment that involves millions of Internet-connected computers
>>in the Search for Extraterrestrial Intelligence (SETI). Participants
>>run a program that downloads and analyzes radio telescope data from
>>a server at Berkeley.
>>
>>Certain people have created unauthorized patches that speed up the
>>client program. The scientists at the SETI project have asked that
>[snip]
>>Is this an intractable problem?
>
>Yes
>However, simple steps increase the difficulty of anyone trying to replace
>the client.
>I suggest a handshake process based on a challenge-reponse approach.
>
>Start simple solution:
>Issue a serial number by client.
>Include serial number to track per client performance statistics.
>Abberations in performance data can be detected - refuse more test data to
>these clients.
>End simple solution:
>
>Complex description starts:
>- Every client gets a serial number ( As a result, every client will have a
>unquie hash result from MD5 or SHA etc).
>- The server has a database of serial numbers, and expected hash results
>(make the S/N reflect versions to address version control problems)
>
>When the client uploads results, it must request a challenge
>1) On receipt of the challenge, it produces a hash value based on the
>serialised client and the challenge. This value is unique to the specific
>client, and the challenge.
>2) The hash and serial number are returned to the server
>3) The server calculates the same hash from the serial number, the client
>(the S/N version info identifies the client type/version) and the
>challenge.
>4) If a match, then :
>a) accept the data, otherwise dump it.
>b) provide more data, otherwise refuse to provide more data.
>
>I suggest step 4 uses a server Public Key to ecnrypt the
>challenge/response/serial # data, reducing the potential for spoofing.
>This will prove the user has a valid client, and can reduce the potential
>for invalid clients to exist.
>This also allows statistical performancetracking per client. Clients
>exceeding statistiscally expected performance can be considered invalid.
>Refuse to supply more test data to these clients.
>Not a trivial solution (server-side workload can be high) but the technology
>is in use today in a commercial application to validate banking clients are
>genuine.
>End complex solution.
>
>Start possibly simple solution:
>Have a challenge for the fastest client that produces valid outputs on a set
>of test data.
>Include the fastest client in distrubutions of SET clients.
>Offer kudos or a $1000 dollar challenge every month.
>The unauthroised client makers may spend more time chasing the $100 than
>using their clients to generate results.
>End possibly simple solution
Interesting ideas! Does it help to know that the server knows the IP
address (so it can send work units) and the email address (so it can
credit the right person)? Right now those are both created upon
installation of le
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #9 Wed, 12 May 99 07:13:04 EDT
Contents:
Help: How to protect my files ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Re: AES ("Douglas A. Gwyn")
Re: Time stamping (complete) (Jean-Jacques Quisquater)
Re: AES (Terry Ritter)
Re: Thought question: why do public ciphers use only simple ops like shift and
XOR? (Terry Ritter)
Re: Crypto export limits ruled unconstitutional (cosmo)
Re: Roulettes ([EMAIL PROTECTED])
Re: Help: How to protect my files (Nathan Kennedy)
Re: Thought question: why do public ciphers use only simple ops like shift and
XOR? (Terry Ritter)
Re: Thought question: why do public ciphers use only simple ops like shift and
XOR? (Terry Ritter)
On Contextual Strength (Terry Ritter)
From: [EMAIL PROTECTED]
Subject: Help: How to protect my files
Date: Wed, 12 May 1999 05:30:12 GMT
I would like to know if there is any way to protect a midi file from copying
it easily. I do a lot of midi programming and a lot of people pirates my midi
files. I don't want something too complicated(I know there will be always
a way for hackers) , but just a way to avoid the common people to copy my
files easily. Is there any programm I should use? If you have a good
idealet me know! Thank you very much Jean [EMAIL PROTECTED]
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Wed, 12 May 1999 06:07:42 GMT
"R. Knauer" wrote:
> Then why does Feller claim that it is fundamentally incorrect to infer
> the properties of random number generation from the time average of a
> single sequence?
Who cares why he says that, it's not relevant.
> >The required
> >key stream properties are such that a UBP is a very good model,
> ...
> Therefore claiming that a TRNG can be modeled by a UBP says nothing
> that we do not already know - it adds nothing substantial to the
> discussion.
You chopped my sentence in two and make a spurious objection to the
result. The important point was the *second* part of the sentence:
> >and the Monobit Test checks the actual data against one property of
> >that model.
> And just what might that "one property" be? 1-bit bias perhaps? If
> so, then a sequence of 20,000 bits is but one sample used to
> determine 1 value of that 1-bit bias.
It's hard to be sure what you mean by terms like "1-bit bias". The
Monobit Test checks the first moment of the distribution, which is
indeed a test for "bias".
> The Monobit Test seems to be saying that John Jones is not likely to
> be a salesman because he earns far less than the typical salesman.
> The typical salesman makes $100,000 per year and most salesmen (say
> 95%) make between $85,000 and $115,000 per year, so Jones cannot be
> a salesman since he makes only $25,000 per year.
If John Jones makes only $25,000/year, then there is evidence that he
isn't a very good salesman, and you should consider not using him to
peddle your product. But a better analogy would be: John Jones
normally makes around $100,000/year, but suddenly his sales plummet
to $25,000/year. Should you suspect that he has developed a problem?
How long are you going to retain him as a sales representative if his
performance drops to that level and stays there?
> ... How can Jone's poor earnings be a
> reflection on the typical earnings of the vast majority of salesmen?
Of course, it isn't -- it reflects only on Jones.
> The Monobit Test is an attempt to characterize a random process on
> the basis of some statistical expectation applied to only one sample
> sequence.
Due to practical considerations, it's as large a sample as we can get
before we have to make a decision.
> If you were to take 10,000 such samples at random times and ...
Sorry, we can't DO that. We cannot wait until 200,000,000 stuck
key bits have been used to encrypt vital information.
> I do not believe it is possible to design a single test. Each test
> is a measure of the strength against a particular attack, ...
No, such tests don't even come close to measuring strength against
actual cryptanalytic attacks. They're just checking how well the
generated key stream fits the theoretical UBP model.
> >So, what can you do with only 20,000 sequential bits?
> Beats me.
> I do not think you can do anything meaningful with only one such
> sequence. Perhaps you could break the sequence into 1,000 samples of
> 20 bits each and use them to plot the distribution and calculate
