Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #13 Wed, 21 Mar 01 15:13:01 EST
Contents:
Re: unbreakable code (Benjamin Goldberg)
Re: Fast and Easy crypt send (Hard)
Re: unbreakable code ("Tom St Denis")
Re: redodancy (Fermat)
[OT] Java (Benjamin Goldberg)
New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Bob C.)
Re: Most secure way to add passphrase verification to "CipherSaber" (Benjamin
Goldberg)
Re: [OT] Java (Jeffrey Williams)
Re: redodancy (Benjamin Goldberg)
Re: [OT] Java ("Tom St Denis")
Re: What happens when RSA keys don't use primes? (Doug Stell)
Re: I was so so right about PGP ... so right when I started writing(Frank
Gerlach)
Re: NSA in the news on CNN (John Hairell)
Re: I was so so right about PGP ... so right when I started writingabout PGP and
about one author so right . ("Mxsmanic")
Re: I was so so right about PGP ... so right when I started writing about PGP and
about one author so right . ("Mxsmanic")
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: Popular Mechanics article on NSA ("Mxsmanic")
Re: Advice on storing private keys (SCOTT19U.ZIP_GUY)
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: unbreakable code
Date: Wed, 21 Mar 2001 18:38:07 GMT
Tom St Denis wrote:
>
> "dexMilano" <[EMAIL PROTECTED]> wrote in message
> news:99ad0o$dorm$[EMAIL PROTECTED]...
> > For the others
> > "
> >
> > About all Rabin's scheme buys you is that you don't have to know
> > how to build a decent random number generator. In all other respects
> > it's just a standard one-time pad.
> >
> >
> > -Ben
> >
> > ".
>
> Whoever said the above is a friggin liar. The BBS generator (or any
> other SQRT type thing) is not like an OTP at all.
>
> Tom
Umm, Tom, he's talking about Rabin's *recent* scheme, where both parties
are listening to a high speed source of truly random bits, and use a
cheap, otherwise insecure, PRNG to tell how many bits to skip/take from
this source. He's NOT talking about the rather older RSA-like scheme,
where the message is squared, mod some n=pq.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
--
From: [EMAIL PROTECTED] (Hard)
Subject: Re: Fast and Easy crypt send
Date: Wed, 21 Mar 2001 18:44:29 GMT
you can prepend "rank " to your handle.
that will clear it up.
--
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: unbreakable code
Date: Wed, 21 Mar 2001 18:47:25 GMT
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > "dexMilano" <[EMAIL PROTECTED]> wrote in message
> > news:99ad0o$dorm$[EMAIL PROTECTED]...
> > > For the others
> > > "
> > >
> > > About all Rabin's scheme buys you is that you don't have to know
> > > how to build a decent random number generator. In all other respects
> > > it's just a standard one-time pad.
> > >
> > >
> > > -Ben
> > >
> > > ".
> >
> > Whoever said the above is a friggin liar. The BBS generator (or any
> > other SQRT type thing) is not like an OTP at all.
> >
> > Tom
>
> Umm, Tom, he's talking about Rabin's *recent* scheme, where both parties
> are listening to a high speed source of truly random bits, and use a
> cheap, otherwise insecure, PRNG to tell how many bits to skip/take from
> this source. He's NOT talking about the rather older RSA-like scheme,
> where the message is squared, mod some n=pq.
Whoopsy doodle... hehehe I wasn't following the thread that closely...
Sorry..
Tom
--
From: Fermat <[EMAIL PROTECTED]>
Subject: Re: redodancy
Date: Wed, 21 Mar 2001 19:52:13 +0100
Something like this?
n= function_countstrings()
i=0
Repeat
[
i=i+1
word(i) = word_to_compare
for j= 1 to i-1
( if word(j)=word_to_compare
then function_Remove redundance (word_to_compare)
)
for j=i+1 to n
(if word(j)=word_to_compare
then function_Remove redundance (word_to_compare)
)
]
until i=n
dexMilano wrote:
> Is there some simple algoritm to remove redodan
Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #12 Fri, 20 Oct 00 06:13:00 EDT
Contents:
Re: Looking for small implementation of an asymmetric encryption algor (lcs
Mixmaster Remailer)
Key activation problem on e-mail server ("Rd. Mikhail Malama")
Masterkey Cracked (JPeschel)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: old factoring tricks (David Blackman)
Re: Which "password" is best. (wtshaw)
Re: working with huge numbers (Ray Dillinger)
Re: Which "password" is best. (Ray Dillinger)
Re: idea for spam free email (Graceful Twerp)
Re: Rijndael in Perl (Runu Knips)
Re: Encrypting large blocks with Rijndael (Runu Knips)
Re: As I study Rinjdael... (Runu Knips)
Re: What is desCDMF? (Runu Knips)
How to post absolutely anything on the Internet anonymously (Anthony Stephen Szopa)
Re: Works the md5 hash also for large datafiles (4GB) ? (Runu Knips)
"INTERNET_ANONYMITY - Speech without Accountability" (Anthony Stephen Szopa)
Re: Why trust root CAs ? (Kempelen)
Re: My comments on AES (Runu Knips)
Re: idea for spam free email (Richard Heathfield)
Date: 20 Oct 2000 04:00:07 -
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption algor
> I'm looking for a small implementation of an asymmetric encryption
> algorithm suitable for a low-memory embedded system.
Here's a small math library to do modular arithmetic (multiplication
and exponentiation). From this you could construct an RSA or ElGamal
encryptor. It's kind of slow, but would be fine for RSA encryption with
a small exponent. You do need to make sure your keys are big enough.
/* Small MP package */
#define BITS1024
#define LEN (BITS/(sizeof(unsigned)*8))
#define ULEN(LEN * sizeof(unsigned))
/* Add two numbers mod a third. Inputs must be < modulus */
void
modadd( unsigned *a, unsigned *b, unsigned *m, unsigned *rslt )
{
int i;
unsigned ai, s, ri, df, carry, borrow;
carry = 0;
for( i=0; i=0; --i ) {
if( rslt[i] < m[i] )
return;
if( rslt[i] > m[i] )
break;
}
}
borrow = 0;
for( i=0; i
unsigned a[LEN], b[LEN], c[LEN];
unsigned r[LEN];
unsigned p[LEN] = {
0x, 0x, 0xECE65381, 0x49286651, 0x7C4B1FE6, 0xAE9F2411,
0x5A899FA5, 0xEE386BFB, 0xF406B7ED, 0x0BFF5CB6, 0xA637ED6B, 0xF44C42E9,
0x625E7EC6, 0xE485B576, 0x6D51C245, 0x4FE1356D, 0xF25F1437, 0x302B0A6D,
0xCD3A431B, 0xEF9519B3, 0x8E3404DD, 0x514A0879, 0x3B139B22, 0x020BBEA6,
0x8A67CC74, 0x29024E08, 0x80DC1CD1, 0xC4C6628B, 0x2168C234, 0xC90FDAA2,
0x, 0x
};
main (int ac, char **av)
{
/* Calculate a^(p-1) mod p */
a[0] = 2;
memcpy( b, p, ULEN );
b[0] -= 1;
modexp( a, b, p, r );
}
--
From: "Rd. Mikhail Malama" <[EMAIL PROTECTED]>
Subject: Key activation problem on e-mail server
Date: Thu, 19 Oct 2000 22:50:43 -0600
Dear All,
I've been trying to activate PGP key on a web site where I receive e-mail
from. This sites supports PGP, without PGP tech support, though. So, I
uploaded PGP key in ASCII format to .PGP directory that I created and tried
to run PGPK command. However, I am getting an error message that says that
PGP executable is not found.
I guess, there it is something simple, but a lot of people I discussed this
issue with have no idea what to do.
copland:/home2/istok$ pgpk -a istoke~1.asc
Cannot open configuration file /home/istok/.pgp/pgp.cfg
Retreiving hkp:/horowitz.surfnet.nl:11371/istoke~1.asc
Looking up host horowitz.surfnet.nl
Establishing connection
Sending request
Receiving data
Cleaning up
Complete.
Unable to import keyfile "istoke~1.asc".
Regards,
Michael Malama
--
From: [EMAIL PROTECTED] (JPeschel)
Date: 20 Oct 2000 04:50:37 GMT
Subject: Masterkey Cracked
I've just added to my web site Casimir's
new essay, "The Cracking of MasterKey
v1.02/1.05."
Parts A and B are up now; parts C and
D will soon follow.
You'll find a link to the essay on
my "Key Recovery Resources" page.
Joe
__
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 20 Oct 2000 04:51:26 GMT
Dido Sevilla wrote:
>
>If your machine has wide open physical access, then all that the
>attacker needs to do is remove and replace the battery which keeps the
>CMOS information powered, or to short a jumper on the
Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #11 Tue, 6 Jun 00 16:13:01 EDT Contents: Cryptography FAQ (10/10: References) ([EMAIL PROTECTED]) Re: Observer 4/6/2000: "Your privacy ends here" (U Sewell-Detritus) Re: Some dumb questions (Jim Gillogly) Re: Brute forcing for Counterpane's Password Safe (tomstd) Re: slfsr.c (tomstd) Re: Some dumb questions - Two Time Pad (E-mail) Re: Brute forcing for Counterpane's Password Safe (Sundial Services) Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (10/10: References) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 06 Jun 2000 19:15:51 GMT Archive-name: cryptography-faq/part10 Last-modified: 94/06/13 This is the tenth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in this part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents 10.1. Books on history and classical methods 10.2. Books on modern methods 10.3. Survey articles 10.4. Reference articles 10.5. Journals, conference proceedings 10.6. Other 10.7. How may one obtain copies of FIPS and ANSI standards cited herein? 10.8. Electronic sources 10.9. RFCs (available from [FTPRF]) 10.10. Related newsgroups 10.1. Books on history and classical methods [FRIE1] Lambros D. Callimahos, William F. Friedman, Military Cryptanalytics. Aegean Park Press, ?. [DEA85] Cipher A. Deavours & Louis Kruh, Machine Cryptography and Modern Cryptanalysis. Artech House, 610 Washington St., Dedham, MA 02026, 1985. [FRIE2] William F. Friedman, Solving German Codes in World War I. Aegean Park Press, ?. [GAI44] H. Gaines, Cryptanalysis, a study of ciphers and their solution. Dover Publications, 1944. [HIN00] F.H.Hinsley, et al., British Intelligence in the Second World War. Cambridge University Press. (vol's 1, 2, 3a, 3b & 4, so far). XXX Years and authors, fix XXX [HOD83] Andrew Hodges, Alan Turing: The Enigma. Burnett Books Ltd., 1983 [KAH91] David Kahn, Seizing the Enigma. Houghton Mifflin, 1991. [KAH67] D. Kahn, The Codebreakers. Macmillan Publishing, 1967. [history] [The abridged paperback edition left out most technical details; the original hardcover edition is recommended.] [KOZ84] W. Kozaczuk, Enigma. University Publications of America, 1984 [KUL76] S. Kullback, Statistical Methods in Cryptanalysis. Aegean Park Press, 1976. [SIN66] A. Sinkov, Elementary Cryptanalysis. Math. Assoc. Am. 1966. [WEL82] Gordon Welchman, The Hut Six Story. McGraw-Hill, 1982. [YARDL] Herbert O. Yardley, The American Black Chamber. Aegean Park Press, ?. 10.2. Books on modern methods [BEK82] H. Beker, F. Piper, Cipher Systems. Wiley, 1982. [BRA88] G. Brassard, Modern Cryptology: a tutorial. Spinger-Verlag, 1988. [DEN82] D. Denning, Cryptography and Data Security. Addison-Wesley Publishing Company, 1982. [KOB89] N. Koblitz, A course in number theory and cryptography. Springer-Verlag, 1987. [KON81] A. Konheim, Cryptography: a primer. Wiley, 1981. [MEY82] C. Meyer and S. Matyas, Cryptography: A new dimension in computer security. Wiley, 1982. [PAT87] Wayne Patterson, Mathematical Cryptology for Computer Scientists and Mathematicians. Rowman & Littlefield, 1987. [PFL89] C. Pfleeger, Security in Computing. Prentice-Hall, 1989. [PRI84] W. Price, D. Davies, Security for computer networks. Wiley, 1984. [RUE86] R. Rueppel, Design and Analysis of Stream Ciphers. Springer-Verlag, 1986. [SAL90] A. Saloma, Public-key cryptography. Springer-Verlag, 1990. [SCH94] B. Schneier, Applied Cryptography. John Wiley & Sons, 1994. [errata avbl from [EMAIL PROTECTED]] [WEL88] D. Welsh, Codes and Cryptography. Claredon Press, 1988. 10.3. Survey articles [ANG83] D. Angluin, D. Lichtenstein, Provable Security in Crypto- systems: a survey. Yale University, Department of Computer Science, #288, 1983. [BET90] T. Beth, Algorithm engineering for public key algorithms. IEEE Selected Areas of Communication, 1(4), 458--466, 1990. [DAV83] M. Davio, J. Goethals, Elements of cryptology. in Secure Digital Communications, G. Longo ed., 1--57, 1983. [DIF79] W. Diffie, M. Hellman, Privacy and Authentication: An introduction to cryptography. I
Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #10 Mon, 24 Jan 00 02:13:01 EST
Contents:
Re: New Crypto Rules (wtshaw)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
The Code Book Challenge ("G. R. Bricker")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Card Ciphers ("Joseph Ashwood")
Re: Challenge. ("Douglas A. Gwyn")
Re: Combination of stream and block encryption techniques ("Douglas A. Gwyn")
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: New Crypto Rules
Date: Mon, 24 Jan 2000 00:44:26 -0600
In article <[EMAIL PROTECTED]>, "John E. Kuslich"
<[EMAIL PROTECTED]> wrote:
> The "rules" will be determined after you have made your case to the
> "authorities" not before.
>
> If the "authorities" specify that there is a one time review and then do
> not specify whet they are reviewing, then this is the only conclusion
> that may be drawn.
>
> I think those who have bought the hype that the reules have benn relaxed
> are in for a terrible surprise.
>
The idea is to get you to be relaxed so you don't fight injustice.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Ed Stone) wrote:
> It's clear that the new regs aren't clear.
>
> Source: Cindy Cohn, lead Bernstein counsel in Bernstein v. Dept. of
> Justice, et. al.
>
--
As an issue in the campaigns, crypto may be forgotten unless we
ask questions whenever we can to bring it up. Report responses.
--
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 06:35:18 GMT
r.e.s. <[EMAIL PROTECTED]> wrote:
>K A 2 ... J Q
>0 1 2 ... 11 12
> -
>Diamonds 0| 0 1 2 ... 11 12
>Spades 1| 13 14 15 ... 24 25
>Hearts 2| 26 27 28 ... 37 38
>Clubs3| 39 40 41 ... 50 51
>
>Take the "value" of a card as a *pair* of numbers (suit, facevalue),
>i.e. the (row,col) coordinates in the above table, and leave it at
>that while navigating the card layout. Don't waste time finding the
>values 0-51!
Actually it doesn't much matter what order the "card table" is
in, if you have a convenient way to do the arithmetic. So try
it like this:
0 40 28 16 4 44 32 20 8 48 36 24
13 1 41 29 17 5 45 33 21 9 49 37
26 14 2 42 30 18 6 46 34 22 10 50
39 27 15 3 43 31 19 7 47 35 23 11
instead of in 0,1,2... order. Notice that with this layout,
table[row, col] % 13 = col, and
table[row, col] % 4 = row.
You don't have to write down the above array or pay any attention
to it at all; I just included it to help explain the principle here.
>The real savings come in the final steps:
>
>While swapping the two cards, separately add up their "rows" & "cols".
>"rows" is the mod 4 sum of their suits, and "cols" is the facevalue
>sum (if it exceeds 0-12, increase the row sum by 1, and take
>"cols" = facevalue - 13).
Now just take the facevalue and suit sums mod 13 and 4 respectively,
independently of each other. If the facevalue sum exceeds 13 just
subtract 13. You don't have to adjust the row sum. This saves you
a step. The Chinese Remainder Theorem in action ;-).
>For the final step, put your finger at the (0,0) position in the
>card-layout and move it the number of rows and columns indicated
>by the (rows,cols) just obtained. You'll then be pointing at the
>output card.
Is this the scheme you were getting 3-4 characters/minute with?
Or is it faster now?
One final speedup: use all 52 values codebook style:
0=a, 1=b, ..., 26=z
27 = "escape" (like in ascii)
28 = unescape
escaped, 0-9 = digits 0-9
1-2-3-27-1-2-3-4-5-28-6-7 would be read abc12345fg
Now use other codes for frequently used phrases in your traffic.
So if you're organizing a chocolate heist, you might use
29 = "president", 30 = "terrorist", 31 = "duct tape", 32 = "helicopter",
plus escape codes:
escape-15 = "roadblock" escape-16 = "chocolate" etc.
This cuts down the number of characters you need to send.
It does mean your agents now have to memorize the codebook, or
carry a printed copy (use edible paper like in the movies, or
print on silk like in "Between Sil
Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #9Sun, 1 Aug 99 10:13:04 EDT
Contents:
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is ("Douglas
A. Gwyn")
Re: Modified Vigenere cipher (Jim Gillogly)
Re: Modified Vigenere cipher (JPeschel)
Re: Looking for RC4 alternative ([EMAIL PROTECTED])
Re: Modified Vigenere cipher (Jim Gillogly)
Re: Modified Vigenere cipher ("Douglas A. Gwyn")
Another random question ("Jeffery Nelson")
Re: Modified Vigenere cipher (Castover80)
Re: Bad Test of Steve Reid's SHA1 (Jaime Suarez)
Re: Modified Vigenere cipher (JPeschel)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Ariel Scolnicov)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
("donald tees")
Re: ? PGP, RSA and ElGamal ? (Gallicus)
Re: bits and bytes (Thomas Pornin)
SCOTT19U CONTEST UPDATE (SCOTT19U.ZIP_GUY)
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is
Date: Sun, 01 Aug 1999 01:19:11 GMT
[EMAIL PROTECTED] wrote:
> ... A megabyte is 2^20 bytes so megabyte is not always 2^23 bits?
"Megabyte" is ambiguous even if you mean 8-bit bytes. Some people
mean 2^23 bits, while others mean 2^9*5^6 bits. ISO came up with
some new, unambiguous prefixes to replace Kilo-, Mega-, etc., but
nobody seems to use them.
--
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Modified Vigenere cipher
Date: Sat, 31 Jul 1999 19:22:00 -0700
JPeschel wrote:
>
> >[EMAIL PROTECTED] writes:
>
> >What is the "average column IC" for a ciphertext ?
>
> Fauzan Mirza wrote some code in C called vigsolve to solve
> Vigeneres. I believe it also gives the IC for a couple other
> polyalphabetic substitution systems.
Period determination with I.C. is independent of the type of
periodic polyalphabetic system: it measures the roughness of
each column, but expresses no opinion on how that roughness
came about. If it gives the IC for Vigenere it will also give
it for Beaufort, Variant Beaufort, Porta, and the mixed alphabet
versions.
--
Jim Gillogly
Hevensday, 9 Wedmath S.R. 1999, 02:20
12.19.6.7.7, 12 Manik 15 Xul, Third Lord of Night
--
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Modified Vigenere cipher
Date: 01 Aug 1999 02:01:02 GMT
>[EMAIL PROTECTED] writes:
>What is the "average column IC" for a ciphertext ?
Fauzan Mirza wrote some code in C called vigsolve to solve
Vigeneres. I believe it also gives the IC for a couple other
polyalphabetic substitution systems.
Joe
__
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__
--
From: [EMAIL PROTECTED]
Subject: Re: Looking for RC4 alternative
Date: Sun, 01 Aug 1999 02:52:45 GMT
In article <7nvsbp$bn4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Aha, this may explain why my results from a similar algorithm.
> Essentially, I took the final table stirring part of the key
> schedule from David Wheeler's WAKE, cut it down to 8 bits and
> came up with:
>
> if( x == 0 ) t[256] = t[0];
> x = (x + 1) & 255;
> y = y ^ t[x ^ y];
> t[x] = t[y];
> t[y] = t[x + 1];
> out = t[t[x] ^ t[y]];
>
> I've been putting it through the DIEHARD tests and it did not
> seem to do as well as RC4.
Probably cuz you get a lot of 'x == y' conditions. In RC4 there is no
fixed point where 'x == y' will result in a zero output. There are
zero points in RC4 though (it's possible to fix either x or y and find
the other which will result in a zero output).
> However, I think we may agree that changing the 't' calculation
> in RC4 would be a good way to modify it without changing some
> of its useful characteristics (cycle lengths etc).
Maybe not. Your
y = y ^ t[y ^ x]
is not close from being in RC4, the line should read
y = (y + S[x]) mod 256
or in your code
y ^= S[x];
Why not just keep RC4 the same? If you really want to change something
change the last line to
O = t[t[x] + ~t[y]]
or something ... This has absolutely no effect on the 'security' of
it, makes it slower and intrigues others ...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what yo
Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #8 Mon, 25 Jan 99 20:13:02 EST
Contents:
Re: Random numbers from a sound card? (Paul Rubin)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: The Performance of Meet-in-the-Middle ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Random numbers from a sound card? (Nathan Kennedy)
Re: Random numbers from a sound card? (R. Knauer)
Would the gentleman with Mondex knowledge in the USA please contact me again.
("Simon Copsey")
Re: S-box cycles (Anthony)
Re: [req]:Cryptanalysis tool - word pattern table (©ú¥Õ)
Unicity, DES Unicity and Open-Keys ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Random numbers from a sound card?
Date: Mon, 25 Jan 1999 21:21:09 GMT
In article <[EMAIL PROTECTED]>,
David Ross <[EMAIL PROTECTED]> wrote:
> Has anyone had success using a sound card (like a Sound Blaster) to
>generate streams of random numbers?
Yes, see http://www.lila.com/nautilus/index.html and download the
source from one of the sites mentioned there.
> What sort of audio source would you suspect would be the best to use
>in generating random numbers?
We ask the user to blow into the microphone to make noise, IIRC.
> How would you test the 'quality' of the generated random number
>stream?
We just test the total amount of energy in the audio to make sure
the mic isn't dead. We expect that the raw audio will have lots
of correlation, so we run it through a hash function or block cipher;
I don't remember the details.
--
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 09:07:36 -0500
In article <[EMAIL PROTECTED]>,
>> What is the actual likelihood of a readable text string
>> being output from an OTP? Most of the encrypted files
>> I've looked at contained very few readable strings of
>> even two characters. I would think that a readable
>> string output would be more likely to be the result of
>> an accidental transmission of plaintext or a zero key
>> than it would be the result of a readable string
>> encrypting to another readable string.
>
>To answer this precisely you need to provide a definition of "a readable
>text string". In terms of letters and spaces in ASCII the odds would be
>(65/265)^N where N is the length of the string of text. Of course this
>formula treats upper and lower case as similar so it includes WiErD
>STRingS liKE thiS One.
>
>> >(n.b. -- if the message I receive reads "attacd at
>> nown", and you use
>> >a stronger filter of never allowing six successive
>> zeros, then I can
>> >still unbutton your message. The reason being the pad
>> necessary to
>> >produce "attack at noon" would be an illegal pad --
>> and hence you're
>> >still attacking at dawn).
>>
>> Is this an indication of a "fatal flaw" in the OTP?
>> From what I've read in this newsgroup, it appears that
>> much of an analyst's work is discovering how plaintext
>> is leaked into the ciphertext. With the OTP, any byte
>> of zero in the key leaks a plaintext character, and
>> that would seem to make analysis possible. Or, as
>> described here, maybe easy. On the other hand, if I
>> knew that the only two possible messages were "attack
>> at noon" and "attack at dawn", I wouldn't bother
>> worrying about which the message specified. I'd already
>> know enough to prepare for an attack.
This isn't an indication of a fatal flaw in the OTP. The reason is,
bluntly, that the amount of "leakage" produced by a zero character
in the bad -- or even a zero bit in the pad -- is *exactly* balanced
by the amount of "false leakage" where something it put into the
pad. So if you see an 'E' in the cyphertext, you have no way of knowing
whether or not this is a leaked 'E' or a spurious 'E' created by
something else XORing to E.
And, in fact, if this "leakage" *weren't* there, then you would KNOW
every time you saw an 'E' that the plaintext letter COULDN'T be an 'E',
which would be a significant weakness..
>> >>
>> >>> As to whether or not the loss of entropy is
>> significant to make a
>> >>> practical difference -- that depends on the degree
>> of filtering.
>> >>> What you do really buy by doing the filtering? Not
>> much --- and
>> >>> every time the filter triggers introduces a
>> weakness.
>> >>
>> >
