Cryptography-Digest Digest #516

2001-06-04 Thread Digestifier

Cryptography-Digest Digest #516, Volume #14   Mon, 4 Jun 01 17:13:01 EDT

Contents:
  Re: Knapsack security??? Ahhuh (John Bailey)
  Re: Diffusion limits in block ciphers (Tim Tyler)
  Re: Diffusion limits in block ciphers ("Tom St Denis")
  Re: Def'n of bijection (John Savard)
  Re: WEB PAGES (SCOTT19U.ZIP_GUY)
  Re: Welcoming another Anti-Evidence Eliminator stooge to USENET  (P.  Dulles / AKA 
Loki) (Dave Howe)
  Re: Welcoming another Anti-Evidence Eliminator stooge to USENET  (P.  Dulles / AKA 
Loki) ("Tom St Denis")
  Re: Def'n of bijection (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Dynamic Transposition Revisited Again (long) ([EMAIL PROTECTED])
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
("Joseph Ashwood")
  Re: Def'n of bijection ([EMAIL PROTECTED])
  Re: National Security Nightmare? (SCOTT19U.ZIP_GUY)
  Re: WEB PAGES (SCOTT19U.ZIP_GUY)
  Re: Welcoming another Anti-Evidence Eliminator stooge to USENET  (Kyle Paskewitz)



From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Knapsack security??? Ahhuh
Date: Mon, 04 Jun 2001 18:43:20 GMT

On 3 Jun 2001 21:32:07 -0700, [EMAIL PROTECTED] (Merc42)
wrote:

>I was wondering if there are any knapsack systems that are still
>secure.  Any that don't use modular arithmatic to change the keys are
>of special interest to me.  Furthermore, if anybody does know of any,
>could you please tell me some reference where i could learn more about
>them.  As always, any help is appreciated...

 I wonder too.  This post in January on this news group did not get
any responses.

(quoting myself)
I was amazed to note that the NTRU Public Key method:
(reference)
Public key cryptosystem method and apparatus
http://www.delphion.com/details?pn=US06081597__
is formally equivalent to a knapsack system.
Referencing the last section of the NTRU tutorial
http://www.ntru.com/technology/tutorials/pkcstutorial.htm
e = r*h + m, where e is the encrypted message, h is a public key, r is
randomly chosen and m is the message.
The message m is recovered by  finding f*e mod q mod p = m.
In the NTRU case,  e, r, h, m, and f are truncated polynomials
whereas, in the cases mentioned at the beginning of this post, they
would simply be large numbers.  In either case, essentially the same
modulo algebra applies, showing the recoverability of encrypted
plaintext using private keys.

Other knapsaci systems:
A Comsat patent:
Simple and effective public-key cryptosystem 
http://www.delphion.com/details?&pn=US04306111__
and
Diophantine encryption for public key encoding
http://www.frontiernet.net/~jmb184/interests/sci.crypt/numerical_encryption.html
In this last one, an encrypted message e = r*h + m*k where e is the
encrypted message, r is a random number, h and k are public key
values, and m is the encrypted message (number)  m is recovered by
computing m = e*g mod p mod q where g, p, and q are calculated from
the private keys.

Simplified knapsack systems are easily implemented  and would provide
a nice means for simple, numeric only  public key tasks such as
symmetric key exchange except they have a history of being ultimately
breakable.

Quoting A. M. Odlyzko of Bell Labs:
The rise and fall of knapsack cryptosystems, 
http://www.research.att.com/~amo/doc/crypto.html
Abstract:
Cryptosystems based on the knapsack problem were among the first
public key systems to be invented, and for a while were considered to
be among the most promising. However, essentially all of the knapsack
cryptosystems that have been proposed so far have been broken. These
notes outline the basic constructions of these cryptosystems and
attacks that have been developed on them. (end quote)

Assuming the NTRU system has a new twist, are there also other
unexploited avenues in which the formalism for simple modulo knapsacks
might lead to interesting public key systems?  An example of such a
system might use digital Fourier Transforms (FFT) to form knapsacks,
along lines paralleling NTRU's use of truncated polynomials.

John Bailey

--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Diffusion limits in block ciphers
Reply-To: [EMAIL PROTECTED]
Date: Mon, 4 Jun 2001 19:02:06 GMT

Scott Fluhrer <[EMAIL PROTECTED]> wrote:

: You are correct, everything being equal, larger blocks are better than
: smaller ones.  However, no matter what you diffuse the information over, the
: diffusion really must be complete -- any partial diffusion [1] can give the
: attacker clues about what the last few rounds look like, and that's a Very
: Bad Thing.  And, as the size of the block grows, it tends to get
: increasingly difficult to maintain the amount of diffusion (without also
: increasing the amount of time spent per bit encryptin

Cryptography-Digest Digest #516

2001-01-21 Thread Digestifier

Cryptography-Digest Digest #516, Volume #13  Sun, 21 Jan 01 16:13:01 EST

Contents:
  Re: How to pronounce Vigenere (Bryan Mongeau)
  Re: Dynamic Transposition Revisited (long) ("John A. Malley")
  Re: How to pronounce Vigenere ("Robert Reynard")
  Re: Windows 98 desktop lockdown application (Steve K)
  Re: using AES finalists in series? (William Hugh Murray)
  Re: How to pronounce Vigenere (JimD)
  Re: cryptographic tourism in Russia (JimD)
  Re: Novell Netware authentication (Quisquater)
  Re: FAQ (Mok-Kong Shen)
  Re: Windows 98 desktop lockdown application (Richard Heathfield)
  Re: FAQ ("John A. Malley")
  Re: using AES finalists in series? (Mok-Kong Shen)
  Re: cryptographic tourism in Russia (John Savard)
  Re: cryptographic tourism in Russia (John Savard)
  Re: 32768-bit cryptography (David Schwartz)
  Re: 32768-bit cryptography (Mike 8465)



From: Bryan Mongeau <[EMAIL PROTECTED]>
Subject: Re: How to pronounce Vigenere
Date: Sun, 21 Jan 2001 17:18:09 GMT

Isn't the word of French origin?
In that case it would be pronounced:

"vee-jhe-nair"

Pronounce "jhe" like the french say "I" ("je").

-- 
<==>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==>

"As far as the laws of mathematics refer to reality, they are not certain, 
as far as they are certain, they do not refer to reality."-- Einstein


--

From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sun, 21 Jan 2001 09:19:01 -0800


John Savard wrote:
> 
> On Sat, 20 Jan 2001 23:15:40 -0800, "John A. Malley"
> <[EMAIL PROTECTED]> wrote, in part:
> 
> >Algorithm P cannot generate more than M distinct permutations when
> >driven by a linear congruential sequence of modulus M. See Knuth Vol. 2,
> >section 3.4.2, Random Sampling and Shuffling. (pg. 145 in the Third
> >Edition.)
> 
> True, but Terry Ritter would not propose any such thing. He is the
> inventor of several quality stream ciphers.
> 

The example used shows us the kind of cryptographically insecure PRNG
and shuffling algorithm used can affect the practical security of the
Dynamic Transposition cipher. A particular shuffling algorithm driven by
a particular cryptographically insecure PRNG that takes on only p-1
distinct values cannot generate every possible permutation of the N bits
in a block if the prime modulus is kept to a "reasonable" magnitude
relative to the number of bits N.

Any PRNG takes on only M distinct values (where M depends on the nature
of the PRNG.) M could be very, very big. The source cited in Knuth's
Vol. 2 states the shuffling Algorithm P can only reach M possible
permutations when driven by a PRNG using output feedback that itself
only attains M possible output values. So if M is much smaller than N!
we'll never actually get all possible permutations of the N bits - and
thus the number of permutations of the bit-balanced block that must be
considered in cryptanalysis reduce significantly. 

I don't know if/how this generalizes across different shuffling
algorithms driven by any kind of PRNG that takes on M distinct states,
but I have a hunch it's not easy (or even possible) to guarantee the
shuffling algorithm in the DTC can actually produce every possible
permutation of N bits in a bit-balanced block when driven by PRNGs. 

Here's a thought - 

A PRNG always takes on M distinct values before it repeats its output
sequence. The PRNG can only start from S distinct seed values, so it can
only generate S distinct pseudorandom sequences of those M distinct
values. Any deterministic shuffling algorithm can only work on the S
different pseudorandom sequences out of the PRNG. We need a
deterministic shuffling algorithm that takes S different inputs and
produces N! different outputs (permutations of N bits.)  That's the only
constraint we put upon the shuffling algorithm - it outputs a unique
permutation of the N bits for each unique input pseudorandom sequence it
gets.  So a bijective shuffling makes the N! permutations of the N bit
bit-balanced block if and only if S >= N!.  That happens if and only if
there are at least N! possible seed values for the PRNG. For a simple
LCG we would then need a modulus M >= N! (which we already showed) and
that results in huge moduli and cumbersome calculations for the LCG used
with large block sizes N. 

So if the shuffling algorithm is deterministic and bijective - each
unique pseudorandom sequence input to it results in a unique permutation
of the N bits in a bit-balanced block - then we must drive the shuffling
algorithm with a PRNG that make

Cryptography-Digest Digest #516

2000-08-23 Thread Digestifier

Cryptography-Digest Digest #516, Volume #12  Wed, 23 Aug 00 15:13:01 EDT

Contents:
  Re: Hidden Markov Models on web site! ("Douglas A. Gwyn")
  Re: SHA-2 name rumors (Daniel Leonard)
  Re: The DeCSS ruling (Jim Steuert)
  Re: Steganography vs. Security through Obscurity (Mike Rosing)
  Re: An interesting cryptographic problem (Mike Rosing)
  Re: The DeCSS ruling (Ichinin)
  Re: The DeCSS ruling (Anonymous)
  Re: Steganography vs. Security through Obscurity ("Aztech")
  Re: Bytes, octets, chars, and characters ("David C. Barber")
  Re: Re-using CD-R discs (S. T. L.)
  Re: The future direction ... ("Richard Bembridge")
  Re: Decryption (John Myre)



From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hidden Markov Models on web site!
Date: Wed, 23 Aug 2000 13:23:06 -0400

Mok-Kong Shen wrote:
> From what I read in this thread I got the (maybe wrong)
> impression that the sequences dealt with are character
> strings. Would HMM be powerful enough to deal with bit
> strings (which are at a finer granularity) from some
> not too bad PRNGs (to predict future output)?

HMM is a general technique, not related to text characters
except when you choose to apply it to them.  The model
is simply a finite number of (internal) states that
have fixed state-transition probabilities (ordinary Markov
model) and the additional feature that the only thing
observable is output that depends probabilistically on
the transition.  (Each piece of output for a single
transition can be *called* a "character" for convenience
in discussion, but the only assumed property is that it
is uniquely identifiable.  The output "character set"
might be the set {0,1}, for example.)  So the output
contains clues about what is going on "inside" the model,
but the clues are indirect since the same output can
result from many possible transitions.  There are further
clues about the state sequence contained in the *sequence*
of outputs.  The process of fitting the model to an
observed output sequence amounts to estimating what
sequence of states (thus transitions) would be the most
likely way of producing that output.  Of course, that
guess could be wrong, but given enough output the
trained model (specified by the parameters for the best
fit) usually tends to reflect what is actually going on
inside the (hidden) system.  It's sort of like a fuzzy
X-ray.

How successful one is at fitting an HMM is largely a
function of how well the assumed number of states
"resonates with" the internal system structure.  You
could try various assumptions and see if any produce
good fits.  Presumably there is an objective measure
of goodness of fit of an HMM to the observations,
although it isn't used directly in the usual fitting
algorithm.  Informally, if the transition and output
probability matrices are quite far from random, there
is a good fit.  For example, a transition matrix
   A   B   C
A 0.7 0.1 0.2
B 0.2 0.5 0.3
C 0.1 0.4 0.5
shows a fairly good categorization, in that the system
tends to stay in the same state, and there are decided
biases in transitions out of the state (e.g. C->A is
4 times less likely than C->B).  Suppose the character
set is {0,1} and the output probabilities are:
out 0:  A   B   C
 A 0.1 0.7 0.2
 B 0.3 0.1 0.6
 C 0.6 0.2 0.2
P(out 1) = 1 - P(out 0)
That shows that most "1"s occur when the system remains
in the same state (at this level of modeling), which is
a potentially valuable clue about how the system works.
Of course, the *actual* system structure would involve
a lot more than 3 states; if we had picked the exact
number *and* had enough data, all the matrix entries
would be very close to 0 or 1 since the system is
deterministic at that level.  By using fewer states,
we lose the details and end up with a probabilistic
model, but some trends can still be seen, and these
often indicate some large-scale aspects of how the
system actually functions.

--

From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: SHA-2 name rumors
Date: Wed, 23 Aug 2000 17:32:36 GMT

On Wed, 23 Aug 2000, Kent Briggs wrote:

> "S. T. L." wrote:
>=20
> > SHA-1 provides 160 bits; isn't that enough?
>=20
> Hash functions make convenient password crunchers and with the new AES st=
andard
> allowing key sizes up to 256 bits, it would nice to have a corresponding =
hash
> function of that size.
>=20
> --
> Kent Briggs, [EMAIL PROTECTED]
> Briggs Softworks, http://www.briggsoft.com

Well, three hash function comes into mind

HAVAL, SNEFRU, RIPEMD256.

==
Daniel L=E9onard

OGMP Informatics DivisionE-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel   : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al   Fax   : (514) 343-

Cryptography-Digest Digest #516

2000-04-08 Thread Digestifier

Cryptography-Digest Digest #516, Volume #11   Sun, 9 Apr 00 00:13:01 EDT

Contents:
  Re: Turing machine (Guy Macon)
  Re: OAP-L3: Semester 1 / Class #1 All are invited. (Taneli Huuskonen)
  Re: Test Vectors for Block Ciphers ("Brian Gladman")
  Re: GSM A5/1 Encryption (Tom St Denis)
  Enigma error (John Savard)
  Re: Cost-effective computing? ([EMAIL PROTECTED])
  Re: GSM A5/1 Encryption (Guy Macon)
  Re: Making keys out of passwords??? ("Markus Hahn")
  Re: Q: Simulation of quantum computing (Bill Unruh)
  Re: Encryption in Software... (Bill Unruh)
  Re: Q: Simulation of quantum computing ([EMAIL PROTECTED])
  Re: Public|Private key cryptography? ("Douglas A. Gwyn")
  Re: Cost-effective computing? ("Douglas A. Gwyn")
  Re: Cryptanalysis-what is it?? ("Douglas A. Gwyn")



From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Turing machine
Date: 08 Apr 2000 18:13:10 EDT

In article <8cnrq3$pku$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David R 
Conorozzo) wrote:
>
>I guess that depends on what you mean by powerful.  Turing machines don't
>exist in reality since they have infinite(and sometimes) 2 way tapes.  To
>compare a Turing machine to a PC you might say that a Turing machine is more
>powerful but if we had a PC with infinite storage we could simulate a Turing
>machine on a PC but not vice versa because a Turing machine requires that
>all data be hardwired before we start the machine and a PC has hardware to
>allow us to do input dynamically.

I disagree.  Turing machine I/O works just like PC I/O.  The computer
(Turing machine or PC) outputs something (a pattern on the tape or
video on a CRT), the state of the memory (tape or ram) is changed by
a non computational process, (New pattern on tape, Windows 2000) and
the computer (Turing machine or PC) continues with the new stored
information.

Partial Turing machines with long finite tapes have been built.  For
the subset of programs that don't hit end of tape they are exactly
equivalent to real Turing machines.


--

From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: 9 Apr 2000 01:32:56 +0300

=BEGIN PGP SIGNED MESSAGE=
Hash: SHA1

In <8cig2e$ot$[EMAIL PROTECTED]> [EMAIL PROTECTED]
(Xcott Craver) writes:

>Anthony Stephen Szopa  <[EMAIL PROTECTED]> wrote:
>>
>>I claim that you cannot successfully use a plain text attack against
>>OAP-L3.
>>
>>Let's cut to the chase:  I will give anyone as many OTP files they 
>>want and all they have to do is predict the next 100 random numbers 
>>(0 - 255) from the OTPs.

>   Great!  Have you mailed Taneli a CD, or are you yet waiting for
>   his reply to your offer?

>   I want to see someone actually step up and take this challenge,
>   as mere talk doesn't seem to convince Mr. Szopa.  

I just sent my address to Mr Szopa a few minutes ago.

However, you seem to have misunderstood the nature of the challenge.  I
simply claimed that one component of his programme, the pseudorandom
digit generator, is cryptographically weak.  That is quite different
from breaking the whole cypher.

>>Believe me, I will create a key with a security level so 
>>astronomical you could take LSD and not get that far out.

>   Well, if you choose a key completely at random, as people are
>   supposed to do, than all keys should have the same level of
>   security, right?

That's a plausible argument, but the concept of a "key" in OAP-L3 is a
bit nonconventional.  A "key" is really a programme in a very restricted
programming language, consisting of instructions to alter the contents
of certain files from a limited set.  Using a very long "key" may well
result in unbreakable output.  Then again, maybe not. *shrug*

Taneli Huuskonen

=BEGIN PGP SIGNATURE=
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBOO+zi1+t0CYLfLaVEQLRjwCg3DTgwJWM45L/rwbpSPLpgwrau7IAnjMo
2r4ltKNsVAnJYsMGrL3q0ZcV
=+RLM
=END PGP SIGNATURE=
-- 
I don't   | All messages will be PGP signed,  | Fight for your right to
speak for | encrypted mail preferred.  Keys:  | use sealed envelopes.
the Uni.  | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/

--

From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Test Vectors for Block Ciphers
Date: Sat, 8 Apr 2000 23:40:03 +0100

"Brian Gladman" <[EMAIL PROTECTED]> wrote in message
news:8cmup8$fm7$[EMAIL PROTECTED]...
[snip]

> I made test vectors and testing programs for all 15 ***original*** AES
> algorithms available at 'ftp.hacktic.nl' (I think i

Cryptography-Digest Digest #516

1999-05-07 Thread Digestifier

Cryptography-Digest Digest #516, Volume #9Fri, 7 May 99 23:13:03 EDT

Contents:
  Re: Pentium3 serial number is based on who you [server/exterior] claimed   to be 
(Armand)
  Re: Kiwi source code released internationally (Sam E. Trenholme)
  Re: Crypto export limits ruled unconstitutional (Lyn A Headley)
  Re: role of PRNG/RNG (kurt wismer)
  Re: Crypto export limits ruled unconstitutional (Jim Gillogly)
  Re: Algorithms where encryption=decryption? (Emmanuel BRESSON)
  Re: Shamir's Discover: to those in the know ([EMAIL PROTECTED])
  Searching information! ("sacfloyd")
  Re: Fast random number generator ([EMAIL PROTECTED])
  Re: Crypto export limits ruled unconstitutional ([EMAIL PROTECTED])
  Re: Triple DES cracked? NYT says so... (Nathan Kennedy)
  Re: The simplest to understand and as secure as it gets. ("Douglas A. Gwyn")
  Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
  Re: Searching information! (David A Molnar)
  Re: Crypto export limits ruled unconstitutional ("hapticz")
  Re: Crypto export limits ruled unconstitutional (Mike McCarty)
  Re: Shamir's Announcement ("Douglas A. Gwyn")
  Re: Shamir's Discover: to those in the know (David A Molnar)



From: [EMAIL PROTECTED] (Armand)
Crossposted-To: alt.security
Subject: Re: Pentium3 serial number is based on who you [server/exterior] claimed   to 
be
Date: 7 May 1999 20:49:10 GMT
Reply-To: address()below


Probably the idea that, what is too much effort today, will be a piece of
cake tomorrow.

Armand

In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> Paul Koning wrote:
>> I think a more accurate statement would be "tamper-resistant software
>> is non-existent".
>> 
>> The whole concept is utterly nonsensical.
> 
> What is the basis for your conclusion?

--

From: [EMAIL PROTECTED] (Sam E. Trenholme)
Crossposted-To: talk.politics.crypto
Subject: Re: Kiwi source code released internationally
Date: 7 May 1999 14:09:18 -0700

[Followups Set appropiately]

Well, I just talked to a lawyer about this, and the decision is not in
effect until the case is returned to the district court and the mandate is
spread.

In Engligh, that means that the Appeal court now orders the district court
to implement this decision, and nothing happens until they do.

Why do I get the feling that the DOJ is going to stay this decision before
the appeal court has a chance to "make it so"?

Sigh, oh sigh.

- Sam

--

From: Lyn A Headley <[EMAIL PROTECTED]>
Subject: Re: Crypto export limits ruled unconstitutional
Date: Fri, 7 May 1999 20:37:46 GMT


When I first heard about this, I figured it was the biggest crypto
news of this decade.  Doesn't it mean that we can do WHATEVER WE WANT
with our cryptographic code now?  Why haven't there been massive
hurrahs and wild parties all over this forum?

-Lyn

--

From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: role of PRNG/RNG
Date: Fri, 7 May 1999 06:25:30 GMT

Eli wrote:
> 
> What is the typical role of a PRNG/RNG in the encryption process?  Why
> is it important?  What does it effect?  How can a faulty one be used to
> break a cryptosystem?

not an expert but... encryption tries to hide information by combining
it with secret information (a key) such that only people who know the
secret (key) can reverse the combination and arrive at the original
information... if the secret is something predictable it makes it easier
to guess or even know what it is so instead unpredictable (random)
numbers are used instead... if a prng/rng is broken then it's output
becomes more predictable and the keys made from it's output are also
more predictable...

that would be a laymans way of looking at it anyways...

> I know it is inconvenient but can responders please email me (I do not
> have regular access to usenet, to retrieve the response).
> 
> Thanks

posted and mailed...


--

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Crypto export limits ruled unconstitutional
Date: Fri, 07 May 1999 14:45:55 -0700

Lyn A Headley wrote:
> 
> When I first heard about this, I figured it was the biggest crypto
> news of this decade.  Doesn't it mean that we can do WHATEVER WE WANT
> with our cryptographic code now?  Why haven't there been massive
> hurrahs and wild parties all over this forum?

There are muted hurrahs over in talk.politics.crypto and sedate parties
on a number of mailing lists, where it's more on-topic than here.  The
"WHATEVER WE WANT" part is premature, according to Bernstein's attorney
Cindy Cohn, who says:

 First, the decision is not final for at least 52 days

Cryptography-Digest Digest #516

1999-01-04 Thread Digestifier

Cryptography-Digest Digest #516, Volume #10   Sat, 6 Nov 99 05:13:04 EST

Contents:
  Re: Incompatible algorithms (Scott Fluhrer)
  Re: questions on smart cards (Hideo Shimizu)
  Re: Proposal: Inexpensive Method of "True Random Data" Generation (Louis)
  Re: How protect HDisk against Customs when entering Great Britain (Menial Roky)
  Re: PGP Cracked ? ("Trevor Jackson, III")
  Re: Proposal: Inexpensive Method of "True Random Data" Generation (Douglas Zare)
  Re: How protect HDisk against Customs when entering Great Britain ("Trevor Jackson, 
III")
  Re: Compression: A ? for David Scott (Tom)
  Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Douglas de la 
Torre")
  Re: PGP Cracked ? (zentara)



From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Incompatible algorithms
Date: Sat, 06 Nov 1999 02:18:23 GMT

In article <7vvdkm$6dg$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>You got my point I suppose.  MARS implemented three 'levels' of
>crypto.  An initial key mixing, some linear mixing, some crypto rounds,
>more linear mixing and key mixing.  These three layers are no where
>near 'compatible' in any sense such as K1 = K2.

And where exactly is the proof that there exists no E2 that is a
composite of E1 and E:

E2(M) = E1(E(M))

whose order of magnitude to break the ciphertext is the same as the order 
of magnitude to break the ciphertext produced by applying E then E1 to 
the plaintext (which was Mr. Polk's question)?  The fact that you, I or
the entire crypto community has thought about it really hard, and don't
have any ideas how to break E2 as easily as E1 or E doesn't mean there
isn't a way.

If (as I read it) Mr. Polk was asking about the composite of two
operations being provably more difficult than either of its components,
then the only answer is that no one has provable nontrivial lower
bounds in cryptography (other than, say, OTP and the Rip Van Winkle
cipher, neither of which apply), and (AFAIK) no one knows what such a
proof would even look like.

-- 
poncho


--

From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: questions on smart cards
Date: Sat, 06 Nov 1999 12:37:50 +0900

Partly.
Smartcard standards are found at credit card company's site.
EMV spec, one of them found at
http://www.mastercard.com/emv/emvspecs01.html

H. Shimizu
TAO, Japan.

--

From: Louis <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 06 Nov 1999 02:34:11 GMT

--  The idea to "use various system timers to extract data from relative
inaccuracies. Put it through some entropizing algorithm, mix well."
would be extremely slow since the quartz crystals are extremely well
correlated.
--  Taking noise from a loudspeaker/audio input in your computer is good
but the bandwidth is at most 10^6 bits per seconds, less if the noisy
sound is not very "loud" or not very good.
--  The digital camera watching a TV set in a Faraday cage idea doesn't
seem like an inexpensive method, but at least it has some bandwidth! You
don't have to put the TV in the Faraday cage: simply short out the
antenna inputs! This will also be better than a picture of AOL CDs
moving in the wind. (John E. Kuslich suggested to use the USB port, can
this port input 30 digital images per seconds?)

 >(1) how random is the TV "snow" to start with?
 Pretty good, it is generated from amplified electronic noise which is
quite unpredictable.
 > (2) what happens when you shoot the snow with the digital cam?
 > how random are the digital pictures?
 Not a good idea, you loose bandwidth and add some periodic signals.
You'd better take the luminance (intensity)
 signal directly from the circuit of your TV.
 > (3) what would be a good "mixing, distilling"
 > algorithm to be applied to the entropy in the snow-files ?
 I don't know, I'm a physicist...
 > (4) what would the throughput rate be in bits per second?
 The bandwith of the luminance is safely one MHz.

 A problem with using the signal from a video camera is that it would be
the sum of a "random" part and a periodic
 part. Suppose for example that one pixel in your camera does not
respond as well to light. Every time the image
 scan would pass through that pixel, the random intensity would be
decreased and your random bit would have more
 chance of being zero! This would be repeated on every image, always at
the same location.

 Here is a general observation for electronically generated noise:
-part of it is truly random,
-part of it is periodic (most likely appears as a period