Cryptography-Digest Digest #193, Volume #14 Fri, 20 Apr 01 17:13:00 EDT
Contents:
Re: Rabin-Miller prime testing (Terry L. Cowart)
Re: DL blind signature ("Cristiano")
Re: Note on combining PRNGs with the method of Wichmann and Hill ("Paul Pires")
Re: Good textbooks on information theory ([EMAIL PROTECTED])
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: First cipher ([EMAIL PROTECTED])
Re: First cipher ([EMAIL PROTECTED])
Random and not random (newbie)
digital certs What is the format of the file? ("normangrant")
Re: Random and not random (Jack Brennen)
Re: "UNCOBER" = Universal Code Breaker ("Joseph Ashwood")
Re: "UNCOBER" = Universal Code Breaker ("Joseph Ashwood")
Re: Minimal Perfect Hashing ("Francois St-Arnaud")
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: Random and not random ("Tom St Denis")
Re: Basic AES question ("Joseph Ashwood")
Re: "UNCOBER" = Universal Code Breaker (Leonard R. Budney)
Re: First cipher ("Tom St Denis")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry L. Cowart)
Subject: Re: Rabin-Miller prime testing
Date: Fri, 20 Apr 2001 17:32:04 GMT
On 17 Apr 2001 13:07:53 +0200, Simon Josefsson <[EMAIL PROTECTED]> wrote:
>Bryan Olson <[EMAIL PROTECTED]> writes:
>
>> 2. Do one base-2 Miller-Rabin (or Fermat) test.
>>
>> 3. Do several random-base Miller-Rabin tests, or a Lucas
>> test.
>>
>> In practice, step 2 dominates the run time, since it usually
>> rejects many candidates.
>>
>> Alternately, we can generate provable primes in not much
>> more time, but there's no practical advantage.
>
>Depends on the threat model -- if you're verifying someone else's
>numbers for primeness, you can be deceived if you're only using
>Miller-Rabin or similar methods.
>
If you are verifying someone else's numbers, it seems there is a
certain level of distrust in the first place. If that distrust is not
misplaced, it is possible the other participant has created a number
that is the composite of exactly two large primes. In that case, it
would seem that any nondeterministic test for primeness would be
unlikely to conclude that the suspect number was indeed a composite,
since the number has only two factors.
Since this is not my primary expertise, what is the current theory on
primality tests for such (2 prime factors) composite numbers? Is
deterministic testing required, or are there nondeterministic tests
that will find them?
Terry L. Cowart [EMAIL PROTECTED]
Solutions Architect, SCA Technologies http://www.scatech.com
Brainbench MVP for Internet Security http://www.brainbench.com
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: DL blind signature
Date: Fri, 20 Apr 2001 20:32:30 +0200
Thank you for the answer.
"Ian Goldberg" ha scritto nel messaggio:
> [Note: I don't have the particular paper in front of me, so I'm basing
> these answers on what usually happens with DL protocols in the subgroup
> construction.]
If you are interested, the paper (only 74 kB) is:
http://www.bogor.net/idkf/idkf-1/aplikasi/e-commerce/loyalty-program-scheme-
for-anonymous-payment-systems-1999.pdf
> Cristiano wrote:
> >In many systems (or perhaps in all) for the blind signature based on DL,
one
> >must choose a prime q that divides p-1 (also p is prime) and then a
> >generator in the moltiplicative group Zq* [...].
>
> Careful; g isn't supposed to be a generator for Zq*. g is supposed to
> be a generator for the subgroup of Zp* which is of order q.
You are right, but what is the difference?
> >Doing some trials with small numbers, when I compute the public key y=g^a
> >mod p (a is my private key) for all a<p, the distribution of y may be
very
> >bad; on the contrary, if I compute y=g^a mod q for all a<q, the
distribution
> >is as expected: I get all the elements in Zq* (g is a generator!).
>
> I think your g may be incorrect. The easiest way to choose g is:
>
> o Let h be a random element of Zp*.
> o Let g = h^((p-1)/q) mod p.
> o Try again if g=1.
>
> Clearly, g^q mod p = h^(p-1) mod p = 1, so g has order dividing q.
> If g is not 1, then since q is prime, g has order exactly q, so g
> generates the subgroup of order q of Zp*.
>
> Then if you calculate y=g^a for all a<q, you'll get all of the elements
> of that subgroup.
I have some problem with your algorithm: p=23; q=11 (in my implementation q
is always (p-1)/2); h=14; g=14*14 mod 23=12.
If I compute g^a mod q I get: 12 1 1 1 1 1 1 1 1 1 (for a=1 ... 10);
If I compute g^a mod p I get: 12 6 3 13 18 9 16 8 4 2 (for a=1 ... 10).
The paper say: "[...] and the corresponding private key is x, where [...]
g^x = h mod p." (h is the public key). Is it correct (again I don't
understand when mod p and when mod q)?
> >My implementation of the algorithm in the above paper at page 13
> >(Chaum-Pedersen blind signature) doesn't work. The modulo for all the
> >calculations is not shown. Is it always mod p or mod q?
>
> If you're calculating with group elements, it's mod p. If you're
> calculating with exponents, it's mod q.
In this way it is worse. If I reverse what you have told (mod p with mod q)
the signature works and the last verification doesn't works; If I do like
you have told don't work nor the signature neither the verification.
I thought that the blind signature in DL is simpler than that in EC! :-)
Thanks
Cristiano
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Fri, 20 Apr 2001 11:46:20 -0700
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snip>
> It was included on the disks accompanying Applied Cryptography
> under the file name I-HAT.ZIP. For your convenience and possible
> general interest I have appended the documentation to this message.
Nice reference.
Are you sure you trust the original author?? :-)
Paul
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Good textbooks on information theory
Date: 20 Apr 2001 18:55:05 GMT
Joe H Acker <[EMAIL PROTECTED]> wrote:
> I already know a bit about information theory and once read the original
> Shannon paper, but I'm looking for a good reference and/or introductory
> text to general information theory. One of these excellent textbooks for
> teaching that are understandable, aren't clutered with lemmas, but
> provide all necessary information for applying the theory.
> There are plenty of books about information theory, which one would you
> recommend?
The best I've seen is "Elements of Information Theory" by Cover and
Thomas....
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Fri, 20 Apr 2001 14:58:52 -0300
How could you know that the keystream used to Xor plaintext is truly
random?????????
Truly random is ideal situation. In practice, we measure randomness
degree. How you measure it????????????
How could you distinguish between truly random or not??????
You have to apply statistical tests.
So I suppose that the keystream used is truly random. That means that
this keystream was filtred by statistical tests. So I have still the
ability to know if my input 10100010010110 Xored with my ciphertext
100100100100 give me truly random sequence or not.
The keysteam used is truly random BUT MY OUTPUT IS NOT NECESSARLY TRULY
RANDOM.
Tom St Denis wrote:
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > So if the probability of non-random is infinitesimal, why to try
> > statistical tests to prove truly randomness?
> > Statistical tests (Diehard, Maurer etc...), is it a loss of time?
> > Sincerely I do not understand.
> > I choose any bit-string I have 99.9999999 % that is purely random.
> > Why wasting time to find if it is random or not.
>
> Why don't ya just read some books on the subject instead of constantly
> randomly posting here? Obviously you are a clueless newbie, which is ok but
> you have to learn to "learn".
>
> Test's like Diehard look for particular types of flaws in particular prngs.
> Most importantly some of tests look for flaws in lagged fibonacii generators
> (birthday spacing).
>
> Typically if your prng given say 20MB of output produces results that
> diehard gives a p=1 or p=0 (or close too) then your PRNG is biased...
>
> I know a few times it was usefull for detecting minute flaws in my homebrew
> prngs...
>
> Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Fri, 20 Apr 2001 10:19:00 -0800
David Wagner wrote:
>
> >Supposedly, if the S-box is reversible and the number of bits per table
> >entry is large, then the probability of a random S-box having one or
> >more bits that are linear functions of the address bits is low.
>
> (... if the S-box is large enough, and is selected at random.)
>
> >Ah, but at one time each one of them was a neophyte just like me.
>
> Yes, but designing new ciphers is unlikely to be the best way to
> learn how to design new ciphers. (Sounds counter-intuitive, but
> it seems to be true.)
I'd be glad to start paying my dues on the cryptanalysis end of things.
The problem seems to be finding a consolidated, unified guide in the
literature.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Fri, 20 Apr 2001 10:30:00 -0800
Tom St Denis wrote:
>
> <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > "M.S. Bob" wrote:
> > >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > "M.S. Bob" wrote:
> > > > >
> > > > > [EMAIL PROTECTED] wrote:
> > >
> > > As his says in his self-study course, there is no one good text on
> > > cryptanalysis of modern ciphers.
> >
> > This is somewhat sad, given that there are textbooks out
> > there on some extremely complicated scientific/mathematical analysis
> > problems.
>
> Not really. Analysis is just one of those subjects that never ends. Find
> one good text that answers all questions about god? Or about how the human
> brain works, or how to factor large integers, or how to remove money from
> society or how to make good tv programs?
>
> Answers to these questions will vary over time....
>
> Tom
You can teach an electrical engineering student the basics of circuit
analysis
by analyzing simpler problems and progressing to more complex problems.
Hopefully
by the end of the curriculum, the fire will light and the student will
be able
to approach a wide range of analysis problems and design circuits on
his/her own.
In spite of the best instruction, some students will never be able to
move
from analysis to design BUT there is a progressive method of teaching an
approach to what are sometimes very complex design or analysis problems.
I'd like to think that the crypto field, like any scientic endeavor, has
a similar method of passing along its cumulative knowledge to serious
students, and not just "go do a hodge-podge
self study course and come back when you've taught yourself everything".
If the basics of cryptanalysis aren't understood well enough to be
documented and
taught, maybe the .crypt should be moved from sci. into alt.
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Random and not random
Date: Fri, 20 Apr 2001 15:48:45 -0300
Let my ciphertext = c(i)
Let my choosen plaintext to test = p(i)
Let ouptut = c(i) Xor p(i).
Length of ciphertext = n
I suppose that my keystream is generated by PRNG.
Suppose that c(i) Xor p(i) = 11111111111111101111110111111111 ( (n-2)
one's and 2 zero's ) for all the length of my ciphertext.
Obvious I have to reject my choosen plaintext.
Not because it contains (n-2) one's, but because it is quite impossible.
The probality to obtain this sequence is near 0.
It does not matter if keystream is random or not.
if (Randomness of PRNG > randomness of "truly random sequence) then my
rejection is more likely valid if the keystream was truly random
sequence.
What do you think about that statement?
Newbie.
------------------------------
From: "normangrant" <[EMAIL PROTECTED]>
Subject: digital certs What is the format of the file?
Date: Fri, 20 Apr 2001 22:27:14 +0200
Hi
I have done a few searches of the web for digital certs and find a lot of
information on how it works etc etc.
The problem is WHAT do you do if you want to write such a file??. Let me be
pedantic.. If I wanted to write to a x509 cert DER CA cert, what is the
exact format needed. I really could not believe that this was not readily
available on the web!! Thanks
------------------------------
From: Jack Brennen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Fri, 20 Apr 2001 16:26:43 -0400
> Suppose that c(i) Xor p(i) = 11111111111111101111110111111111 ( (n-2)
> one's and 2 zero's ) for all the length of my ciphertext.
>
> Obvious I have to reject my choosen plaintext.
> Not because it contains (n-2) one's, but because it is quite impossible.
> The probality to obtain this sequence is near 0.
Any sequence is as likely as any other sequence given a good PRNG,
and the probability to obtain any particular sequence is in fact
near 0. That's what makes it a good PRNG!
A good PRNG will give the sequence:
11111111111111101111110111111111
as often as it will give the sequence:
10011101001001100001010011101001
In fact, it will give these sequences just as often:
00000000000000000000000000000000
11111111111111111111111111111111
If you don't believe that, then find another hobby, because it
falls under the realm of "that which should be obvious" :-)
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Fri, 20 Apr 2001 13:23:56 -0700
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> How could you know that the keystream used to Xor plaintext is truly
> random?????????
By definition.
> Truly random is ideal situation. In practice, we measure randomness
> degree. How you measure it????????????
You judge the generator, if the generator produces purely random data so be
it.
> How could you distinguish between truly random or not??????
By analyzing the generator
> You have to apply statistical tests.
BZZZZTTTT!!!! Wrong again, I've corrected you on this repeatedly now. You
have to analyze THE GENERATOR not the output, analyzing the output can tell
you complexity, but analyzing the generator can tell you randomness. I gave
an example of this that you seem to be completely ignoring. An infinitely
long output of ARCFOUR is likely to have very high complexity. However given
complete knowledge of the generator it is possible to reduce that entire
sequence to a key for ARCFOUR, giving me a reduction from infinite to at
most 256 bytes. ARCFOUR passes statistical tests consistently, but it is not
random, merely complex.
> So I suppose that the keystream used is truly random. That means that
> this keystream was filtred by statistical tests.
No random means that given all bits of the key stream save 1, it is
impossible to predict the value of that bit with probability higher than
0.5. It is likely that a random text will pass statistical tests, but
passing statistical tests every time is a sign of a flaw. A short proof, by
building a pRNG that demonstrates this. Take a very long key (say 20 Mbit),
to compute the next bit you compute the bit that passes your choice of
statistical tests the best, remove the first bit from the key, add the
generated bit to the end of the key, and output the bit. This pRNG will
always pass the statistical tests, but the sequence will be predictable
given 20Mbit of contiguous known data, simply by the fact that the attacker
knows the entire state. So one preposition must be wrong either:
The attacker can't predict this pRNG by knowing the entire state or
The statistical tests do not dictate security
Now since the user is predicting the next state by knowing the complete
state, the first cannot be wrong, therefore the second must be wrong.
> So I have still the
> ability to know if my input 10100010010110 Xored with my ciphertext
> 100100100100 give me truly random sequence or not.
Sort of correct, except your basis of assumption is wrong. You insist on
going form the basis of complexity when complexity and randomness/chaos need
not coincide.
> The keysteam used is truly random BUT MY OUTPUT IS NOT NECESSARLY TRULY
> RANDOM.
Actually the output you've given this group has a very high amount of
correlation, so I think you're correct. Now about the choices you are
insisting are necessary for security, this statement makes no sense. I think
you need to read up a bit on entropy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Fri, 20 Apr 2001 13:29:40 -0700
"Joe H Acker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If the random source is truly random, it doesn't do any harm when some
> of its output is discarded, except for performance slowdown. So yes,
> tests are useful to (a) continually test wether the hardware has failed
> or does appear to work correctly, and (b) to prevent against very very
> bad luck when a true random source happens to output the complete volume
> of Shakespeare's Macbeth (very unlikely)
Actually it can do a great deal of harm. A short, rather extreme
demonstration:
take a perfect random number generator that generates binary
throw away all the output bits that are 1
Is the sequence predictable?
Yes it is (it's all 0). So there is an extreme where removing bits from even
a perfect random number generator weakens the output, so the statement is
not completely correct, although when the tossing is done in certain ways it
will not harm the system.
Also because of the statistics involved, in order to be a tRNG it actually
MUST fail these very tests on occassion, for reference see by proof by
constructing a pRNG that violates the opposing assumption. Besides if a tRNG
generator did output Macbeth, it would do so at such random intervals as to
be unpredictable and the fact that it is in a book does nothing for or
against the security.
Joe
------------------------------
Reply-To: "Francois St-Arnaud" <[EMAIL PROTECTED]>
From: "Francois St-Arnaud" <[EMAIL PROTECTED]>
Subject: Re: Minimal Perfect Hashing
Date: Fri, 20 Apr 2001 20:59:55 GMT
I have misused the term due to some incomplete knowledge on my part and may
have created confusion. The "minimal" and "perfect" aspects of Minimal
Perfect Hashing had caught my eye and served as a starting point in my
investigations to try to find a solution to my problem, not realizing that
what I was looking for was really just a cipher!
Yes, I am trying to encrypt a 48-bit value and not trying to create a hash
table.
I need a function y=f(x) that takes a 48-bit x and returns a 48-bit y. Given
y and f(x), it should not be trivial to find x and x and y should have a
one-to-one relation (only one y for each x and only one x for each y).
I have not yet looked closely at the solutions proposed in this thread, but
I would not be in a position to prove that a candidate algorithm actually
meets my requirements, hence the question in this group.
"Jim Steuert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The term Minimal Perfect Hashing, as in the algorithm of Czech and
Majewski,
> (an amazing algorithm which really works) is for hash table lookup
> purposes, in which one is hashing a large set of values (say 2^48) into a
much
> smaller
> set of contiguous integer values (say 2^20), with no gaps. Are you trying
> to encrypt a 48-bit value, or to create a hash table from a larger set of
> values?
>
>
> Francois St-Arnaud wrote:
>
> > "Anders Thulin" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Francois St-Arnaud wrote:
> > > >
> > > > I'm looking for a simple C algorithm for a function y = f(x) that
would
> > take
> > > > a 48-bit number x and return another 48-bit number y. f should map x
to
> > y in
> > > > a one-to-one fashion. f should be one-way, or at least, it should
not be
> > > > trivial to calculate x knowing y and the algorithm used.
> > >
> > > Your subject says *Minimal*, but that requirement is not repeated in
> > > the body. Is the minimality criterion important?
> >
> > Yes. I neglected to repeat this important criterion in the requirements.
It
> > should be "minimal", meaning that n plaintexts will map to 0..n-1
ciphers
> > with no collisions at all. For my application, n = 2^48, x and y in
> > [0..2^48-1].
> >
> > Regards,
> >
> > Francois St-Arnaud
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Fri, 20 Apr 2001 22:59:37 +0200
"Douglas A. Gwyn" wrote:
>
> It was included on the disks accompanying Applied Cryptography
> under the file name I-HAT.ZIP. For your convenience and possible
> general interest I have appended the documentation to this message.
Thanks. One sees the effects of export regulations. The
AC I bought was without disks.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Fri, 20 Apr 2001 21:02:43 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> How could you know that the keystream used to Xor plaintext is truly
> random?????????
> Truly random is ideal situation. In practice, we measure randomness
> degree. How you measure it????????????
> How could you distinguish between truly random or not??????
> You have to apply statistical tests.
> So I suppose that the keystream used is truly random. That means that
> this keystream was filtred by statistical tests. So I have still the
> ability to know if my input 10100010010110 Xored with my ciphertext
> 100100100100 give me truly random sequence or not.
> The keysteam used is truly random BUT MY OUTPUT IS NOT NECESSARLY TRULY
> RANDOM.
Write properly or don't write at all. I make grammar mistakes and such but
I form my questions a tad better.
if X is a truly random bit then 1 xor X is truly random and so is 0 xor X.
Your question is moot.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Fri, 20 Apr 2001 21:04:09 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Let my ciphertext = c(i)
> Let my choosen plaintext to test = p(i)
> Let ouptut = c(i) Xor p(i).
> Length of ciphertext = n
> I suppose that my keystream is generated by PRNG.
>
> Suppose that c(i) Xor p(i) = 11111111111111101111110111111111 ( (n-2)
> one's and 2 zero's ) for all the length of my ciphertext.
>
> Obvious I have to reject my choosen plaintext.
> Not because it contains (n-2) one's, but because it is quite impossible.
> The probality to obtain this sequence is near 0.
>
> It does not matter if keystream is random or not.
> if (Randomness of PRNG > randomness of "truly random sequence) then my
> rejection is more likely valid if the keystream was truly random
> sequence.
>
> What do you think about that statement?
I think you should read some of the other posters messages.
Random (in the OTP sense) doesn't mean the output looks random. It just
means that predicting that it would happen is not likely.
For example, 100000 zero bits in a row is random if the probability of that
happening is exactly 2^-100000.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Basic AES question
Date: Fri, 20 Apr 2001 13:51:25 -0700
There are certain hedge bets against that. For example there is a maximum
number of rounds of Rijndael/AES before it maps back to itself, and in order
to make use of larger keys you need to increase the number of rounds. Also
there are typically attacks that have a fixed complexity regardless of key
size, the one that comes to mind if RC6 had one at IIRC 2^772 work, making
any use of keys larger than 772-bits worthless. It may also be possible for
a cipher to be constructed such that using a longer key actually introduces
weaknesses, although no way of doing it comes to mind immediately.
In general though, the longer the key the more likely there is to be an
attack that uses less work than bruteforcing the key. However the longer the
key the more possibilities for security exist. With Rijndael the current
state of the art is that nothing better than bruteforce is known for any key
length of those with the AES definition. So if you stick to AES/Rijndael
it's probably a safe assumption.
Joe
"Lou Grinzo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Thanks to Paul and the others for responding.
>
> As best I can tell from the replies, there doesn't seem to
> be a technical reason for limiting keys to those three
> sizes. General crypto theory strongly implies that using
> other key sizes would have the predictable effect on the
> strength of the encryption (longer == stronger), but that
> hasn't been tested and proved to be the case. Correct?
>
>
> Take care,
> Lou
>
>
>
> In article
> <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > [EMAIL PROTECTED] (Lou Grinzo) writes:
> >
> > > I'm just starting to learn about AES, and I was wondering:
> > > Why does the AES standard support only the key sizes of
> > > (I think) 128, 192, and 256 bits? Is it purely to keep
> > > the specification and logistical issues simple?
> >
> > Yes.
> >
> > > Or is there
> > > a technical reason, such as increasing the key size doesn't
> > > make AES any more difficult to attack? (I know that last
> > > one sounds goofy, but in a world where PKI works, almost
> > > anything is possible. <g>)
> >
> > Since the most effective attack known against AES at any key size is
> > brute force, the larger keys are believed to increase the security.
> >
> > Rijndael can be used with block and key sizes that vary in jumps of 32
> > bits between 128 and 256 bits, but it isn't AES unless you use a 128
> > bit block and one of the key sizes you list. Sufficiently confusing?
> > --
> > __ Paul Crowley
> > \/ o\ [EMAIL PROTECTED]
> > /\__/ http://www.cluefactory.org.uk/paul/
> >
------------------------------
From: [EMAIL PROTECTED] (Leonard R. Budney)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: 20 Apr 2001 17:07:11 -0400
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> ...in order to be a tRNG it actually MUST fail these very tests on
> occassion, for reference see by proof by constructing a pRNG that
> violates the opposing assumption.
That proof doesn't cut it. It proves that a RNG may pass any specified
set of statistical tests without being a tRNG. It doesn't prove that a
RNG which passes all the tests is NOT a tRNG.
The proof is quite simple, though. For a tRNG, all sequences are equally
likely. Therefore, sequences of length N which fail the specified tests
will happen sometimes. It also seems clear that "sometimes" -> "never"
as N -> infinity, but (and my ignorance is probably showing) I'm not sure
how to prove it.
Len.
--
Frugal Tip #47:
Instead of turning up the heat at night, sleep with an extra blanket.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: First cipher
Date: Fri, 20 Apr 2001 21:07:11 GMT
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > > "M.S. Bob" wrote:
> > > >
> > > > [EMAIL PROTECTED] wrote:
> > > > >
> > > > > "M.S. Bob" wrote:
> > > > > >
> > > > > > [EMAIL PROTECTED] wrote:
> > > >
> > > > As his says in his self-study course, there is no one good text on
> > > > cryptanalysis of modern ciphers.
> > >
> > > This is somewhat sad, given that there are textbooks out
> > > there on some extremely complicated scientific/mathematical analysis
> > > problems.
> >
> > Not really. Analysis is just one of those subjects that never ends.
Find
> > one good text that answers all questions about god? Or about how the
human
> > brain works, or how to factor large integers, or how to remove money
from
> > society or how to make good tv programs?
> >
> > Answers to these questions will vary over time....
> >
> > Tom
>
> You can teach an electrical engineering student the basics of circuit
> analysis
> by analyzing simpler problems and progressing to more complex problems.
> Hopefully
> by the end of the curriculum, the fire will light and the student will
> be able
> to approach a wide range of analysis problems and design circuits on
> his/her own.
> In spite of the best instruction, some students will never be able to
> move
> from analysis to design BUT there is a progressive method of teaching an
> approach to what are sometimes very complex design or analysis problems.
> I'd like to think that the crypto field, like any scientic endeavor, has
> a similar method of passing along its cumulative knowledge to serious
> students, and not just "go do a hodge-podge
> self study course and come back when you've taught yourself everything".
Given say an hour I could teach you how to perform differential
cryptanalysis (which is basically the only attack I really get). But that
takes time and money. You can learn diff (etc...) cryptanalysis in school,
just depends on what school.
The bigger problem is that you may resist 100s of attacks but someone may
find another attack. Saying something is secure means it resists known
attacks only. Nothing can be provably secure except the OTP.
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
