Cryptography-Digest Digest #891, Volume #8 Tue, 12 Jan 99 13:13:03 EST
Contents:
Re: Random numbers in C: Some suggestions. (Charles Bond)
Re: a^x mod n question (Mok-Kong Shen)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: Practical True Random Number Generator ("Tony T. Warnock")
Re: Help: a logical difficulty ("Tony T. Warnock")
Re: On the Generation of Pseudo-OTP ("Tony T. Warnock")
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: Practical True Random Number Generator (R. Knauer)
Re: Contents of server gated certificates (Paul Rubin)
Re: Public key source code (Paul Rubin)
Re: On the Generation of Pseudo-OTP (R. Knauer)
----------------------------------------------------------------------------
From: Charles Bond <[EMAIL PROTECTED]>
Crossposted-To: sci.stat.math,sci.math,sci.math.num-analysis,sci.physics
Subject: Re: Random numbers in C: Some suggestions.
Date: Tue, 12 Jan 1999 07:13:47 -0800
Reply-To: [EMAIL PROTECTED]
Thanks for the post. I want to comment on the SWB routine. I've been
using
a similar routine in high speed simulations for years. Small departures
from
statistically correct randomness are not a problem for my application,
but
speed is. I believe Knuth briefly discussed the method with guarded
approval -- constrained by the concern that there was no real theory
behind it. Do you know if any theoretical work has been done since
Knuth's
book to justify SWB?
George Marsaglia wrote:
> This posting ends with 17 lines of
> C code that provide eight different
> in-line random number generators, six for
> random 32-bit integers and two for uniform
> reals in (0,1) and (-1,1).
> Comments are interspersed with that
> code. Various combinations of the six in-line
> integer generators may put in C expressions to
> provide a wide variety of very fast, long period,
> well-tested RNG's. I invite comments, feedback,
> verifications and timings.
>
> First, there is narrative giving background
> for this posting; you may want to skip it.
>
> Narrative:
>
> Having had experience in producing and
> testing for randomness in computers,
> I am frequently asked to suggest good
> random number generators (RNG's), test
> RNG's, or comment on existing RNG's. Many
> recent queries have been in two areas:
> (1) requests for implementations in C and
> (2) comments on generators with immense periods,
> particularly the Mersenne Twister.
>
> This posting is mainly for category (1),
> for which I suggest a set of C implementations
> of RNG's I have developed. C implementations
> of my DIEHARD battery of tests will be
> discussed elsewhere, and Narasimhan's GUI
> version is expected to be released soon.
>
> For (2), I merely repeat what I have said
> in response to various queries: the Mersenne
> Twister looks good, but it seems to be essentially
> a lagged Fibonacci RNG using the exclusive-or
> (xor) operation, and experience has shown that
> lagged Fibonacci generators using xor provide
> unsatisfactory 'randomness' unless the lags are
> very long, and even for those with very long lags,
> (and even for those using + or - rather than xor),
> many people (I among them) are inclined to be
> cautious about sequences based on such a simple
> operation as: each new integer is the xor, (or sum,
> or difference), of two earlier ones. To be sure,
> the resulting integers can be "twisted", but not,
> I think, as simply or as safely as combining, say
> by addition, with members of a sequence from a
> (shorter period) generator that has itself passed
> extensive tests of randomness.
>
> I also reply that it does not take an immense
> program (as, for example, in posted listings
> of Twister) to produce a more satisfactory RNG
> with an immense period, and give this example,
> on which I will expand below: Inclusion of
>
> #define SWB ( t[c+237]=(x=t[c+15])-(y=t[++c]+(x<y)) )
>
> together with suitably initialized seeds in
>
> static unsigned long x,y,t[256]; unsigned char c;
>
> will allow you to put the string SWB in any C
> expression and it will provide, in about 100 nanosecs,
> a 32-bit random integer with period 2^7578. (Here
> and below, ^ means exponent, except in C expressions,
> where it means xor (exclusive-or).
>
> Now for the (2) part, in which I suggest a number
> of C implementations and invite comment and feedback.
> Most of these were previously developed and tested
> via Fortran versions. I list eight RNG's, each of
> them by means of C's powerful #define device. This
> provides fast, compact implementation, allows
> insertion of the required random variable directly
> into an expression, and, finally, provides a good
> selection of RNG's for use individually or in
> combination. The latter makes it possible to
> further confirm what empirical results suggest:
> combining two or more RNG's provides better,
> (or no worse) randomness, and for encryption enthusiasts:
> combination generators are harder to "crack".
>
> For those wishing to try these eight RNG's:
>
> At the top of your C program, include these
> definitions and the static variables that follow.
> Everything past this line is either C code or comment.
> --------------------------------------------------
>
> #define UL unsigned long
> #define znew ((z=36969*(z&65535)+(z>>16))<<16)
> #define wnew ((w=18000*(w&65535)+(w>>16))&65535)
> #define MWC (znew+wnew)
> #define SHR3 (jsr=(jsr=(jsr=jsr^(jsr<<17))^(jsr>>13))^(jsr<<5))
> #define CONG (jcong=69069*jcong+1234567)
> #define KISS ((MWC^CONG)+SHR3)
> #define LFIB4 (t[c]=t[c]+t[c+58]+t[c+119]+t[++c+178])
> #define SWB (t[c+237]=(x=t[c+15])-(y=t[++c]+(x<y)))
> #define UNI (KISS*2.328306e-10)
> #define VNI ((long) KISS)*4.656613e-10
> /* Global static variables: */
> static UL z=362436069, w=521288629, jsr=123456789, jcong=380116160;
> static UL t[256];
> static UL x=0,y=0; static unsigned char c=0;
>
> /* Random seeds must be used to reset z,w,jsr,jcong and
> the table t[256] Here is an example procedure, using KISS: */
>
> void settable(UL i1,UL i2,UL i3,UL i4)
> { int i; z=i1;w=i2,jsr=i3; jcong=i4;
> for(i=0;i<256;i++) t[i]=KISS; }
>
> /* End of C code; Only comments follow. Stick the above
> 17 lines in your simulation programs, initialize the table,
> and have a variety of promising RNG's at your disposal. */
>
> /* You may want use more complicated names for the
> above simple 1-letter variable names: z,w,x,y,t,c,
> to avoid clashing with favorites in your code. */
>
> /* Any one of KISS, MWC, LFIB4, SWB, SHR3, or CONG
> can be used in an expression to provide a random
> 32-bit integer, and UNI in an expression will
> provide a random uniform in (01), or VNI in (-1,1).
> For example, for int i, float v; i=(MWC>>24); will
> provide a random byte, while v=4.+3.*UNI; will
> provide a uniform v in the interval 4. to 7.
> For the super cautious, (KISS+SWB) in an expression
> would provide a random 32-bit integer from
> a sequence with period > 2^7700, and would only
> add some 300 nanoseconds to the computing
> time for that expression. */
>
> /* The KISS generator, (Keep It Simple Stupid), is
> designed to combine the two multiply-with-carry
> generators in MWC with the 3-shift register SHR3
> and the congruential generator CONG, using
> addition and exclusive-or. Period about 2^123. It
> is one of my favorite generators. */
>
> /* The MWC generator concatenates two 16-bit
> multiply-with-carry generators, x(n)=36969x(n-1)+carry,
> y(n)=18000y(n-1)+carry mod 2^16, has period about
> 2^60 and seems to pass all tests of randomness. A favorite
> stand-alone generator---faster than KISS, which contains it.*/
>
> /* SHR3 is a 3-shift-register generator with
> period 2^32-1. It uses
> y(n)=y(n-1)(I+L^17)(I+R^13)(I+L^5), with the
> y's viewed as binary vectors, L the 32x32
> binary matrix that shifts a vector left 1, and
> R its transpose. SHR3 seems to pass all except
> the binary rank test, since 32 successive
> values, as binary vectors, must be linearly
> independent, while 32 successive truly random
> 32-bit integers, viewed as binary vectors, will
> be linearly independent only about 29% of the time. */
>
> /* CONG is a congruential generator with the
> widely used 69069 as multiplier:
> x(n)=69069x(n-1)+1234567. It has period 2^32.
> The leading half of its 32 bits seem to pass
> all tests, but bits in the last half are too
> regular. */
>
> /* LFIB4 is an extension of the class that I have
> previously defined as lagged Fibonacci
> generators: x(n)=x(n-r) op x(n-s), with the x's
> in a finite set over which there is a binary
> operation op, such as +,- on integers mod 2^32,
> * on odd such integers, exclusive-or (xor) on
> binary vectors. Except for those using
> multiplication, lagged Fibonacci generators
> fail various tests of randomness, unless the
> lags are very long. To see if more than two
> lags would serve to overcome the problems of 2-
> lag generators using +,- or xor, I have
> developed the 4-lag generator LFIB4:
> x(n)=x(n-256)+x(n-179)+x(n-119)+x(n-55) mod 2^32.
> Its period is 2^31*(2^256-1), about 2^287, and
> it seems to pass all tests---in particular,
> those of the kind for which 2-lag generators
> using +,-,xor seem to fail. For even more
> confidence in its suitability, LFIB4 can be
> combined with KISS, with a resulting period of
> about 2^410: just use (KISS+LFIB4) in any C
> expression. */
>
> /* SWB is a subtract-with-borrow generator that I
> developed to give a simple method for producing
> extremely long periods:
> x(n)=x(n-222)-x(n-237)-borrow mod 2^32.
> The 'borrow' is 0 unless set to 1 if computing
> x(n-1) caused overflow in 32-bit integer
> arithmetic. This generator has a very long
> period, 2^7098(2^480-1), about 2^7578. It seems
> to pass all tests of randomness, but,
> suspicious of a generator so simple and fast
> (62 nanosecs at 300MHz), I would suggest
> combining SWB with KISS, MWC, SHR3, or CONG. */
>
> /* Finally, because many simulations call for
> uniform random variables in 0<v<1 or -1<v<1, I
> use #define statements that permit inclusion of
> such variates directly in expressions: using
> UNI will provide a uniform random real (float)
> in (0,1), while VNI will provide one in (-1,1). */
>
> /* All of these: MWC, SHR3, CONG, KISS, LFIB4,
> SWB, UNI and VNI, permit direct insertion of
> the desired random quantity into an expression,
> avoiding the time and space costs of a function
> call. I call these in-line-define functions.
> To use them, static variables z,w,jsr and
> jcong should be assigned seed values other than
> their initial values. If LFIB4 or SWB are
> used, the static table t[256] must be
> initialized. A sample procedure follows. */
>
> /* A note on timing: It is difficult to provide
> exact time costs for inclusion of one of these
> in-line-define functions in an expression.
> Times may differ widely for different
> compilers, as the C operations may be deeply
> nested and tricky. I suggest these rough
> comparisons, based on averaging ten runs of a
> routine that is essentially a long loop:
> for(i=1;i<10000000;i++) L=KISS; then with KISS
> replaced with SHR3, CONG,... or KISS+SWB, etc.
> The times on my home PC, a Pentium 300MHz, in
> nanoseconds: LFIB4=64; CONG=90; SWB=100;
> SHR3=110; KISS=209; KISS+LFIB4=252; KISS+SWB=310. */
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: a^x mod n question
Date: Tue, 12 Jan 1999 15:52:49 +0100
Rx Video wrote:
>
> In his book B.Schneider shows how to efficiently calculate a^x mod n by
> splitting the whole statement into multiplications (modulo) of squares
> of (a*a mod n).
>
> a^x mod n = a*a*...*a mod n=(((a^2 mod n)^2 mod n)...^2) mod n
>
> I wanted to ask why not do this in the following manner.
>
> a=k*n+r, r being the rest
>
> a^x mod n=((a mod n)^x) mod n - calculate a mod n first, and then raise
> it to power x and calculate modulo from this result. It gives the same
> result.
> There are probably some good reasons for doing things the way
> B.Schneider described, still, I would like to know why is it that way.
I believe that 'implicit' in the formulation given in the beginning
is the assumption that a < n. First of all, the method is certainly
correct also for a > n. Second, in doing modular arithmetics one
usually (almost invariablly) takes the first possible opportunity
to reduce intermediate quantities modulo n, if n is large.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 15:07:57 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 12 Jan 1999 02:50:35 -0800, John H Meyers <[EMAIL PROTECTED]>
wrote:
>This brings up the question of whether some set of selected offsets
>into this "pad" (XOR'ing all pads together) can constitute an effective
>key and pad
That is the central question regarding the use of such bitstream
generators as digit expansions. The question is how to remove
correlation.
FIPS 140-1 (http://csrc.ncsl.nist.gov/fips/fips1401.htm) discusses
so-called "strong mixing" which is supposed to remove correlation from
bitstreams, but some people here have criticized such methods in the
past based on the fact that these techniques are algorithmic and that
is sufficient to introduce correlation itself.
If you or anyone else can some up with a proveably secure algorithmic
method for removing correlation, please let us know.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 15:42:08 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 12 Jan 1999 12:26:32 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>So there is not of much practical value to insist on perfect security,
>on obtaining (ideal) OTP.
There is practical value in using the "perfect OTP" (as you call it)
as a standard, just as there is practical value in using a Perfect
Circle as a standard.
>And one can, for example, consider the
>utility of the non-perfect 'intended approximation to an ideal OTP'.
Yes, most definitely.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 16:28:05 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 12 Jan 1999 12:54:42 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>I only employ mathematics to illustrate the type of 'rigor'.
>On the other hand, all rigorous proofs are ultimately reduced
>to proofs in mathematical logic. And mathematical logic is
>a subfield of mathematics.
here are a class of problems in pure mathematics that are undecideable
using "mathematical logic" (formal axiomatic systems). One of them is
the Godel construction, such as "This statement is false". Another is
the set of all non-computable numbers - if they are non-computable,
then how do you decide what they are? A third are equations like
Chaitin's exponential diophantine equation.
Formal mathematics is not as "rigorous" as once believed at the turn
of the century.
>But if that phrase 'If the .... random' cannot be true in the real
>world,
But it can be - radioactive decay is 100% random.
>then your assertion has no practical meaning. It's like
>'If there are plants on the moon'.
Quantum Mechanics is full of random processes - a particle in free
space, spontaneous emission (of which radioactive decay is one
example), etc.
You don't really have to look very far in QM to find random pyhsical
processes all over the place. And we mean TRUE random in the sense
that they are completely unpredictable in principle and in practice,
because they are composed of an equiprobable superposition of all
possible states, and therefore any one of them can occur with no way
to know ahead of time which one it is going to be.
That's as random as it gets.
>So long that you accept 'non-perfectness' (through your 'arbitrary
>level of precision') everything is o.k. You verify that with some
>tests and these give you confidence level of whether a given
>sequence from radioactive source satisfy certain advertised merits.
>But so can appropriately done 'intended approximation to an ideal OTP'
>be subject to such tests. If the tests happen to be o.k., these
>can be used in the practice.
The only way you can know for sure that your bitstream is even close
to truly ramdom is to look at the generator. Therefore you need some
method to analyze each proposed algorithmic generator on a case by
case basis to decide just how close to random the output is.
If you can provide such methods, formal or experimental, for
characterizating specific algorithmic generators, please let us know.
But remember that you cannot apply the criteria to the output streams
per se - the criteria must be applied to the algorithm itself.
>By hardware noises I mean noises (randomness) from physical processes.
>If you exclude these, where do you obtain your 'TRNG'?
Radioactive decay is usually not considered "hardware noise".
>This is only a 'belief' and hence subjective. I get the impression
>from the amount of works people have expended in trying to remove
>bias from hardware noises. It's like trusting a well-sold household
>device is o.k. One may err, of course, with such subjective
>(non-rational) belief.
Removing bias from bitstreams can be done reliably with algorithms,
such as Knuth's famous one. See FIPS 140-1 and Schneier.
Supposedly it is correlation that is the difficult thing to remove
algorithmically from bitstreams.
>Hardware noise may indeed be the best source in the practical sense.
What do you mean by the term "hardware noise"?
>But that anyway doesn't preclude 'intended approximation to an ideal
>OPT' from being, say, the second best source and thus have utility in
>practice because of cost advantages, etc.
I agree that such sources should be considered. But I also would
insist that there be some kind of certification that such sources are
secure to some level, otherwise why use them?
In my estimation, the trick is to find a way to remove all correlation
that is inherent in these sources. Using algorithmic means to remove
correlation is suspect because algorithms introduce their own form of
correlation into bitstreams - so the expert cryptographers around here
tell us (and I have no reason to doubt their purported wisdom).
If Strong Mixing (FIPS 140-1) is the proper method for removing
correlation, then I wonder if anyone has proven the level of security
for such methods.
>I indicated certain viable techniques in the original article.
>Whether they are good have ultimately to be verified by experiment.
>But I thought that there is certainly value to know what merits the
>individual techniques (or additional proposals) may possibly have
>according to experts' evaluations before doing extensive experiments,
>which could be expensive without guidance of experts' opinions.
>That's why I initiated the the present thread.
I would like to see you give reasons why you believe those techniques
are secure, even if they are not "perfectly secure".
Until you do, or appeal to someone else who can, it just looks like
you grabbed a few methods out of a hat and slapped them together. You,
I and all the rest of the crypto world, expert and amateur alike, know
that such a practice is extemely dangerous. Some of the most complex
algorithms ever invented, even those concocted by Giants in the crypto
field, have turned out to be vulnerable to simple attacks. Schneier
has any number of instances of such in his main book - and we are
talking about Big Giants too.
>Covered by what is said about 'approximation' above.
I do not believe you can hide behind this euphemism "approximation"
much longer. At some point you are going to have to come clean and
show us (or get someone to show us) just how much of an
"approximation" your proposed methods are.
By attaching your proposals to a loaded term like "pseudo-OTP", you
have tried to characterize them as "approximations" to the OTP, with
the implication that they are only "slightly" less perfect than the
OTP. To bolster that, you try to point out that even TRNGs are not
perfect, therefore it is unfair to claim that your proposals are no
good because they are imperfect "approximations".
But all that is disengenuous, since it has been argued by expert
cryptographers that all stream ciphers except the OTP are very poor in
terms of security. If you claim that your stream ciphers are very good
"approximations" to the OTP, then you will have to provide reasons for
us to accept that claim.
Handwaving about how they are "approximations to the OTP" is not good
enough, because they are likely very poor approximations, so poor as
to be totally unusable in crypto - based on the opinions of experts in
the field.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Practical True Random Number Generator
Date: Tue, 12 Jan 1999 08:25:32 -0700
Reply-To: [EMAIL PROTECTED]
Nicko van Someren wrote:
> "R. Knauer" wrote:
>
> > On Mon, 11 Jan 1999 16:48:45 -0500, Nicko van Someren
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Another method is to time the two intervals between three decay
> > >events. If the first interval is longer than the second then emit a
> > >zero and if the second is longer than the first emit a one. If your timer
> > >says that they are the same do it again. This has as little bias as
> > >you can get.
> >
> > That is the preferred method because it cancels any slowly varying
> > systematic errors, such as clock errors or detector errors - as long
> > as the the interval lengths are shorter in duration than the time
> > constants for the errors.
> >
> > It was my understanding that you needed to measure each interval
> > independently, that is, you need to time the two intervals between 4
> > decay events, not 3.
>
> No. This is not necessary. In radioactive decay the decay events
> are independant (give or take some cascade effect which is extreemly
> short lived). In fact you don't even need three events, you can
> say to yourself "Now" and then time until the first event and then
> time until the second event, or even you can just pick a second
> random starting point and time until the next event. Irrespective
> of the starting time the probability distribution for the time until the
> next event is the same. (The astute reader will see that this means
> the distribution is an exponential curve).
>
> Nicko
It's not the decay event that causes the problem; it's the detector.
Tony
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Help: a logical difficulty
Date: Tue, 12 Jan 1999 08:23:11 -0700
Reply-To: [EMAIL PROTECTED]
Darren New wrote:
> > I would side with Mike on this. Computer scientists should serve the
> > wider community, not dictate to them. If this make their sorting
> > algorithms a bit harder, so be it.
>
> Amusingly enough, it became obvious when the local Blockbuster video
> store switched to computerizing their videos for sale (as well as the
> rented ones), as movies like "The 4th Protocol" moved from the "F's" to
> the beginning of the section (as in ASCII). Bleh.
It's worse in Spanish, Coahuila comes before Chihuahua. It is the
responsibility of the program to get it right, not the users. Violation of
this principle contributes the distrust of computers.
As an aside, I once wrote a program to sort English transliterations of
Russian names according to the Russian collating sequence. There was an
essential ambiguity in that the letter "TS" and the sequence of letters
"T""S" both occur in Russian names.
Tony
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 08:29:25 -0700
Reply-To: [EMAIL PROTECTED]
Peter Wright describes another method of breaking a OTP. MI6 would just break into a
spy's
flat and photograph the pad. Details in "Spycatcher."
Tony
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 16:31:08 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 12 Jan 1999 07:50:08 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> >The preceeding statement is sense-free.
>Please distinguish between an atack upon your self and an attack upon your statements.
>The claim "you are stupid" is an ad hominem attack. The claim "your statement is
>wrong"
>is not.
I think most people would consider the term "sense-free" as an insult
to them personally.
If a statement is wrong, say so and make your case. Using bigotted
terms like "sense-free" lends nothing of merit to the discussion.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Practical True Random Number Generator
Date: Tue, 12 Jan 1999 17:54:40 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 12 Jan 1999 15:16:51 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> A simple fix comes to mind. If we write your original loop as
>> (disregarding the case of t1 = t2 for simplicity)
>>
>> while(true)
>> {
>> get(t1, t2); // get the intervals t1 and t2 between detected
>> fissions
>> if(t1 > t2)
>> output(0);
>> else
>> output(1);
>> }
>>
>> then we could modify the loop to invert the rule at every reading:
>>
>> while(true)
>> {
>> get(t1, t2);
>> if(t1 > t2)
>> output(0);
>> else
>> output(1);
>> get(t1, t2);
>> if(t1 < t2)
>> output(0);
>> else
>> output(1);
>> }
>
>I don't see why the modified version is better than the original.
You are introducing symmetry into the measurements, and now the
direction of time does not matter - so systematic errors such as the
decay of the radioactive source over time are cancelled and cannot
cause bias in the bitstream.
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Contents of server gated certificates
Date: Tue, 12 Jan 1999 17:53:01 GMT
In article <01be3e49$712f1bc0$[EMAIL PROTECTED]>,
Dick Perkins <[EMAIL PROTECTED]> wrote:
>I have been unable to discover the contents of server gated certificates
>(and step up certificates if they're not the same thing). Is there a
>specification for them anywhere? If not, can anyone tell me what they
>contain or how to extract one from a browser. I'm particularly interested
>in whether there's any cryptography used to ensure that such a certificate
>is authentic.
Someone posted a description a month or two ago of Verisign Global ID's.
They just had one field inside that was different from ordinary
certificates. It seems obvious that they have to be signed by CA's
(i.e. Verisign) the same way that ordinary certificates do. What
I don't know is whether there's some special root certificate inside
the browser that's needed to validate them, or if you can import
new roots the usual way.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Public key source code
Date: Tue, 12 Jan 1999 17:54:29 GMT
In article <[EMAIL PROTECTED]>,
Ericsson User <[EMAIL PROTECTED]> wrote:
>Does anyone know of a cryptographic public/private key algorithm source
>code which is free and can be implemented in commercial application. I
>have already looked at pgp50i but it is so huge.
Try Peter Guttmann's cryptlib. It's kind of complicated, but gives
every algorithm you could want. You should be able to find it
quickly with a web search.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 16:37:42 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 12 Jan 1999 07:55:06 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Such an attack is one method of showing weakness. It is not the only method. We do
>not
>need to attack a system using weak keys to prove the keys are weak. You have been
>stating that text-based keys are weak.
Not I - it is the experts who have been stating such things. I am the
one who would like to find methods of strengthing text ciphers to a
level that is practical enough to be useable. I believe that if
someone can come up with a certifiable method of decorrelation, we
might just have it, namely a crypto-grade stream cipher that can be
used without the headaches of key management that the OTP system
suffers from. I would include other sources of input from the Internet
such as sound recordings too.
>This conclusion is undoubtedly based on analytic
>considerations rather than experimental ones.
>In the instance of the Russian cipher the key generation process could not have
>produced
>fully independent key elements (this from human factors considerations).
BTW, has it ever been determined just how poor such methods are? The
reason I ask is that very method is used by PGP to generate the main
key.
>However, it may
>have produced keys good enough to make an attack infeasible without making it
>impossible.
I fully agree with everything you say here - so where is the point of
debate?
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
