Cryptography-Digest Digest #490, Volume #11 Wed, 5 Apr 00 01:13:01 EDT
Contents:
Is this code crackable? ("Jethro")
Re: Massey-Omura protocol & ECC ([EMAIL PROTECTED])
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - (Tom St
Denis)
Re: Key exchange using Secret Key Encryption ([EMAIL PROTECTED])
Re: NSA ([EMAIL PROTECTED])
BBS again (Tom St Denis)
Re: Is this code crackable? (Yoman Liker)
Re: Crypto API for C (Tom St Denis)
Re: Is this code crackable? ("Ross Smith")
Re: rc-5 plaintext guess. ("krale")
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is trying
to silence our program? It's not working...) (pgp651)
*** FREE DSL **** ("Richard Burton")
Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...) (RotGut)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: "Jethro" <[EMAIL PROTECTED]>
Subject: Is this code crackable?
Date: Tue, 4 Apr 2000 18:09:59 +0100
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?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Massey-Omura protocol & ECC
Date: Wed, 05 Apr 2000 02:07:47 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
>
> I originally thought it made it impossible too, but it ain't so.
Let's
> take Harry, Ron and Malfor (from Harry Potter, my kids love it) and
> Harry
> trys to send a key to Ron with Malfor in the middle. Harry has e_h,
> d_h,
> Ron has e_r, d_r and Malfor has e_m, d_m. Harry sends to Ron, but
> Malfor
> intercepts. (e*d = 1 mod p) Let's see what happens:
> Harry Malfor Ron
> 1) e_h*P_h = P1 -> M e_m*P_m -> R
> 2) e_m*e_h*P_h <- M e_r*e_m*P_m <- R
> 3) d_h*e_m*e_h*P_h -> M d_m*e_r*e_m*P_m -> R
>
> at this point, Malfor can get the message P_h and Ron has the message
> P_m.
> So the man-in-the-middle can intercept the original message but has to
> fake
> it to the true receiver. If it's a private key, then Malfor knows
both
> keys and neither side knows they are compromised. Bad news.
>
> Koblitz proposed using digital signatures to solve this problem in "A
> Course in Number Theory and Cryptography". This means you have to
send
> much more data the first time since there are 2 components to the
> signature
> as well as the data being sent. However, since Massey-Omura uses a
> curve of
> known parameters, and you've got to use integer math to get the e and
d
> values,
> you have all the code subroutines. So Harry first sends P1 and the
> digital
> signature of the message burried in P_h. At the end, Ron can check if
> the
> signature matches. Since he has P_m and not P_h, it won't check.
>
> This whole thing is one way. So to eliminate man-in-the-middle you
have
> to send 2 keys, one from Harry to Ron and one from Ron to Harry.
>
> I'm not sure it's worth worrying about really. The number of people
> using
> Diffie-Hellman which is far easier to compromise is rather high. If
you
> really think MITM attacks are feasable for your application tho, you
> need
> to worry about it.
>
> Look at MQV too. No patents have been issued yet, but be ready to
yank
> the
> code if ever does :-)
>
> Patience, persistence, truth,
> Dr. mike
>
Thanks very much for yout response. It will probably take me several
days to digest it all :)
About MQV I found this patent
US5933504: Strengthened public key protocol
Assigned to the three of them. I have not read the patent, but I think
this might be it. Too late I'm afraid.
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator -
Date: Wed, 05 Apr 2000 02:26:50 GMT
anonymous wrote:
>
> On 4-Apr-2000, "xyz" <[EMAIL PROTECTED]> wrote:
>
> > Instead of using your commercial product, I use BC Wipe which is free from
> > http://www.jetico.com/ . Runs on Win9x, ME & 2K.
>
> Shredding the files isn't the only problem. EE does a whole more!
Whoopy, and it has bells and whistles.
This is not a forum for commercial software. either give out a freeware
copy documenting how it's secure, or stop spamming.
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key exchange using Secret Key Encryption
Date: Wed, 05 Apr 2000 02:51:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote in part:
>
>
> That is only true if you have another channel to verify that your
> intended recipient got your first message before you replied to the
> second message. A man in the middle could still execute the complete
> protocol with you, then pass the message along by executing the
> complete protocol with the recipient.
>
> John Savard (jsavard<at>ecn<dot>ab<dot>ca)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
In another thread in sci.crypt Mike Rosing offered the following
comment. I've copied it over for easy reference. If you wish to read
the while thread please refer to thread : Massey-Omura Protocol & ECC
I quote :
"I originally thought it made it impossible too, but it ain't so.
Let's
take Harry, Ron and Malfor (from Harry Potter, my kids love it) and
Harry
trys to send a key to Ron with Malfor in the middle. Harry has e_h,
d_h,
Ron has e_r, d_r and Malfor has e_m, d_m. Harry sends to Ron, but
Malfor
intercepts. (e*d = 1 mod p) Let's see what happens:
Harry Malfor Ron
1) e_h*P_h = P1 -> M e_m*P_m -> R
2) e_m*e_h*P_h <- M e_r*e_m*P_m <- R
3) d_h*e_m*e_h*P_h -> M d_m*e_r*e_m*P_m -> R
at this point, Malfor can get the message P_h and Ron has the message
P_m.
So the man-in-the-middle can intercept the original message but has to
fake
it to the true receiver. If it's a private key, then Malfor knows both
keys and neither side knows they are compromised. Bad news.
Koblitz proposed using digital signatures to solve this problem in "A
Course in Number Theory and Cryptography". This means you have to send
much more data the first time since there are 2 components to the
signature
as well as the data being sent. However, since Massey-Omura uses a
curve of
known parameters, and you've got to use integer math to get the e and d
values,
you have all the code subroutines. So Harry first sends P1 and the
digital
signature of the message burried in P_h. At the end, Ron can check if
the
signature matches. Since he has P_m and not P_h, it won't check.
This whole thing is one way. So to eliminate man-in-the-middle you have
to send 2 keys, one from Harry to Ron and one from Ron to Harry.
"
It would seem that Massey-Omura Protocol coupled with the DS would at
least allow a detection of intrusion if not the security against
intrusion. I will now have to go look up the book suggested by Mike to
understand it better.
Thank you for you time, as well as others whom have replied.
Petang
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NSA
Date: Wed, 05 Apr 2000 03:02:14 GMT
In article <
[EMAIL PROTECTED]
om>,
Johnny Bravo <[EMAIL PROTECTED]> wrote:
> On Tue, 04 Apr 2000 03:52:47 GMT, [EMAIL PROTECTED] wrote:
> >necessary). It's illegal for the NSA to spy on
> >Americans living in the U.S., and, thus, it
> >might be illegal for them to gather potentially
> >incriminating intel from or about Americans
> >here who are using the Internet, usenet, etc.
> >Perhaps Britain, e.g., does collect the intel and
> >shares some of its findings with the U.S.
>
> But nothing prevents other three letter agencies from doing so.
> The FBI would probably be interested, and due to the public nature
> of the net they wouldn't even have to worry about getting a warrant
> to read posts from people they have an interest in.
>
IIRC, there are rules which prevent or limit
the scope of the CIA's domestic operations but
I've heard the FBI examines usenet, etc. for
leads. The FBI assumes (sometimes correctly)
that there will be a few hackers, for example,
who will not be able to resist the urge to
boast about their exploits.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: BBS again
Date: Wed, 05 Apr 2000 03:11:32 GMT
Now that I know a little more about num theory. I want to ask how the
BBS works. I will explain what I know.
p, q = primes congruent to 3 mod 4
n = pq
phi(n) = (p - 1)(q - 1)
X[0] = num rel prime to n
To gen next output compute
X[i] = X[i - 1]^2 mod n
To seek compute
a = 2^i mod phi(n)
X[i] = X[0]^a mod n
What is the period of this generator?
Do p and q have to be p- and q- strong?
Thanks.
Tom
------------------------------
From: [EMAIL PROTECTED] (Yoman Liker)
Subject: Re: Is this code crackable?
Date: Wed, 05 Apr 2000 03:17:52 GMT
"Jethro" <[EMAIL PROTECTED]> wrote:
>It works, but of course it requires one to physically give the key file to
>someone else.
What you're calling a "key file" is known as a "PAD".
>My question is, is it possible to crack this type of code
>without having the key file? I can't think of a way.
There's a catch - you can only use the pad "ONE TIME".
>Is this a well-known technique?
Yes, and I'll bet you'll never guess what it's called.
--
"Yoman Liker" is actually 2678 430519 <[EMAIL PROTECTED]>.
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Crypto API for C
Date: Wed, 05 Apr 2000 03:27:42 GMT
Mike Rosing wrote:
>
> Tom St Denis wrote:
> >
> > I simply can't believe it. About 100 people have downloaded cb.zip from
> > my website, and no comments, suggestions or problems. Am I just that
> > good of a library writer or are some people shy?
>
> Hey, be happy they at least looked at it! If it works like you said,
> then
> there's no reason to send feedback. "No news is good news" you know?
> Hang
> in there and keep learning.
Yup I always am. I released another update of the library today.
Includes a better implementation of BBS, fixed IDEA.H file, another
example, better rng code [RNG.C]...
If anyone wants to check it out, it's at
http://24.42.86.123/cb.html
And I don't mind 'good' feedback :-)
Thanks,
Tom
------------------------------
From: "Ross Smith" <[EMAIL PROTECTED]>
Subject: Re: Is this code crackable?
Date: Wed, 5 Apr 2000 15:44:50 +1200
"Jethro" <[EMAIL PROTECTED]> wrote in message
news:5owG4.81349$[EMAIL PROTECTED]...
> 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.
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.
> 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?
It *resembles* a well-known technique called the "one-time pad", which
is known to be unbreakable provided the proper precautions are followed
carefully. But I'm afraid your version has two critical flaws.
First, you're not using *real* random numbers (generated by some random
physical process such as radioactive decay), but only pseudo-random
numbers (yes, I know the *seed* comes from physical processes, but I'm
afraid that's not good enough). The seed for your PRNG is effectively
the real key to your cipher, since the entire key file can be
regenerated from the seed alone. If each of the four input values you
mention comes as a 32-bit integer, then the key can have no more than
128 bits, making it (if all else was equal) equivalent in security to a
reasonably good modern commercial cipher.
(Actually, I suspect you're not really getting 128 bits of key; most
simple PRNGs use 32-bit integers, so I suspect you're doing something
like adding or XORing the inputs rather than concatenating them, giving
you only 32 bits of real key. If you're using the rand() and srand()
library functions it's even worse, because the most common
implementation delivers only 15 bits (and is a lousy PRNG to boot).)
Second, the plaintext and key include characters 1 to 126 only, whereas
the ciphertext includes characters 2 to 252. This means it leaks
critical clues to the plaintext value of each character. For example, if
a character in the ciphertext is, say, 240, then I know the
corresponding plaintext character must have been in the narrow range 114
to 126 (it can't be less than 114 because that would require a key
character greater than 126, which never happens). It would be easy to
write a program that could crack a message by listing the possible
values for each character and working out which combinations made sense.
--
Ross Smith <[EMAIL PROTECTED]> The Internet Group, Auckland, New Zealand
========================================================================
"So that's 2 T-1s and a newsfeed ... would you like clues with that?"
-- Peter Da Silva
------------------------------
Reply-To: "krale" <[EMAIL PROTECTED]>
From: "krale" <[EMAIL PROTECTED]>
Subject: Re: rc-5 plaintext guess.
Date: Tue, 4 Apr 2000 23:12:49 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
These are very wise words ( if generalized ); only if people would listen
to them. I know many a newsgroups that this would help.
Krale
lordcow77 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Regardless of how stupid the original poster's statement was, it
> is not very pleasant to tell him to "go back to school junior"
> You imply without evidence certain characteristics that he may
> or may not possess. People on this newsgroup have been very
> tolerant of the mistakes and inaccurate statements that you have
> made in the past and sometimes still make as you are learning
> about cryptography. Please do other the same courtesy that was
> provided to you.
>
> By the way, in standard English syntax, sentences begin with
> capital letters.
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion
> Network * The fastest and easiest way to search and participate in
> Usenet - Free!
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBOOq9QJ4N7GovN66ZEQKeWQCfcP81ZMUfLRKx3xSzG4j7LIgj6a4AoM4E
/N/8EOU5pagF8eyo+tkR+EBP
=y7Hy
=====END PGP SIGNATURE=====
------------------------------
Date: 5 Apr 2000 03:43:08 -0000
From: pgp651 <Use-Author-Supplied-Address-Header@[127.1]>
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who is
trying to silence our program? It's not working...)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
What is the value of your challenge ?
On Mon, 03 Apr 2000, Thor Arne Johansen <[EMAIL PROTECTED]> wrote:
>
>I would challenge anyone to produce evidence that overwritten data, can
>be recovered.
>
>Thor Arne Johansen
------------------------------
From: "Richard Burton" <[EMAIL PROTECTED]>
Subject: *** FREE DSL ****
Date: Tue, 4 Apr 2000 21:20:36 -0700
Winfire is now offering free DSL (Published in Forbes and The Wallstreet
Journal).
Also available for a limited time is a
free DSL Modem through Broadband Digital Group.
Internet connections can be >>7X current speeds!
Click on the address below to go to Winfire's site for details of joining:
http://i.winfire.com/s/isapiEng.dll/wf.exe?cmd=rl&508,130023193&wf.exe
------------------------------
From: RotGut <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Magnetic Remenance on hard drives. (was: Re: Evidence Eliminator - Who
is trying to silence our program? It's not working...)
Date: Wed, 05 Apr 2000 00:39:16 -0400
"anonymous" <[EMAIL PROTECTED]> wrote:
>yeah, I keep phosphorous flares handy myself. Just like the US gov embassies.
Is that what they're using now? IIRC, when I was in the military a common
practice was to keep a thermite grenade atop steel file cabinets and/or safes.
If the call ever came to bug out in a hurry, just pull the pin, pop the spoon
and the molten slag would burn through the steel storage container igniting any
contents inside.
It would be interesting to see what a few ounces of thermite (iron oxide,
aluminum and magnesium igniter) would do to a 30 gig Seagate, (purely in the
interest of science and national security, of course).
>On 3-Apr-2000, Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>> BTW burning the hard disk at 1000c is still much more effective then any
>> software :-)
>>
>> Tom
>
>
>
>______________________________________________________________
>Posted via Uncensored-News.Com, http://www.uncensored-news.com
> Only $8.95 A Month, - The Worlds Uncensored News Source
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Tue, 04 Apr 2000 21:52:54 -0700
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.
------------------------------
** 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
******************************
