Cryptography-Digest Digest #493, Volume #11 Wed, 5 Apr 00 12:13:01 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. ([EMAIL PROTECTED])
Re: GSM A5/1 Encryption (Matt Linder)
Re: Key exchange using Secret Key Encryption ([EMAIL PROTECTED])
Re: NSA ("Geir Rastad")
A course on "Methods of Cryptanalysis" (Alex)
Re: Is this code crackable? ([EMAIL PROTECTED])
Re: Looking for some help on RSA public key/private key generation (Bodo Moeller)
Re: Q: Entropy ("Tony T. Warnock")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Re: DDJ Crypto cdrom (first edition) ("Keith Monahan")
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 5 Apr 2000 12:05:19 GMT
In article <8cdl0d$[EMAIL PROTECTED]>, "Harvey Rook" <[EMAIL PROTECTED]>
writes:
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message > For any who
> need a lesson: first a random digit triplet is formed
>> directly from the random digit generator. If this number is
>> greater than 767 it is discarded. Otherwise this number is
>> divided by 3 and the remainder is truncated. This and all
>> subsequent random numbers from 000 - 255 calculated in this manner
>> are then stored in RandOut files usually having a length of
>> 18144000 binary bytes each. These several RandOut files are
>> further processed repeatedly using as many as ten different
>> processes. All processes use true random user input as parameters.
>> Finally, these RandOut files are combined randomly in the OTPs again
>> using true random user input. This is it in a nutshell. Read the
>> documentation available in the Help Files for more details at
>> http://www.ciphile.com
>>
>
> Out of curiosity, Why are you generating biased numbers?
> 0 and 255 will show up much less often than 127 and 128.
> This operates on the same principle as rolling 3 dice,
> summing them up and then dividing by 3. The value of 1
> and 6 will only show up about 0.5 % of the time, but the
> value of 3 will show up 8.3% of the time.
He's not rolling 3 100 sided "dice" and adding. He's rolling 3 10
sided "dice" and using them as the decimal digits of a number. The
result will be a value in the range 0 through 999. If the dice are
well behaved, the distribution for the resulting value will be uniform.
He's discarding values greater than 767. This gives a uniform distribution
from 0-767.
He's dividing by 3. This gives a uniform distribution from 0-255.
All conditioned on the randomness of the digit generator, of course.
John Briggs [EMAIL PROTECTED]
------------------------------
From: Matt Linder <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Wed, 05 Apr 2000 12:22:08 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]=NOSPAM (Arturo) wrote:
>
> >I have seen some ads from companies like G-com in new york that
> >advertise GSM intercept equipment for sale (to law enforcement only
of
> >course !)
>
> It is posslble. Would you share the url, please?
Sure, go to http://www.gcomtech.com/ but don,t expect to get very far,
just about all the links require a password. I saw the ad for them
in a magazine (I don't remember which one though)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key exchange using Secret Key Encryption
Date: Wed, 05 Apr 2000 12:34:31 GMT
In article <8cb1iq$tfu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8bvdfk$ghs$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Strangely enough, many "secure" connections, such as those used in
> > browsers, completely ignore the man-in-the-middle problem.
>
> Not quite accurate. They don't ignore the problem, they push it off
> somewhere else. In the case of SSL, they push it to server
> certificates. Your browser uses the server's public key to encrypt
the
> session key which it uses to encrypt the data.
OK, browsers was a bad example, since they often use certificate
authorities and such.
Consider for instance, the Windows 2000 terminal server. The protocol
used to set up a "secure" connection between a thin client and the
terminal server uses the Diffie-Hellman protocol or something similar
for the key exchange. No certificates or digital signatures.
It is wide open for a man-in-the middle attack.
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Geir Rastad" <[EMAIL PROTECTED]>
Subject: Re: NSA
Date: Wed, 5 Apr 2000 14:55:37 +0200
An off-topic anekdote:
A couple of years ago the Norwegian Intelligence (NI) decided to buy some
new crypto kit for their internal network (they have their own little
network for data, fax and phone using crypto). Ofcourse they would buy it
from the North Americans (as they've already paid for all the domestic
intelligence equipment used to spy on russians...) , but this piece of kit
had a built-in decryption chip so CIA could read the data stream in plain
text using some of their equipment....
NI built the equipment themselves...
This obviously had something to do with the exporting of strong encryption
equipment from US, but
if CIA can monitor the data, so can a lot of other intelligence offices
'round the world, I guess...
------------------------------
From: Alex <[EMAIL PROTECTED]>
Subject: A course on "Methods of Cryptanalysis"
Date: Wed, 05 Apr 2000 15:29:09 +0200
==============D20BDA3A1AB20424C03FD173
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I am teaching the course on "Methods of Cryptanalysis" this semester at
Weizmann.
If you are interested in this topic, you are welcome to participate in
this course
through the Internet. Although the course is already running for a
month, registration
for course participants starts now. Due to this, prerequisites for this
course for Internet
participants are: knowledge of classical cryptography ("simple" ciphers)
or any basic
Cryptology course.
In order to participate in this course you will have to pass an entrance
exam.
Correct solution for the first three problems of Homework 2 (1, 2a, 2b,
3) is a condition
for you acceptance to this course. The deadline is 13.04.2000, 24:00
IST (about a week from now).
Only full submissions will be considered. See more info exam submission
here.
Pencil & paper solution of the exam is highly recommended. You may find
helpful hints
and auxiliary programs here .
Together with your submission please provide the some personal
information:
Name (or Nick): Tamerlan
Institution: Kurultai
Your Background in Crypto: "Introduction to Cryptology" course by
Zhengis Khan
Country: White Horde
It is up to you what information to provide about yourself, but note
that it will appear in your
course graduation digital certificate.
good luck,
Alex.
==============D20BDA3A1AB20424C03FD173
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>I am teaching the course on "<a
href="http://www.wisdom.weizmann.ac.il/~albi/cryptanalysis/">Methods
of Cryptanalysis</a>" this semester at Weizmann.
<br>If you are interested in this topic, you are welcome to participate
in this course
<br>through the Internet. Although the course is already running for a
month, registration
<br>for course participants starts now. Due to this, prerequisites for
this course for Internet
<br>participants are: knowledge of classical cryptography ("simple" ciphers)
or any basic
<br>Cryptology course.
<p>In order to participate in this course you will have to pass an entrance
exam.
<br>Correct solution for the first three problems of <a
href="http://www.wisdom.weizmann.ac.il/~albi/cryptanalysis/home2.htm">Homework
2</a> (1, 2a, 2b, 3) is a condition
<br>for you acceptance to this course. The deadline is <font
color="#FF0000">13.04.2000,
24:00 IST</font> (about a week from now).
<br>Only full submissions will be considered. See more info exam submission
here.
<p>Pencil & paper solution of the exam is highly recommended. You may
find helpful hints
<br>and auxiliary programs <a
href="http://www.wisdom.weizmann.ac.il/~albi/cryptanalysis/homeworks.htm">here</a>
.
<p>Together with your submission please provide the some personal information:
<br> Name (or Nick): Tamerlan
<br>
Institution:
Kurultai
<br> Your Background in Crypto: "Introduction to Cryptology"
course by Zhengis Khan
<br>
Country:
White Horde
<p>It is up to you what information to provide about yourself, but note
that it will appear in your
<br>course graduation digital certificate.
<p>good luck,
<br>Alex.</html>
==============D20BDA3A1AB20424C03FD173==
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is this code crackable?
Date: Wed, 05 Apr 2000 13:46:27 GMT
In article <5owG4.81349$[EMAIL PROTECTED]>,
"Jethro" <[EMAIL PROTECTED]> wrote:
> I'm new to this subject, but I'd appreciate an experts opinion on
this.
>
> I've written a program that generates a "key" file. The key file is a
text
> file composed of 10,000 randomly-selected ASCII characters (character
codes
> 1 through 126, excluding the end of file character code 026). The
> characters were generated randomly using the CPU timer, mouse position
and
> current ocean water temp and barometric pressure inputs for randomizer
> seeding.
>
> To encrypt a plain text file (of less than 10,000 characters, ASCII
codes 1
> through 126), the ASCII value of each character of the text file is
added to
> the ASCII value of each character of the key file. This summed
character is
> then placed into the encrypted file. Therefore, the encrypted file
consists
> of the same number of characters as the unencrypted file and all the
> encrypted characters are ASCII character codes 127 through 256.
>
> To decrypt the encrypted file, the same key file is used, this time
> subtracting the key character from the encrypted character to obtain
the
> ASCII value of the original text file.
>
> 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?
The method you suggest is a typical example of how to mess up the
classic One Time Pad algorithm, making it breakable.
Why invent your own algorithm? There are plenty of secure encryption
algorithms which are public, including source code, which you could use
instead.
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Looking for some help on RSA public key/private key generation
Date: 5 Apr 2000 13:48:20 GMT
Tom St Denis <[EMAIL PROTECTED]>:
> Bob Silverman:
>> "Tom St Denis" <[EMAIL PROTECTED]>:
>>> Why do people say phi(N) when in your own paper you suggest to use lcm(p -
>>> 1, q - 1)?
>> Both work. LCM(p-1, q-1) will be slightly smaller.
> So wouldn't lcm(p-1, q-1) be better way to document RSA? It's more
> efficient, no more complex, etc...
I usually write lcm(p-1, q-1) rather than phi(pq); however,
this does not make RSA decryption or signatures more efficient: In
efficient implementations, you use the Chinese Remainder Theorem
anyway. Then d never explicitly appears as an exponent: The
intermediate values
x^d mod p and
x^d mod q
(which, according to the CRT, can be used to determine x^d mod pq)
can be computed as
x^(d mod p-1) mod p and
x^(d mod q-1) mod q,
respectively. Note that the residues d mod p-1 and d mode q-1
do not depend on whether you defined d as the inverse of e mod phi(pq)
or as the inverse of e mod lcm(p-1,q-1).
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Wed, 05 Apr 2000 08:11:15 -0600
Reply-To: [EMAIL PROTECTED]
Mok-Kong Shen wrote:
> John Savard wrote:
> >
> > (And, just as the entropy of numbers created by throwing dice is known
> > exactly, on an _a priori_ basis, the argument for the security of the
> > true one-time pad is not affected by the limitation on knowing the
> > entropy of _some_ types of sequence.)
>
> After reflecting a bit more about tossing a perfect coin, I
> believe there is a paradox whose explanation I don't yet know.
> If a perfect coin is tossed n times, it generates a bit
> sequence of length n. How much entropy should I ascribe to
> that sequence? Note that the result is one of the binary numbers
> in the interval 0 to 2^n-1. Each of these numbers has an equal
> chance of turning up in my experiment. Suppose by chance I get
> the number 0, i.e. all n bits are 0. Should I still consider the
> sequence to have some entropy and, in particular, the same
> entropy as a sequence having an apparently fairly random pattern
> of 0 and 1? Thanks.
>
> M. K. Shen
It's the process that is "random" not the sequence that comes from the
process. If the process is the usual "fair coin toss" then everything is OK.
Probability (in this sense) is a priori. One doesn't get 40 heads in a row
from an unbiased coin.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 05 Apr 2000 09:27:57 -0500
>
<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)?
------------------------------
From: "Keith Monahan" <[EMAIL PROTECTED]>
Subject: Re: DDJ Crypto cdrom (first edition)
Date: Wed, 05 Apr 2000 14:13:50 GMT
I haven't tried as I have the new version -- but have you tried
an alternative solution? Have you tried contacting the
people involved with making the CDROM about an upgrade?
For the cost of a CDROM, they might want to make an
existing customer happy.
Just a thought.
Keith
jean-baptiste.marchand <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi everyone,
>
> does anyone ever tried to convert the horrible proprietary format of
> the first edition of the DDJ Crypto cdrom in something more usable,
> HTML for example ?
>
> I konw that the new edition in in PDF but I have the old one and the
> hypertext reader interface is so horrible...
>
> Thanks for your help.
>
> Jean-Baptiste Marchand
> --
> [EMAIL PROTECTED]
> Gnome is object-oriented, it is fully boss-compliant
> (Miguel de Icaza, Linux Expo Paris, 2000/02/03)
------------------------------
Date: Wed, 05 Apr 2000 11:24:38 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > Anthony Stephen Szopa wrote:
> >
> > > Taneli Huuskonen wrote:
> > > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> > > > <[EMAIL PROTECTED]> writes:
> > > >
> > > > [...]
> > > >
> > > > >I'll ask you again: how many raw random digits from the random
> > > > >digit generator will you need? I will supply them. You can
> > > > >then give us what you have determined to be the subsequent
> > > > >raw random digits from the random digit generator.
> > > >
> > > > >Then I will provide the key for the software where we all can see
> > > > >that the random digits I gave you were in fact the ones generated
> > > > >from the software using this key.
> > > >
> > > > OK, fine - no BS, just the facts. However, I have trouble handling
> > > > very large files (I'd need a couple hundred million digits for
> > > > predicting the entire output stream), so I propose the following:
> > > >
> > > > You supply twenty blocks of a thousand consecutive digits each.
> > > > Between each block and the next, the "Rotation" is incremented by 10,
> > > > and the "Offset" is reset to zero. In other words, the starting digits
> > > > of two consecutive blocks are 10! * 10 places apart in the full output
> > > > stream of the random digit generator. You may start with any value for
> > > > the Rotation that you want; just make it known afterwards.
> > > >
> > > > You can make the digits available in any reasonable format: ASCII or
> > > > BCD, all the blocks concatenated in one large file or 20 small files,
> > > > zipped or not, made available by HTTP or FTP, or e-mailed to me.
> > > >
> > > > I will make a thousand predictions of this form: "The digit at Rotation
> > > > 234, Offset 43 is 5." If you can find one incorrect prediction, I've
> > > > failed. So, my chances of succeeding by chance are 1 out of 10^1000.
> > > >
> > > > Deal?
> > > >
> > > > Taneli Huuskonen
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: PGPfreeware 5.0i for non-commercial use
> > > > Charset: noconv
> > > >
> > > > iQA/AwUBOOjmAV+t0CYLfLaVEQJQHgCdGjNvXKyM32E4mP8dW74Q8i7YPDQAn0rD
> > > > 1Q6v3/9KiZOajAl/3FjT9CKU
> > > > =DbCx
> > > > -----END PGP SIGNATURE-----
> > > > --
> > > > I don't | All messages will be PGP signed, | Fight for your right to
> > > > speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> > > > the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
> > >
> > > You certainly realize that there is at least one person in this
> > > news group that actually thinks that the random digits from the
> > > random digit generator are used directly in the encryption
> > > process. This is because he hasn't a clue.
> > >
> > > There may even be some in this news group that think that the
> > > random numbers from 000 - 255 calculated directly from the random
> > > number generator are used directly in the encryption process.
> > > These people also haven't a clue.
> > >
> > > For any who need a lesson: first a random digit triplet is formed
> > > directly from the random digit generator. If this number is
> > > greater than 767 it is discarded. Otherwise this number is
> > > divided by 3 and the remainder is truncated. This and all
> > > subsequent random numbers from 000 - 255 calculated in this manner
> > > are then stored in RandOut files usually having a length of
> > > 18144000 binary bytes each. These several RandOut files are
> > > further processed repeatedly using as many as ten different
> > > processes. All processes use true random user input as parameters.
> > > Finally, these RandOut files are combined randomly in the OTPs again
> > > using true random user input. This is it in a nutshell. Read the
> > > documentation available in the Help Files for more details at
> > > http://www.ciphile.com
> >
> > Look. If your RNG is flawed it is flawed. Perhaps this multitude of steps
> > makes it harder to attack directly. My bet is you have an algorithim with a
> > complexity of attack in the neigborhood of the present AES cyphers -- maybe
> > worse. Justify why I should use your closed source product that does not
> > offer me more security than an AES algrotihim, offers less flexibility,
> > slower operation, less robust examination, poor documentation, and a poor
> > user interface vs Oh say PGP or even something like David Scotts ScottXu.
> > Make your case.
> >
> > >
> > >
> > > Let's now discuss your proposition strictly regarding the random
> > > digit generator (this is not a discussion about the OAP-L3 software
> > > as a whole.)
> > >
> > > First let me say this: everyone knows that computer software
> > > programs are entirely deterministic. Knowing the algorithm and
> > > the inputs you can predict the output before even running the
> > > process if you are so inclined. You can also go the other way.
> > >
> > > Regarding encryption software I like to think of there being an
> > > explicit key and an implicit key. It all depends on your point
> > > of view.
> > >
> > > The explicit key is the key I will use to create the three MixFiles
> > > that I will use as input to the OAP-L3 random digit generator
> > > software. Then I will generate the random digit streams you seek.
> > >
> > > The implicit key is what you will be forced to use. This key is
> > > the raw random digit output from the random digit generator.
> > > Theoretically you may be able to determine the original MixFiles I
> > > actually used. The more raw random digit output you have the more
> > > possible this becomes: perhaps a few hundred million (I doubt it)
> > > or a few hundred billion (possibly) or a few trillion (probably)
> > > raw random digits in sequence directly from the start of the random
> > > digit generator might do it exactly.
> > >
> > > Suppose I do this: I will give you 21 consecutive blocks of
> > > 3,628,800 digits. The software automatically will rotate and
> > > reset the increment to zero after each block. You just choose
> > > the first 1000 or 10,000 or 100,000, etc. digits as you like
> > > from each file. You can even check your results from the first
> > > 20 blocks with block 21. I will write these to a CD-R and mail
> > > it to you.
> > >
> > > At my option I would like three tests: this being the first.
> > > Just give me any address you like. I will try to get it in the
> > > mail to you within a week. Keep in mind that I am very busy
> > > trying to get this next OAP-L3 Version 4.3 out.
> > >
> > > Now, let us take a brief moment to think about your statement
> > > that there is a flaw in the random digit generator. You choose
> > > to call it a flaw. Think about this: we all know that computer
> > > software is deterministic. By analysis of the process and with
> > > enough output, anyone can determine subsequent output because
> > > you will have effectively determined the MixFiles. So you have
> > > done nothing but confirmed what we already had known (or should
> > > have known.)
> > >
> > > Next, you must agree, that the only way to exploit this fact is
> > > to have basically unlimited access to the raw random digit output
> > > of the random digit generator. How is anyone going to get this in
> > > a real life situation except like I am giving it to you now? If
> > > you could get the raw random digit output from the random digit
> > > generator you would certainly have access to the MixFiles or better
> > > yet, the AutoFile key itself. And possibly the final OTPs.
> > >
> > > So what are you proving that is detrimental to the security of the
> > > OAP-L3 system? You are merely solving a problem in simultaneous
> > > equations, or solving multiple equations with sufficient numbers
> > > of constraints (the raw random output from the random number
> > > generator.)
> > >
> >
> > >
> > > You could not do this unless I gave you the raw random digit output
> > > of the random digit generator in the first place. Are you next
> > > going to say that you can crack OAP-L3 encrypted messages if I
> > > give you the OTPs and then conclude that you have proven your
> > > statement and therefore OAP-L3 is flawed? Basically this is what
> > > you are saying and attempting to convince others of with this
> > > inconsequential "test."
> > >
> > > So, if you do manage to predict a few or all the random digits
> > > subsequent to the random digit stream I provide you with, so what?
> >
> > You claim that your crypto product is highly secure. You claim that any file
> > encrypted with it is secure, and if there is a useful attack vs. the
> > generator this means that in all likleyhood there is a useful attack vs. the
> > whole system. Yes it may not be "broken" by this, but the security provided
> > is MUCH less than the amounts claimed if there is a predictable hole in the
> > RNG.
> >
> > >
> > >
> > > You will have shown us nothing that anyone can use to crack the
> > > software or any of the encrypted messages using OAP-L3.
> > >
> > > Do you disagree? Why? How?
> >
> > Ever heard of a "Known Plaintext Attack"? It is a very basic concept.
> > Probably as old as cryptography itself. You intercept a message, and later
> > find out what it contains say from a prinout that you aquired or the like.
> > You then have raw stream output available for analisys as your stream cypher
> > is simply combined with the plaintext.
> >
> > >
> > >
> > > I do agree that you can at least show your employer that you have
> > > done something in the hopes of justifying your salary but
> > > unfortunately you have gotten no further to the goal of cracking
> > > the OAP-L3 software.
> > >
> > > Post the address.
>
> 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?
>
> Keep in mind that there is no way this data is going to be
> available in a real life situation.
>
> 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.
>
> You have refused to do your homework.
>
> I do not have any more time to spend with such an unmotivated
> pupil.
I think this software belongs in the FAQ "pour encourage les autres".
------------------------------
** 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
******************************
