Cryptography-Digest Digest #498, Volume #11 Thu, 6 Apr 00 02:13:01 EDT
Contents:
Re: MARKKU AND INTEL BUSINESS ... $ (97B)
Re: RNG based on primitive multiplicative generator. (Tom St Denis)
CryptoAPI towards portability (Tom St Denis)
Re: Keeping numbers small in RSA ([EMAIL PROTECTED])
Re: Keeping numbers small in RSA ([EMAIL PROTECTED])
Re: Q: Entropy (David Hopwood)
Re: Is this code crackable? ([EMAIL PROTECTED])
Re: Is this code crackable? ([EMAIL PROTECTED])
Re: Is this code crackable? ([EMAIL PROTECTED])
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: 97B <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.israel
Subject: Re: MARKKU AND INTEL BUSINESS ... $
Date: Thu, 06 Apr 2000 03:06:29 -0400
[EMAIL PROTECTED] wrote:
>
> Since April, 1999, Markku J. Saarelainen has provided the valuable
> service and intelligence for the global audience without any
> compensation. So he has done this by himself without anybody's
> assistance and has utilized his intelligence and knowledge database
> that was developed since 1980's. There are thousands of individuals who
> have benefited from his services and insights. The estimated work time
> spent by him in 1999 and 2000 is approximately 1800 hours and with the
> 50-dollar hourly contract rate this would be approximately 90,000.00 US
> dollars. So if you have benefited from his services in 1999 or in 2000
> and want to make your payment, you can contact him by email at
> [EMAIL PROTECTED] or by phone at 305-374-2834 to make an arragement for
> his compensation. He can also provide further analysis and research
> work in all intelligence fields addressed in his postings. However, he
> shall not continue posting any intelligence reports and notes in the
> future without any considerable compensation for his valuable work.
>
> All his 1999 and 2000 postings are available for you and your
> associates for the rest of everybody's life.
>
> Brivet,
>
> Vladimir
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Well thanks Markku!
Send your bill to the Usaf Intelligence - Shape - Belgium
:-)
"I think there is a world market for maybe five computers." -
Thomas Watson, chairman of IBM,
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RNG based on primitive multiplicative generator.
Date: Thu, 06 Apr 2000 01:31:47 GMT
"David A. Wagner" wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > "David A. Wagner" wrote:
> > > You might look at the papers which cryptanalyze truncated
> > > linear congruential generators. (M[i] = g*M[i-1]+a;
> > > N[i] = some bits of M[i]) The similarities are striking.
> >
> > Where can I find these papers?
>
> Your favorite research library?
> If you have a university nearby, it's a good bet,
> as always, with the cryptographic literature.
> Search for, well, cryptanalysis of linear congruential generators,
> and/or lattice reduction in cryptanalysis.
Do you remember where I live? Cryptography is not a hot topic,
political science however is a big winner :)
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: CryptoAPI towards portability
Date: Thu, 06 Apr 2000 01:34:18 GMT
I am working on making CB more portable, so if you are one that nagged
and picked on me, can you please get
http://24.42.86.123/cb_105b.zip
Basically I made all the cipher functions use
IMACIPHER_func(unsigned char *in, unsigned char *out);
Model. But what do I do for 'large' endian targets to make those
functions interoperable with little endian targets [or vice versa].
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Keeping numbers small in RSA
Date: 5 Apr 2000 22:35:30 -0400
[EMAIL PROTECTED] wrote:
> I am having some trouble calculating result = A*B mod n as part of a
> modular exponentiation. The tempory value for A*B gets too big too
> store before the modular reduction. I am limited to 32 bit storage for
> the tempory register.
How do you calculate x^y? By reducing it to accumulating products (of just
two terms) (writing y in a binary expansion).
How do you calculate x*y? By reducing it to accumulating sums (write y in
binary, say). This reduces the product to SUMS ... however!
How do you do A+B mod n (if n fits in your word size, but 2n doesn't! then
A+B might be too large! Even ADDING, let alone multiplying, may
overflow! To avoid that...
Assuming A,B,n positive and all fit .. A,B<n,
use:
IF A>=N-B THEN SUM=A-(N-B)
ELSE SUM=A+B)
For doing the calculations, here it is in QBasic (something I wrote up the
last time this came up and the question poser did not want to use a larger
integer package). You would have to convert this to whatever language you
are using.
===============
The following QBasic routine calculates a^b mod n (a between 0 and n
where a,b,n>0) without using any results larger than n.
It uses the trick of expanding b=SUM[e_j*2^j] and using:
answer=1:j=0:x=a
LOOP through bits of b
if e_j=1 then answer=(answer*x) mod n
x=x*x mod n:j=j+1
(answer is then a^b mod n)
To do the multiplications mod n (for answer*x and x*x mod n) one uses:
To calculate A*B mod n
B=sum[f_j*2^j]
PROD=0:j=0:x=A
LOOP through bits of B
if f_j=1 then PROD=(PROD+x) mod n
x=(x+x) mod n:j=j+1
(PROD is then A*B mod n)
Having reduced everything to adding A+B mod n, one does that calculation
by:
if A>=(n-B) then SUM=A-(n-B) else SUM=A+B
(sum is then A+B mod n)
which has no intermediate value which is negative (works for unsigned
integers) and which leads to no term larger than n.
-=-=-=-=-=- PROGRAMME -=-=-=-=-=-
DECLARE FUNCTION add& (a&, b&, n&)
DECLARE FUNCTION mult& (a&, b&, n&)
DECLARE FUNCTION modpow& (a&, d&, n&)
' Calculates a^d mod n without intermediate results larger than n
' a,d,n>0
' QBasic: '=REMark, \=Integer division, &=Long Integer
' 19 February 2000: John McGowan
CLS
PRINT : PRINT "This calculates a^d mod n for long integers."
PRINT : PRINT
INPUT "a (number to be raised to power)"; a&
INPUT "d (exponent = power)"; d&
INPUT "n (modulus)"; n&
a& = a& MOD n&
IF a& < 0 THEN a& = a& + n&
PRINT : PRINT
PRINT "a^d mod n="; modpow&(a&, d&, n&)
FUNCTION add& (a&, b&, n&)
' a,b,n>0: a and b both between 0 and n
' Adds a+b mod n without intermediate results larger than n
' Returns non-negative result
IF a& >= (n& - b&) THEN add& = a& - (n& - b&) ELSE add& = a& + b&
END FUNCTION
FUNCTION modpow& (a&, d&, n&)
' a^d mod n (a,d,n>0)
' a between 0 and n
pow& = 1: powsq& = a&: expo& = d&
DO WHILE expo& <> 0
IF (expo& MOD 2&) <> 0 THEN pow& = mult&(pow&, powsq&, n&)
powsq& = mult&(powsq&, powsq&, n&): expo& = expo& \ 2&
LOOP
modpow& = pow&
END FUNCTION
FUNCTION mult& (a&, b&, n&)
' a,b,n>0 (a,b between 0 and n)
' multiplies ab mod n without intermediate results larger than n
factor& = b&: prod& = 0&: temp& = a&
DO WHILE factor& <> 0
IF (factor& MOD 2&) <> 0 THEN prod& = add&(prod&, temp&, n&)
temp& = add&(temp&, temp&, n&): factor& = factor& \ 2
LOOP
mult& = prod&
END FUNCTION
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Keeping numbers small in RSA
Date: 5 Apr 2000 22:41:33 -0400
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <8cb73q$3me$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> I am having some trouble calculating result = A*B mod n as part of a
>> modular exponentiation. The tempory value for A*B gets too big too
>> store before the modular reduction. I am limited to 32 bit storage
> for
>> the tempory register.
> You have two choices: use a double length register to store the
> temporary double length product or use a radix that is half the
> word size.
No. One can write an algorithm which calculates a^b mod n without using
numbers larger than n (other than b, if b is larger than n). Heck,
consider just writing down and using the addition and multiplication
tables for mod n arithmetic! None of the numbers there are larger than n.
It is easier to write an algorithm using a word size at least twice as
large as the length of n. It is *not* necessary (see the QBasic programme
posted this time and the last time the question came up).
It is a cute *programming* problem (do the arithmetic with the smallest
word size) - but for practical applications one would use a larger word
size.
------------------------------
Date: Thu, 06 Apr 2000 00:04:54 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Entropy
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> Tony T. Warnock wrote:
[...]
> > > > Probability (in this sense) is a priori. One doesn't get 40 heads
> > > > in a row from an unbiased coin.
> > >
> > > I don't understand your last sentence. That probability is 2^(-40),
> > > isn't it?
> >
> > Yes. Really small. The point is, in practice one does not see things
> > this rare.
> >
> > On a related issue. Not only will a team (finite) of monkeys not type
> > the works of Shakespeare, they won't even get the first 50 digits of pi.
> > A team of screen writers could come up with "Romeo and Ethel, the
> > Pirates Daughter" perhaps.
>
> But note that any other bit pattern has exactly the same (small)
> probability!
Yes - which means that if you fix any specific pattern of 40 outcomes in
advance, you won't see that pattern from an unbiased coin, either.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOOvGSzkCAxeYt5gVAQFqtQf+I96OWze54ZHoPBjnEOkFcUwmvg6NaTBO
2ddU7wjR9YuXquXHSsuJ+FeObq6pEc6vV4ufK7RLmDlUdu5GLUgbSfUrDoQAedvD
iT/gjtNN2LCeJtOQl9bzikoQuDWpN6zU6Ahi8gSRcLQToXieBjVa934RVjQRhXVZ
ldfdVkdhDwgwBrtUvhCD7OmY84zf6YF49E7m1MeYEtbypqKUtG7K3674hpztemCk
Me4wuLR4naiUSAerTMp0e/U9bdWeJHgbeUMeq0Ogdbd6bCQzFCgroaUGk8qKEwmR
In1P9zafwieDM7ZrMoxr6epZd8yjCK9RxvDngsqXO2IF8ga/QN4ZYQ==
=UZEj
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is this code crackable?
Date: Thu, 06 Apr 2000 03:54:01 GMT
I'm afraid I have to agree; why don't you just
use PGP? It's safe, the code is free, and you
don't have to worry about key swapping; (public
and private key method is used instead). You can
get it at the MIT website, do a search in any
search engine for: MIT pgp
That'll take you to the page; you can download
the command line version, windows version, or mac
version.
The reason you can't use the same One Pad key
more than once is that any experienced
cryptanalyst could compare the copies and put
them together. What's more, if all the letters
are still in their original locations, (with only
the letters themselves changed) clues are given
about the construction of the code and the
message being coded, if given enough data. (ie:
multiple messages).
In article <9bffc8.bfr.ln@twirl>,
[EMAIL PROTECTED] (Geoff Lane) wrote:
> In article <5owG4.81349$AT6.92942@dfw-
read.news.verio.net>,
> "Jethro" <[EMAIL PROTECTED]> writes:
> > It works, but of course it requires one to
physically give the key file to
> > someone else. My question is, is it possible
to crack this type of code
> > without having the key file? I can't think
of a way. Is this a well-known
> > technique?
>
> Sounds like a variation of a one-time-pad. In
general there is no
> systematic method of attack for such cyphers
when used correctly. But the
> key file must be truely random and as you say
you must distribute the key
> file - tricky. Some people have suggested
using the binary stream from an
> audio CD as the key, but that has the same
problems as in the past when
> people used the same edition of a published
book. Plus you must NEVER EVER
> reuse the key file contents otherwise you are
screwed; when you rely on
> humans to follow rules you become open to
attack when they don't -- even
> Enigma was crackable when tired soldiers did
stupid things.
>
> Public key cyphers came about because of the
problems with distributing
> secret keys.
>
> --
> /\ Geoff. Lane. /\ Manchester Computing /\
Manchester /\ M13 9PL /\ England /\
>
> (A)bort (F)ail (C)reate a holographic image in
plasma memory?
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is this code crackable?
Date: Thu, 06 Apr 2000 04:00:34 GMT
I'm afraid I have to agree; why don't you just use PGP? It's safe, the
code is free, and you don't have to worry about key swapping; (public
and private key method is used instead). You can get it at the MIT
website: http://web.mit.edu/network/pgp.html
That'll take you to the page; you can download the command line
version, windows version, or mac version.
The reason you can't use the same One Pad key more than once is that
any experienced cryptanalyst could compare the copies and put them
together. What's more, if all the letters are still in their original
locations, (with only the letters themselves changed) clues are given
about the construction of the code and the message being coded, if
given enough data. (ie: multiple messages).
In article <9bffc8.bfr.ln@twirl>,
[EMAIL PROTECTED] (Geoff Lane) wrote:
> In article <5owG4.81349$[EMAIL PROTECTED]>,
> "Jethro" <[EMAIL PROTECTED]> writes:
> > It works, but of course it requires one to physically give the key
file to
> > someone else. My question is, is it possible to crack this type of
code
> > without having the key file? I can't think of a way. Is this a
well-known
> > technique?
>
> Sounds like a variation of a one-time-pad. In general there is no
> systematic method of attack for such cyphers when used correctly.
But the
> key file must be truely random and as you say you must distribute the
key
> file - tricky. Some people have suggested using the binary stream
from an
> audio CD as the key, but that has the same problems as in the past
when
> people used the same edition of a published book. Plus you must
NEVER EVER
> reuse the key file contents otherwise you are screwed; when you rely
on
> humans to follow rules you become open to attack when they don't --
even
> Enigma was crackable when tired soldiers did stupid things.
>
> Public key cyphers came about because of the problems with
distributing
> secret keys.
>
> --
> /\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\
England /\
>
> (A)bort (F)ail (C)reate a holographic image in plasma memory?
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is this code crackable?
Date: Thu, 06 Apr 2000 04:16:58 GMT
> No, they're not. You said the key file and the plaintext both consist
of
> characters from 1 to 126. That means the ciphertext will consist of
> characters 2 to 252.
I just have to wonder what your software will do with a character that
encrypts to EOF.
And, like everybody else has commented, PGP would be better.
Hypatia's Daughter
--He who lives by the sword often dies
at the hand of he who lives by the gun--
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 05 Apr 2000 22:12:15 -0700
James Felling wrote:
>
> >
>
> <Big snip>
>
> >
> > You want me to believe that there is a useful attack of the random digit
> > generator?
> >
> > You want to talk reality? Then consider this:
> >
> > If there is why do I have to give anyone the raw random digit
> > output directly from the random digit generator before they
> > can make such an attack?
>
> You don't. However, most peole are willing to spend a few days worth of computer
> time to proove a point, more than that and its not worth the effort. Since the
> dificulty of attack increases greatly without such, it becomes impractical and
> expensive for anyone to do so merely to allow you to see the light. Your cypher
> on the whole is (given the attacks against it) probably as strong as the AES
> candidates( but not significantly stronger). What we are discussing is equivalent
> to saying that there is a weakness in the round key generator for such a cypher.
> This will NOT compromise a cypher(directly), but it provides a point of attack,
> and can remove an algorithim from contention for serious practical usage.
>
> >
> >
> > Keep in mind that there is no way this data is going to be
> > available in a real life situation.
>
> Agreed to a point. It certianly is not directly exposed, but the weaknesses it
> posesses will result in artifacts in the stream generated that CAN be used to make
> an (admitedly academic -- it needs truly ridiculous quantities of stream data)
> attack against it.
>
> >
> >
> > Your questions / points of contention indicate clearly that you
> > do not have the software, you have not thoroughly read the Help
> > Files, you have not run the examples, you have not done the
> > tutorials.
>
> Really now? I have read your tutorials, examined the software, read what
> helpfiles exist, and messed with it enough to familiarize my self with its
> function as far as that goes.
>
> >
> >
> > You have refused to do your homework.
>
> You sir, have refused to answer my direct questions, you have accused me of
> neglecting to familiarize myself with the topic, and have been generally
> uncooperative in nearly all respects. If you are atempting to educate people
> about your software, you are sadly deficient in teaching skills.
>
> >
> >
> > I do not have any more time to spend with such an unmotivated
> > pupil.
>
> If my simple questions were answered in a satisfactory manner, I would cease to be
> a drain upon your time, and may even be an advocate. Is it possible, sir, that
> you cannot do so?
> Here they are again:
>
> Your RNG is flawed. This does not sink your algorithim, however, it does raise
> issues. Can you give a good expalnation as to why the flaws in the RNG do NOT
> result in an artifacts in the resulting stream? Or if they do can you explain why
> such artifacts do not comprise a security risk? Do you understand the nature of
> the flaw in your RNG? Do you know how to fix it?
>
> I accept that a direct attack versus the RNG while not impossible is going to be
> quite challenging. I will accept even for the sake of argument that you are as
> secure as the AES.
>
> your program needs several MINUTES to setup before encryption, while equivalently
> secure algorithims take at worst seconds to setup on an equivalent machine -- Why
> should I use it? What benefit does it offer that justifies the time investment?
>
> your program generates stream data much slower than, oh say, RC4 for example, why
> should I use it in prefrence to other stream algorithims?
>
> PGP has a much cleaner and easier to use user interface and offers equivalent
> security and faster encryption, why should I use your program?
>
> Even ScottXu has had more thourough examination, and has actually had some
> sophisticated analisys performed upon it, has your program? If so why does the RNG
> have the weakness that it does( it is a fairly simple one that can be easily
> avoided by trivial modification)?
"time to proove a point"? Prove what point? That there is a flaw
in the random digit generator? No flaw exists except in your own
imagination. The random digit generator serves a purpose. To
this end it has no flaw. You choose to perceive a flaw. But this
is because you do not comprehend the purpose of the random digit
generator.
"without such, it becomes impractical and expensive" (To put it
mildly.) When the software is used according to recommended use
it becomes practicably impossible, is more like it.
"This will NOT compromise a cypher(directly), but it provides a
point of attack" Oh? Regarding OAP-L3 this claim is completely
irrelevant. Again, when used according to recommended use,
specifically, when the original random number stream output
(0 - 255) is completely and irretrievably lost with subsequent
processing, there will be no attacks according to your pointless
generalization.
"will result in artifacts in the stream generated" Totally
ridiculous. I will give you any amount of the final OTP data
you think you will need and you will never ever ever deduce the
random digit output from the random digit generator or the original
MixFiles used as the random digit generator input. You cannot
even justify your statement other than to say that you read it
somewhere.
You know I am correct if you have read and understand the OAP-L3
software, specifically regarding the processing done to the RandOut
files and the final generation of the OTP files.
"messed with it enough" Clearly not enough.
Can any one of you imagine when you were in the university, a
student telling his professor that he "messed around" with his
homework "enough"? "Yeah, teach. I messed around with your
homework enough..."
Then how do you explain your obvious lack of understanding about
OAP-L3? What kind of credibility do you bring to this discussion
when you admittedly (implicitly) have not done your homework
adequately?
"Your RNG is flawed" I thought we were talking about the random
digit generator. If you insist: the random number generator
outputs the random numbers found in the OTPs. Are you now talking
about the OTP random numbers or are you fantasizing about some other
numbers. You really must decide what you want to discuss. You
are ridiculous if you think there is a flaw in the OTP random
numbers. You still have given us no proof of this: not even a
plausible glimmer.
Your insistence borders on the insane, and we can be sure of this.
The only flaw is in your illogical thoughtless position. There is
absolutely no flaw in the theory, processes, and procedures of
OAP-L3. Show us how you intend to break the OTPs.
Consider the probabilities inherent in the recommended use of
OAP-L3 software. Then give up.
FACE IT: YOU HAVE BEEN BEATEN BY AN ALGORITHM!
And consider this: you and your phony cronies in this news group
are just about out of time.
Version 4.3 is about to be released. And version 5.0 has been
spec'ed out.
In fact, I have had a working prototype of version 5.0 running for,
let me look... over three months now.
Version 5.0 will blow everyone away with its variability and power.
Isn't this really why you and your phony cronies in this news group
are so unnaturally concerned about OAP-L3?
I think so.
You asked me to write a paper. Guess what? There are probably
a dozen papers already written on OAP-L3. One is at NSA, another
at MI 6, one is in Moscow, another in Tokyo, ... But don't hold
your breath waiting for one of these to be published.
Perhaps someone else will get around to publishing one. They
would certainly get much attention from the experts in the field.
It would be great publicity for someone. But I recommend they wait
until Version 5.0 is released.
Here is a suggestion: why don't you write one and highlight your
supposed flaws in OAP-L3. Now that would take some guts on your
part. Are you not sure enough of your position? I don't think
you are. The experts will slaughter you (and your phony cronies as
well.) Be sure of it.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 05 Apr 2000 22:21:08 -0700
Xcott Craver wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> [huge snip]
>
> Hi Anthony,
>
> >You want to talk reality? Then consider this:
> >
> >If there is why do I have to give anyone the raw random digit
> >output directly from the random digit generator before they
> >can make such an attack?
>
> This isn't true: people can attack the cryptosystem
> this way even if you don't directly give them the
> pseudo-random digit stream.
>
> In partial known plaintext attacks, say in which I
> know what's in the first half of your file but not
> the second, I can extract the raw random digit output
> used in the first half. This situation occurs very
> commonly in real life, say if someone incrementally
> updates a large text file, like a log file, a diary,
> a business plan, etc etc.
>
> For a stream cipher based on a "cryptographically secure"
> generator, the information from the first half should
> not provide any information about the second half.
> Conversely, if the generator is not cryptographically
> secure, meaning that given current outputs one can
> predict future outputs (within a single period,) then
> one can crack a code based on it.
>
> So being able to predict future generator outputs
> _can_ be used to attack the cryptosystem in some
> realistic scenarios.
>
> >Keep in mind that there is no way this data is going to be
> >available in a real life situation.
>
> I don't see how you can say such a thing. Any
> small portion of a ciphertext which is known, or
> can be guessed, through other techniques, gives
> away a portion of the PRNG output.
>
> You have no idea, because NOBODY has any idea, what
> cryptanalytic attacks may exist for a cipher. You can't
> simply make a cipher resistant to what you know;
> even flaws that do not translate into direct attacks
> today can be used to pry open an attack tomorrow.
> That's why PRNGs are not used for cryptosystems
> if they don't pass a bevy of statistical tests, or
> if future outputs can be predicted from previous
> outputs.
>
> -Scott
I claim that you cannot successfully use a plain text attack against
OAP-L3.
Let's cut to the chase: I will give anyone as many OTP files they
want and all they have to do is predict the next 100 random numbers
(0 - 255) from the OTPs.
Believe me, I will create a key with a security level so
astronomical you could take LSD and not get that far out.
Too often the discussion leads to vague generalities.
I have to say it again: it is clear to me that you do not know
OAP-L3 and therefore you do not know what you are talking about.
------------------------------
** 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
******************************
