Cryptography-Digest Digest #925, Volume #8 Mon, 18 Jan 99 10:13:04 EST
Contents:
Re: Random numbers in C: Some suggestions. (Eric Backus)
Re: Trying to find simple, yet effective implementation of crypto... (Lincoln Yeoh)
A further descent in Nullism (wtshaw)
Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) (Daniel James)
Re: Practical True Random Number Generator
long numbers math - how to ? (Rx Video)
Re: Metaphysics Of Randomness (R. Knauer)
Re: Practical True Random Number Generator (R. Knauer)
Re: Practical True Random Number Generator (R. Knauer)
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: Metaphysics Of Randomness (R. Knauer)
Re: Help: a logical difficulty (Gus Gassmann)
----------------------------------------------------------------------------
From: Eric Backus <[EMAIL PROTECTED]>
Crossposted-To: sci.stat.math,sci.math,sci.math.num-analysis,sci.physics
Subject: Re: Random numbers in C: Some suggestions.
Date: 13 Jan 1999 12:21:37 -0800
George Marsaglia <[EMAIL PROTECTED]> writes:
> 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.
> #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; }
Thank you for providing this extremely useful code. (I'd like to make
use of it, however I see no copyright notice, can I assume you are
making it free for anyone to use?)
I have a small problem with the definition of LFIB4 and SWB. In an
attempt to make these a single line of C code, they both use "++c" in
the same expression as they use "c". A C compiler is free to
rearrange the order in which it calculates the intermediate terms of
these expressions, so the expressions can produce different results
depending on the compiler.
I might propose alternate expressions using the "," operator in
order to remove any ambiguity. With a good compiler, these
expressions probably won't be any slower than your original ones:
#define LFIB4_ALT (t[c]=t[c]+t[c+58]+t[c+119]+t[c+179],t[c++])
#define SWB_ALT (t[c+237]=(x=t[c+15])-(y=t[c+1]+(x<y)),t[c++ +237])
However, these are uglier and harder to understand than your original
expressions, and of course I might have made a mistake in interpreting
where the c++ should go. Any comments?
--
Eric Backus <[EMAIL PROTECTED]>
http://labejb.lsid.hp.com/
(425) 335-2495
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Trying to find simple, yet effective implementation of crypto...
Date: Mon, 18 Jan 1999 09:44:20 GMT
Reply-To: [EMAIL PROTECTED]
I use SSL and the SSLeay package
http://www.psy.uq.edu.au:8080/~ftp/Crypto/
There are various clients and servers which work with the SSLeay package.
Right now I'm using SSLeay and SSLWrap as a quick and dirty solution to
"wrap" a normal nonssl webserver (MS IIS on NT 4.0) in 128 bit SSL.
http://www.rickk.com/sslwrap/
The fortified Netscape browser (http://www.fortify.net/) smakes an SSL
(HTTPS) connection to SSLWrap which unwraps it and makes a plain connection
to the real server. Quite simple.
Source is available for both SSLeay and SSLWrap, but I haven't had time nor
expertise to go through the code with a fine toothed comb :).
128 bit crypto. Ever wondered what the US export laws are really for?
Cheerio,
Link.
On Sun, 17 Jan 1999 10:15:35 -0600, "Tim Mavers" <[EMAIL PROTECTED]>
wrote:
>I am trying to implement a system where my program can send messages to a
>server (also written by me) who then can reply (or send messages) to another
>client (my program as well). The messages have to be encrypted. The
>messages basically contain a meta-protocol that the programs use to
>communicate with each other (the server parses the messages and determines
>what to do). Since I don't want anyone knowing my protocol (it's a very
>basic one, but if known by all, malicious acts can be done).
>
>Is there a basic crypto principle I can use for this? I have read through
>the sci.crypt FAQ and the first couple chapters of Bruce Scheiners book
>(very eye-opening), but am still confused about what the best method to
>take.
>
> The server must decrypt the packets on-the-fly (very quickly) and then
>re-encrypt them to go to someone else.
>Each client program doesn't need to have it's own "public" key as everything
>can be encrypted the same (is this a flaw?)
>
>Can anyone help?
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: A further descent in Nullism
Date: Mon, 18 Jan 1999 01:48:39 -0600
As some of you may recall, I implemented a cipher called Rimfire, which
converts base 100 to base 22, keyboard input: 22 character output,
characters drawn from a possible 26. An an option, the four unused
characters can be inserted as nulls. An attacker must decide which are
the nulls, as well as the order of the other 22 characters, and also solve
a digit transposition scheme, 8/12/16/20 or 24, all problems at the same
time.
As this project goes downhill, at least numerically speaking, enter base
18, also convenient for this sort of thing. The same rules generally
apply, but with 18 characters of 26 used, leaving 8 for optional null
use. Two digit handy transposition sizes are implemented, 10 and 20
digits. Oh, the name....Balsas10/20.
Surely you wonder where on earth I got such a name. Well, as a matter of
fact, that is just where I got it, at about 100 W and 22 N, for the two
bases involved. Considering that given two different bases, you have a
maximum of 4 or 8 possibilities that some locally named town, river, etc.,
will suggest a name. In this case, Balsas is the name of a town and a
river in southern Mexico. Don't blame me entirely, I did not choose where
people settled, and I am not responsible for useful, numerical
geopositions.
Where do I go from here with this sinking into nullification of
ciphertext, same direction I guess. Speaking of guessing, try to figure
out what comes next. As the base goes down, so does the expansion of
ciphertext vs. plaintext, nulls make it worse. At some point, what you
get is simply not worth it. However, if security is your goal, as long as
some obscure method is used for placing nulls, the greater percentage of
them, the better.
On a character level, the use of nulls is certainly close to Rivest's
introduction of noise as in the winnowing scheme. By the dictionary:
winnow 5. To examine closely in order to separate the good from the bad;
sift. 6.a. To separate or get rid of (an undesirable part); eliminate. b.
To sort or select (a desirable part); extract.
And, it does not help if their are several extra choices for 26
character-ciphers for confident professional hackers to face. And, this
type of ciphertext is so chainable as well.
Between Rimfire and Balsas, there are few differences, mainly cosmetic, so
that the keys look right on the screen. In a classy implementation, it is
down to pixel counting to do it right. It would be nice if a few variable
would allow several low bases to be implemented together, but there is
more to it than that. So, it's 22, 18...going down...at least two more
stops below.
--
Crypto with attitude....
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Java speed vs 'C' (was Re: New Twofish Source Code Available)
Date: Mon, 18 Jan 1999 11:40:31 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Mr. Tines wrote:
> It really depends on the cypher - here are some results I
> bashed out this afternoon.
>
Interesting - I'd have expected Java to fare much worse against
optimized code like this.
Some trials I carried out some time ago (between Microsoft's Visual J++
V1.0 and Visual C++ (I think V4.2)) suggested that C++ could be
expected to be around five times faster than Java (maybe that wasn't
JIT compiled, though??).
Cheers,
Daniel James
Daniel at sonadata.demon.co.uk
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Practical True Random Number Generator
Date: Wed, 13 Jan 1999 12:07:21 +0100
On Wed, 13 Jan 1999, Mok-Kong Shen wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Mok-Kong Shen wrote:
> > >
> > > R. Knauer wrote:
> > >
> > > > >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.
> > >
> > > Sorry, being not a physicist, I find it difficult to understand
> > > the 'direction of time'. Isn't it that time is uni-directional?
> > > Or could you refer to literature on perhaps the reversal of the
> > > direction of time? Thanks in advance.
> > >
> >
> > Think of radioactive decay: The probability to get a count within a
> > fixed time - let's call it t1 - becomes smaller because of the decay.
> > Because of that the probability of 't2 < t1' is smaller than that of
> > 't1 < t2' - this is the bias he talked about.
> >
> > Now write the counts down on a tape. You may move along this tape either
> > in one or in the other direction. If you are moving in the same
> > direction as the time you'll get more 't1 < t2' while when moving in the
> > opposite direction you'll get more 't2 < t1', so by changing the
> > direction of time (or by changing the direction of your movement:)
> > you'll change the number of 0es and 1es, so your results are dependent
> > on the 'direction of time'.
> > Since time is unidirectional in the world as we can see it this causes
> > the bias.
> >
> > BTW: Most physical processes are independent of time, only entropy in a
> > closed system is always growing.
> > Is our world based on the movement towards chaos?
>
> I understand now that the original sentence means that due to decay
> the remaining material becomes less. But that, I presume, gives
> rise to a solution of a differential equation that becomes smaller,
> involving an exponential term. But in the present context of
> measurements for two successive time intervals, how much is this
> effect (from the exponential term) compared to the measurement errors
> of the apparatus, including also the error of the time signal?
> If the former is very small compared to the latter (I don't know),
> then we don't need to consider it in practice. Would you say something
> to my point? Thanks.
Of course this depends on the halflife of the radionuclide used, but
generally it changes the statistics and even if the apparatus is not very
exact statistics will change.
May p be the probability to get a count within time interval [0,t1] and
using an isotope with halflife T the probability to get a count within a
time interval [t1,2t1] is
p * 0.5^(t1/T)
The probability to get 't1>t2' would be 0.5 - (0.5^(t1/T)), the
probability to get 't1<t2' becomes 0.5 + (0.5^(t1/T)).
Since your source decays the effect becomes larger and larger and this way
the quality of the TRNG becomes worse and worse.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Rx Video <[EMAIL PROTECTED]>
Subject: long numbers math - how to ?
Date: Mon, 18 Jan 1999 08:08:54 -0500
Hello,
I'm looking for some information on how to implement the long numbers
calculations. I have some ideas of my own, but I'm sure there are some
better solutions. If anybody knows of some articles on the subject, or
has tried to do it, please, let me know. I'm looking for conceptual
(theoretical) solutions.
Sincerely yours,
Martin
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Mon, 18 Jan 1999 13:55:52 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 17 Jan 1999 07:02:48 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>There are also limitations to this point of view.
>For example: Given a truly random bit generator,
>inevitably *some* finite bit sequences are more
>highly ordered (in the Chaitin sense) than others,
>but there is no more "reason" behind them than for
>the others.
And they are just as random as any other sequence that is output from
a TRNG. IOW, the sequence 111...1 is just as random as any other
sequence of that length. The fact that it is nearly impossible to
realize for sufficiently large N does not change the fact that it is a
random number in terms of the definition of a crypto-grade random
number produced by a TRNG.
>While the "laws of nature" appear to
>most humans to be highly nonrandom, keep in mind
>that evolution has imposed upon us highly selective
>sensory/perceptual/conceptual filters, so our
>attention is naturally focussed on the orderly
>portions of nature.
Observing politics in the last few decades has changed all that. Now
we have learned to expect the random on an everyday basis.
>Probably that has something
>to do with the difficulty we have in nailing down
>the notion of "randomness".
Nailing down the notion of randomness is dependent on the field of
study. Compare the notion of randomness between simulation and crypto.
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Practical True Random Number Generator
Date: Mon, 18 Jan 1999 14:05:16 GMT
Reply-To: [EMAIL PROTECTED]
On 14 Jan 1999 11:30:15 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>I've gotten several independent
>recommendations for Gelman, et al. (1995) _Bayesian Data Analysis_,
>published by Chapman and Hall.
Amazon.com says that "The Publisher Is Out Of Stock".
>In terms of literature relevant to Bayesian methods of cryptanalysis --
>well, I probably *could* write such a textbook, and I might be able
>to see three copies to my IMMEDIATE circle of friends, and my mother
>might buy one if she could find a magnet strong enough to hold it
>onto the refrigerator.
It would probably be out of stock before any of that happened.
>You see the problem; there's just not enough
>of a market for such literature outside of the specialist journals.
What does that tell you about the method?
>Mr. Shen is, of course, correct that to apply a Bayesian attack
>to a stream cypher, the analyst must be aware that a biased generator
>is being used and have some idea of what sort of bias is likely
>to be present. However, this isn't that difficult to believe if
>one is, for instance, using a stream cypher generated from a known
>transcendental number.
Recall that the stream from digit expansion was to be post-processed
to remove any correlation due to the fact that it was calculated.
Would your statement still be correct if you had made it about a
stream cipher generated from a digit expansion which was processed by
running it through an LZ77 compression, a CRC hash or a Latin Square
scrambler, to produce the final pad?
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Practical True Random Number Generator
Date: Mon, 18 Jan 1999 14:12:20 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 15 Jan 1999 17:28:21 GMT, [EMAIL PROTECTED] wrote:
>I don't think it matters that the physics behind the RNG is "truly random" in
>the quantum sense so much that the internal state trajectory is unpredictable
>*outside* the box. [...]
>What matters is that Eve isn't
>able to predict what comes out of your classical resistor even if she could
>given knowledge she doesn't have and can't obtain.
As Patrick Juola just pointed out, that analysis you give depends on
whether the messages are few and small. If the messages are many and
large, then you need a TRNG to provide the entropy.
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 18 Jan 1999 14:19:25 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 15 Jan 1999 16:18:34 -0600, Jim Felling
<[EMAIL PROTECTED]> wrote:
>The only reason I mentioned that condition is that we are effectively
>limited to sampling a limited(if rather large) subset of such a number,
>and therefore must be concerned with the properties of that subset, and
>not of the system as a whole.
Somewhere along the way I lost what you were trying to get across. If
you feel it is important to this discussion, please restate it.
Thanks.
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 18 Jan 1999 14:17:03 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 15 Jan 1999 07:29:24 -1000, "Mr. Brisket" <[EMAIL PROTECTED]>
wrote:
>You should say "true" fine mixing.
>You should say "true" correlations.
>Is that "true" hope, "total" hope, or just common hope?
>"True" Turing sense is better than Turing sense.
>You need to use a "true" operator in this case.
>Yes, "totally" unpredictable is better than unpredictable. Totally, dude,
>like wow, you know?
Yep. You are totally true.
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 18 Jan 1999 14:16:01 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 15 Jan 1999 16:26:44 GMT, [EMAIL PROTECTED] (Snowhare)
wrote:
>>2) If you operate algorithmically on a random number generated by a
>>TRNG, it is no longer random.
>Not ok. Trivially disprovable. I algorithmically XOR a random bit
>stream with '1'. It is just as random as the original bit stream.
Good point. And as we have seen since I first made the statement
above, there are some other algorithmic procedured believed to
preserve crypto-grade randomness, even for those encryptions that are
classified as many and large encryptions.
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Mon, 18 Jan 1999 13:40:13 GMT
Reply-To: [EMAIL PROTECTED]
On 15 Jan 1999 10:21:07 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>So the point is that the *process* that generates the bits isn't
>the important part; the important part is the degree of randomness
>in the key vis a vis the randomness of the message. So if you
>have an unbounded message length (contrast with "short", which
>in this context mostly means "bounded") you need an unbounded
>supply of randomness, which usually means a TRNG. If you have
>a bounded message length, then there's a maximum amount of randomness
>necessary to provide perfect security which *can* be achieved
>via algorithmic means.
What is the approximate message and/or key length where a message
stops being "small" and become "big" enough to require a TRNG-based
key?
Bob Knauer
"Liberty lies in the hearts of men and women. When it dies there,
no constitution, no law, no court can save it."
--Justice Learned Hand
------------------------------
From: Gus Gassmann <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Help: a logical difficulty
Date: Mon, 18 Jan 1999 10:51:39 -0400
Reply-To: [EMAIL PROTECTED]
Arthur N. Klassen wrote:
>
> (Incidentally, to this day, Canadian telephone directories put Mc/Mac in a section
>of their own
> between L and M -- we're not all Scots and Irish, but we've got enough of 'em over
>here that this
> was a necessity)
That practice seems to vary from province to province, actually. In
British Columbia they
certainly do it as you describe, but in Nova Scotia they do not. Here
you are sort of supposed
to know your 'Mcs' and 'Macs' --- even the cross-reference ("for Mac see
also Mc") is easy
to miss.
=======================================================
gus gassmann ([EMAIL PROTECTED])
------------------------------
** 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
******************************
