Cryptography-Digest Digest #888, Volume #8 Tue, 12 Jan 99 09:13:04 EST
Contents:
Re: On the Generation of Pseudo-OTP ("Trevor Jackson, III")
Re: Birthday Attack calculations. ("Trevor Jackson, III")
Re: Birthday Attack calculations. (Fred Van Andel)
Re: Comments & note for Bryan (Re: coNP=NP Made Easier?) (Yak)
bootlock for NT or 98 ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP (John H Meyers)
Re: Practical True Random Number Generator (KloroX)
Re: On the Generation of Pseudo-OTP (Mok-Kong Shen)
Re: Practical OTP for secure two-person emailing (Mok-Kong Shen)
Re: On the Generation of Pseudo-OTP (Mok-Kong Shen)
Re: On the Generation of Pseudo-OTP (Mok-Kong Shen)
Re: DES Hardware Implementation!! (Vincenzo Liguori)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (Mok-Kong Shen)
RSA-Examples ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP ("Lassi Hippeläinen")
----------------------------------------------------------------------------
Date: Mon, 11 Jan 1999 23:22:04 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
R. Knauer wrote:
> On Mon, 11 Jan 1999 20:48:07 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >If you are wiling to work with keys that are less than perfect,
>
> I do not recall ever saying I was, but let's assume so for the sake of
> discussion. The only "imperfection" I said should not make any
> practical difference was the filtering out of two particular
> pathological sequences - all 1s and all 0s.
No, you said:
> By practical security in the context of an OTP cryptosystem, I mean
> that a successful Bayesian Attack is not possible, even if there is
> the slightest leakage of information due to a TRNG that is not
> perfect.
The phrase "a TRNG that is not perfect".
> >can you
> >describe the limits on the amount of imperfection that you find tolerable?
By imperfection were you referring to flatline output segments, or something
more sinister?
------------------------------
Date: Mon, 11 Jan 1999 22:45:19 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Birthday Attack calculations.
Fred Van Andel wrote:
> A birthday attack would require > 2^128 calculation while an
> exhaustive search would need 2^255. There is a big difference. When
> you are dealing with large hashes even a birthday attack becomes
> impossible to do. Its the birthday attach that dictates the size of
> hash required, not the exhaustive search.
I agree with your last statement above. But I an confused by your first statement
above. Is there a closed-form equation for the figure 2^128 you quoted? I am only
familiar with the probability series summation.
------------------------------
From: [EMAIL PROTECTED] (Fred Van Andel)
Subject: Re: Birthday Attack calculations.
Date: Tue, 12 Jan 1999 06:34:34 GMT
Reply-To: [EMAIL PROTECTED]
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>Fred Van Andel wrote:
>
>> A birthday attack would require > 2^128 calculation while an
>> exhaustive search would need 2^255. There is a big difference. When
>> you are dealing with large hashes even a birthday attack becomes
>> impossible to do. Its the birthday attach that dictates the size of
>> hash required, not the exhaustive search.
>
>I agree with your last statement above. But I an confused by your first statement
>above. Is there a closed-form equation for the figure 2^128 you quoted? I am only
>familiar with the probability series summation.
You quoted the formula yourself in a earlier message
> odds = 1;
> for i=0 to N-1
> odds = odds * (M-i)/M
For any gives value of M the location of the 50% mark will be roughly
the square root of M. The square root of 2^256 is 2^128.
Unless I am misunderstanding you again.
Some closed forms of the equations were given in the earlier posts of
this thread.
This method was posted by David Broughton
> w = n^g + 0.29 - e
>
>where:
>w = the number of documents to get 50% probability of a collision
>n = number of different hash codes, all equiprobable
>g = 0.5 + 1/(6.13 * ln(n))
>ln() is the natural logarithm function
>e is a small error that can be ignored in practice, usually < +- 1.
>
>This is an empirical formula that I worked out many years ago and
>filed away in a notebook.
>
>The exact formula is the value of w in this equation:
>
> ( product from k = 1 to k = w-1 of (n-k)/n ) = 0.5
>
>but this is not a practical calculation for large n.
>
>As you can see, w is a bit larger than the square root of n. For
>n = 10^6, for example, w = 1177.68 (e = -0.197).
>
>If your formula is meant to be 1.2 * n^0.5, then w = 1200 for n =
>10^6 which is getting there.
Or this one by Peter Pearson
>To derive your own approximation formula from the above, exact
>formula, rewrite it as follows:
>
> n (n-1) (n-2) ... (n+1-w) n!
>product = -------------------------- = ----------
> n^w (n-w)! n^w
>
>Then, use Stirling's approximation to make the factorials more
>manageable. Stirling's approximation (see, for example, Knuth,
>Art of Computer Programming, Volume 1) is:
>
> ln( n! ) = (n+1/2) ln(n) - n + ln( 2*pi )/2 + 1/(12*n) - ...
>
>You'll have to experiment with the number of terms required to
>get meaningful results. Overimplifying to n*ln(n)-n gives conspicuously
>nonsensical results. If memory serves, (n+1/2) ln(n) - n + ln( 2*pi )/2
>is a good level of approximation, and one needs the approximation
>ln(1+x) = x (for small x) as well.
Or this one by Terry Ritter
> s(N,p) = (1 + SQRT(1 - 8N ln(p))) / 2
>
>where s is the expected number of samples needed, N the size of the
>population being sampled, and p the given probability.
>
>For N = 10**6 and p = 0.5 (so ln(p) = -0.693) we get 1177.9 instead of
>the usual handwave SQRT(N) = 1000, or the stated approximation, 1.2 *
>SQRT(N) = 1200.
>
>For N = 2**20 and p = 0.5, we get 1206.2 instead of 1.2 * 1024 =
>1228.8 for the stated approximation.
>
>The formula basically comes out of my article on population
>estimation:
>
> http://www.io.com/~ritter/ARTS/BIRTHDAY.HTM
>
Fred Van Andel
------------------------------
From: Yak <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: Comments & note for Bryan (Re: coNP=NP Made Easier?)
Date: Mon, 11 Jan 1999 21:46:48 -1000
rosi wrote:
> P
TM.
coNP=NP.
if A
> then B.
> Queuing Theory?
'P by DTM'.
> Turing,
Church's Thesis
Cantor, do it in private.
> If NDTM is real, coNP=NP.
>
> SS positively in P, then coNP=NP.
>
>
> coNP?=NP
> 27.
> NDTM is realizable, coNP=NP.
because NDTM (K) behaves
> as described in 26.
> 2. NDTM (K)xistence (i.e. P=NP)
> NP=coNP.
> NOTE: Hope
> NDTM is real
do not waste your time.
O(n) TM's; there are
> O(n^2) TM's; there are O(2^n) TM's; and there are O(e^O(1)) ones
Because DTM can not solve SS
ryptographic scheme is also
>
> --- (My Signature)
>
> P.S.
>
coNP=NP
It is because you are wrong.
'irrelevant' problem
Ilias in
Ilias is now
different opinions, make them
> explicit and clear for me, the readers and the world see. I
> say a BOTM(x) { return NO#; }
YES#! You know Bryan. If YOUR_ NDTM solves SS coNP=NP
>
> --- (My Signature)
------------------------------
From: [EMAIL PROTECTED]
Subject: bootlock for NT or 98
Date: Tue, 12 Jan 1999 06:38:21 GMT
Howdy Folks,
I'm chasing a bootlock for NT and/or 98.
The only way I can think to describe it is as a cross between DoubleSpace and
Scramdisk. I believe Norton's do a bootlock within YEO...
Any ideas? Is the Scramdisk guys amenable to suggestions?
cheers, mike
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: John H Meyers <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 02:50:35 -0800
Reply-To: [EMAIL PROTECTED]
Patrick Juola wrote:
> For most trancendental numbers and most bases, it takes time and effort
> to calculate increasingly long strings of digits. So for engineering
> reasons, it's a lot faster to calculate the first thousand digits
> than the second thousand (and so forth, progressively).
> for generating successive digits of
> a trancendental numbers -- each digit costs marginally more than the
> last, which means that there's one digit that costs more to generate
> than it would cost to generate and distribute random pages. At this
> point, it is no longer cost-effective to consider trancendental-based
> computation. You might as well print the pads and be done with it.
Nonetheless, any *hexadecimal* digit of pi can be calculated (yes,
at slightly increasing cost) without calculating *any* previous digit:
<http://www.mathsoft.com/asolve/plouffe/plouffe.html>
The following claims to have calculated over 50 *billion* (50*10^9)
digits of pi: <ftp://www.cc.u-tokyo.ac.jp/README.our_latest_record>
(many statistics included)
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 (no need to store the pad, since the digits at any offset
can be generated, as above, without knowing any prior digits);
cryptanalysis of this one might seem difficult :)
===========================================================
With best wishes from: John H Meyers <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (KloroX)
Subject: Re: Practical True Random Number Generator
Date: Tue, 12 Jan 1999 09:30:10 GMT
Reply-To: [EMAIL PROTECTED] (this is spam bait)
On 11 Jan 1999 23:31:17 GMT, [EMAIL PROTECTED] (John Curtis) wrote:
> I think that a smoke detector is probably modifiable into
> a very good TRNG, as the decay particles are detectable as
> individual events and the time series of these is tied
> directly into quantum decay. Should be possible to isolate
> the system from outside influences much more easily than a
> "noise" source, as you are sensing a highly amplified discrete
> event, rather than trying to highly amplify a continuous
> signal.
Does anyone have pointers to on-line schematics/explanations of the
electronics in a ionization-type smoke detector? As I understand it,
alpha radiation ionizes the oxygen and nitrogen in the air, which then
flows to one of the charged plates in the detector. Smoke absorbs some
of the ions, and the reduced current flow is detected. For this to
work, a rather steady flow of ions must be necessary, so it might be
difficult to resolve the flow into individual "hits". Perhaps the
detector cannot be used without sibstantial modifications.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 11:41:42 +0100
R. Knauer wrote:
>
> On Mon, 11 Jan 1999 16:35:46 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >So please give a FORMAL and rigorous proof of the security! Does
> >'arbitrary limit of precision' mean an approximation or perfectness??
>
> Is there an echo in here? Every time I open one of your posts you are
> asking the same question.
>
> I will omit a response this time to let you get caught up on the
> several earlier posts where I have discussed this about as
> exhaustively as I am able to do right now (although I do have more to
> discuss later when we get past these hurdles).
Mmm. How many time did you ask me to prove that my proposal gives
perfect strength? And how many times I told you that such a proof
is not needed because the proposal doos not claim perfect strengh
and is simply something for discussion (and have hence a potential
chance to turn out to be of no practical value at the end of
discussions)? It was because you are apparently SO fond of 'proof'
that I also challenged you to deliver a proof, to the satisfaction
of your own wishes!
>
> >Can you give good literature references to 'Bayesian Attacks'?
>
> No. I am not a cryptanalyst. I am only someone who reads the posts
> submitted here and makes judgements based on the expert opinions
> presented. You will have to ask the experts here to provide you with
> that information.
>
> I believe someone did do so a year ago, but I can find nothing in my
> bookmarks or text archives regarding it. But that person, Patrick, a
> bona fide expert cryptographer who lent considerable insight to these
> discussions a year ago, is either not on here at the moment, or is
> lurking - or has not opening this thread.
Is this term 'Bayesian Attack' employed in any text books on
cryptology? Another question: Using frequency analysis dates back to
the very beginning of cryptology. Since you are VERY sensitive to
new terminologies (against my 'pseudo-OTP', for example), tell
me why have you accepted that new term 'Bayesian Attack' without
significant inner resistance.
>
> Terms like "pseudo-OTP" in the subject header do have a strong
> tendency to scare off experts, because they assume that the person who
> would use such a term is a complete neophyte. That's why it is
> important to learn the proper use of terms lest you end up talking to
> just yourself in the long run.
>From now on in this thread I'll in all discussions with you (only)
use the longer term 'intended approximation to an ideal OTP'. Does
that serve to avoid wasting time on debating about this point??
(Tell me if you have objections to the new term.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Practical OTP for secure two-person emailing
Date: Tue, 12 Jan 1999 11:11:54 +0100
Anonymous wrote:
>
>
> Following on the thread of the "Practical TRNG," if Alice filled a 660mb
> file with a stream of true random bits, burned one CD-ROM copy for herself
> and one copy for Bob, then met Bob to give him the CD-ROM OTP, it seems
> like they could exchange years worth of personal email (textual at least)
> before needing to generate a new OTP and meet again to swap it.
>
> Alice starts at offset zero, Bob starts at offset halfway through the CD,
> and if Alice hits Bob's offset or Bob hits the end of the CD (or say, they
> come within 10% of their ends), then they begin to make provisions to
> create and exchange a new OTP. Each message contains an offset number to
> avoid synchronization problems.
>
> Each party could send ~330mb of data before the pad would be used up.
> This is quite a decent amount of text, certainly more text than I write to
> any single person in my lifetime.
>
> This seems to make an OTP-based TSCS quite feasible in real life, as long
> as you make sure you never re-use any portion of the pad, and that the pad
> (and original file) are securely deleted after use. Obviously the
> strongest attack would be to recover either Alice or Bob's pad.
>
> Protocol concerns such as Bob being assured that Alice REALLY made good
> TRNs for the OTP could be addressed by each of them burning their own OTP
> CD-ROMs and trading them, then agreeing to use XOR-ed data combining one
> byte from each CD-ROM to create one key byte.
I indicated in another thread (on 'pseudo-OTP') that there is a
possibility of using a set of offsets and combining the subsequences
(wrapping round at end of file) thus obtained with, say, an XOR
or an addition mod 2^32. This way, by changing the set of offsets,
one can get different combined sequences. This effectively prolong
the practical lifespan of the orginal sequence. I believe that, if
there are a sufficient number of participating subsequences, i.e.
if the set of offsets is not too small, such derived sequences need
not be weaker than the original sequences, though I can't offer a
formal proof of that assertion.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 12:22:43 +0100
[EMAIL PROTECTED] wrote:
> > I sincerely hope that the region outside of the 33 countries will
> > very soon catch up in matters of crypto technology.
>
> I don't think this is what we have to wait for: The more interested
> point
> is that large companies are beginning to export the cryptography they
> developed in their countries from countries outside the 33.
>
> On the one hand this way the law becomes useless, on the other hand it
> causes economic loss to the 33.
Yes. The recent recruitment by RSA of two very capable cryptographers
in its Australian branch is significant for the the viewpoint that
the Wassenaar agreement may not achieve its (officially) intended goal.
One should perhaps not entirely dispose of the (certainly wild)
speculation that the agreement were actually intended to create a
crypto business boom under a false cover.
Your last sentence is significant and true. There is prospect from
that reason that not all of the 33 countries will march with
the same pace despite their signatures. It is a blessing of our
world that it is barely possible to manage to get a significant
number of people (or legal persons) to act in exactly the SAME way.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 12:26:32 +0100
R. Knauer wrote:
> I know, I know. Nothing in the real world is perfect, not even this
> statement.
>
> But so what?
So there is not of much practical value to insist on perfect security,
on obtaining (ideal) OTP. And one can, for example, consider the
utility of the non-perfect 'intended approximation to an ideal OTP'.
M. K. Shen
------------------------------
Date: Mon, 11 Jan 1999 06:50:03 +1100
From: Vincenzo Liguori <[EMAIL PROTECTED]>
Subject: Re: DES Hardware Implementation!!
> Hello!
> I'm working on the hardware inmplementation (with VHDL into an FPGA) of
> DES decryption.
> after many searh I did not find any publication or example about this
> topic.
>
> Can anyone point me to some documentation on the subject?
> Thanks in advance!!
We sell such DES implementation in VHDL and Verilog.
Some examples for the serial implementation (no pipelining, 16 cycles):
Xlinx Virtex : 272 CLBs 77 MHz 308 Mbits/s
Altera Flex 10K : 570 LEs 73 MHz 292 Mbits/s
Smaller if only encryption or decryption are required.
Soon to be released as Altera and Xilinx cores.
My real email is in the web page.
Regards,
Vincenzo Liguori
=========================================================
Vincenzo Liguori
Ocean Logic Pty Ltd
PO BOX 768
Manly NSW 1655
Australia
Ph : +61-2-99054152
Fax : +61-2-99050921
Email : see web page
WWW : http://www.bigfoot.com/~oceanlogic
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 12:43:44 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 10 Jan 1999 22:08:29 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> The best possible key is one generated by a TRNG, which is a physical
>> device capable of outputting all possible sequences of a given finite
>> length equiprobably. That includes outputting sequences that have bits
>> which are not "independent" of one another, such as in the sequence
>> 111...1.
>The preceeding statement is sense-free.
Whenever people lead in with an ad-hominem like that one above, I
become suspect that they are trying to cover their own lack of
understanding.
>One cannot infer independence by looking at the data.
I think we have said that very thing a sufficient number of times not
to have to harp on it any more.
>One can only fail to find dependence.
I do not understand what you have just said in the context of this
discussion.
>A sequence of 6 one bits is going
>to appear in more than 1% of the six-bit samples from a true random bit generator.
>This does not mean the bits are dependent.
I fully agree, and have stated so many times.
The reason for emphasizing that particular sequence (and its inverse)
is that they are two of the most common manifestations of digital
circuit failure, and on top of that one would have to be a complete
idiot to use them for an OTP, regardless of how tainted that would
make one in the Platonic world of pure ideals.
>Right. The quality of the key was certinaly "good enough" to qualify that system
>and a true OTP in spite of what we would judge as low-quality key material.
I never knew that Venona concluded that the key material was of low
quality. In fact, I don't even know what you mean by such a term.
How does one characterize a key as low quality, unless it can be show
to be susceptible to a successful Bayesian Attack, which was certainly
not the case with those Russian ciphers. Instead it took pad reuse to
break them.
>No. I mean a compression/decompression system. Such systems are lossless, and so I
>would speculate that they cannot reach 100% information density.
You seem to be saying that mixing entropy cannot reach 100%, even for
simple mixing that is lossless. Perhaps you are right - it has been a
long time since I studied such concepts formally.
>A hash is not lossless. A hash is lossy. E.g., you cannot recreate the source from
>the hash value. It should be possible to reach 100% information density with a
>hash.
You are couching your comments in subjunctives, which means you do not
know whether they are accurate or not. Can you offer some solid
evidence for your assertions about entropy so we can move past this
conjecture stage?
>It should be possible to define a
>deterministic algorithm that accepts 3 inputs:
> 1. some bit stream
> 2. a number describing the assumed entropy density of the input stream
> 3, a number describing the desired entropy density of the output stream
>algorithm produces an output stream of the desired entropy density.
>I believe this is possible. Do you disagree?
I have no earthly idea how to begin to agree or disagree. You are the
entropy guru, not me.
As I mentioned in an earlier post, I have my own suspicions that
entropy is not a sufficiently strong way to characterize a
crypto-grade random number since it is applied either to the sequence
itself (as in a determination of possible reduction) or the method of
generation (limitations on the number of microstates for a given
macrostate), and as I mentioned I do not consider either of those to
be completely relevant to the proveable security of the OTP.
The proveable security of the OTP cryptosystem comes from its complete
resistance to a Bayesian Attack, which has nothing to do per se with
either an intrinsic property of the pad or how it was produced - other
than to indicate that the pad was poorly produced when a Bayesian
Attack succeeds.
A crypto-grade random number is one which resists a successful
Bayesian Attack. There is no more to it than that, other than to point
out that a properly constructed TRNG will generate such numbers.
>> BTW, what algorithmic method do you propose, besides hash functions,
>> to produce 100% entropy from text?
>I suspect we'll get to that, but let's set the parameters first.
The sole parameter is that whatever pads you generate using your
entropy criteria, they must be such that a Bayesian Attack is
impossible.
That means that even if you accepted 000...0 as your pad, a
cryptanalyst would not be able to conclude from a Bayesian Attack
alone that it was the actual message plaintext, however likely that
might be based on the extreme unliklihood of such a pad ever occuring.
IOW, not even such a freak pad would "leak" any information in a
Bayesian Attack.
So there is your parameterization. Now, do you have any algorthms to
offer us for consideration, based on your entropy theory.
>> Again, I ask you to provide a class of hash functions which will
>> proveably produce 100% entropy from any input.
>Here's a key assumption: "from any input". Clearly that's asking a bit much. It
>would require an arbitrarily large amount of entropy from the input string "".
I do not understand what you have just said.
You seem to be saying that you have this entropy criterion but it
cannot be used in the real world to specify crypto-grade random
numbers.
>> In fact I have said (a year ago and repeated here) that one might be
>> able to build a secure stream cipher from the least signigicant bits
>> of text, after antiskewing and decorrelation. The hangup was on the
>> proposed method of decorrelation. Strong mixing of different streams,
>> such as recommended in RFC1750 (which includes hashing), is supposed
>> to produce a correlation-free stream, but others criticized that
>> method and I could not argue against them. Perhaps you are in a
>> position to clarify this sticking point.
>Rats. I cannot possible debate arguments I have not encountered.
Nobody is asking you to. Your comments would be sufficient to get the
discussions going again, hopefully in an even more fruitful manner
this time.
>I've got to travel most of this week,
So, take a laptop and connect online at the hotel.
>so I can't go spelunking in news archives until next week
>at the earliest. I'll see how far I get with it.
RFC 1750 is available on the Web. Here is one source that seems to be
stable over the last year:
http://andrew2.andrew.cmu.edu/rfc/rfc1750.html
Bob Knauer
"Anyone that can get elected, is not qualified to serve."
--Lance Bledsoe
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 11 Jan 1999 13:53:55 +0100
R. Knauer wrote:
>
> On Fri, 08 Jan 1999 15:35:50 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >BTW, if you have collected a bunch of bits
> >from hardware (OTP), you could also use a number of offsets on it in a
> >similar manner, i.e. combine the sequences with XOR, etc. (You would
> >say that results in a pseudo-OTP, but it could be an economical way
> >of using the resource.)
>
> But that would defeat the portability of the proposed system. Remember
> the original objective was to have a system that could be used
> anywhere without having to worry about OTP key management.
That was only a side remark. It means that if there exists already
a file of hardware random bits, then letting it combine with, say,
texts, can give some useful pseudo-OTP, thus in a sense prolong
the lifespan of the hardware bits.
>
> >There is NO (computationally feasible) method to decide that a number
> >is random for ANY purposes, not just crypto purpose.
>
> Not true. There is a much relaxed set of criteria for randomness used
> in simulations - so relaxed that it would not pass the criteria for
> crypto-grade randomness. PRNGs, for example, are used in simulation.
PRNG are extensively in normal numerical computations. But PRNG
wears the prefix 'pseudo', meaning that the sequence is not truly
random.
>
> >We have discussed
> >in another thread that the high theories of Chaitin and others are
> >non-practical!
>
> I never agreed with any of that. I think there is some applicability
> to crypto. But Chaitin is not the one who says what a crypto-grade
> random number is. That is dictated by crypto people. See Schneier's
> main book for some relevant discussions.
>
> >There are the so-called cryptologically strong PRNGs, e.g. the one
> >of BBS.
>
> But there is no way to know for sure that these and similar
> "cryptologically strong" PRNGs are really all that secure.
Similary there is no way to know for sure that hardware random
numbers are really all that secure!
>
> >What is the reason of your general opposition to PRNGS?
>
> The only time I object to PRNGs is when we are discussing the OTP
> system, and then on fundamental grounds, not practical grounds.
If you accept that a good pseudo-OTP can be useful on PRACTICAL
grounds, then we don't have to argue.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: RSA-Examples
Date: Mon, 11 Jan 1999 15:07:00 GMT
Hello all,
RSA Examples for download are available.
The zipped file is RSA.mdb (MS Access7). The data base
contains 13 tables. Each table corresponds a modulus.
If n=pq is a modulus then the name of the table looks as
Tab_p_q. Columns of the table are all possible exponents.
Lines of the table are all possible messages. With the
help of this tables you can check all my results and/or
your own theory and practice.
Please follow the link 'RSA Examples for download(57 Kb.ZIP)'
at the top of www.online.de/home/aernst/RSA.html or
use the link 'RSA-NULL Security'
at www.online.de/home/aernst .
Regards
Alex
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Lassi Hippeläinen" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Tue, 12 Jan 1999 11:50:14 +0200
John H Meyers 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 (no need to store the pad, since the digits at any offset
> can be generated, as above, without knowing any prior digits);
> cryptanalysis of this one might seem difficult :)
>
> -----------------------------------------------------------
> With best wishes from: John H Meyers <[EMAIL PROTECTED]>
I have toyed with the same idea. Of course you must make sure that you do not
use overlapping segments in the XOR, or you would introduce some correlation
to parts of the generated pad. For example, you could split pi to segments of
equal length and use wrap-around counters to index the segments. When the
segments have been consumed, increment only one of the counters and do it all
over again. And again...
Using a public origin (like pi) separates randomness as a statistical entity
from randomness as a secret. My argument has been that the randomness of the
OTP should be compared with the statistical tools that a cryptanalyst can
use. Therefore the pad can be public, as long as it is unrecognizable without
the key.
-- Lassi
------------------------------
** 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
******************************
