Cryptography-Digest Digest #559, Volume #10 Fri, 12 Nov 99 18:13:03 EST
Contents:
Re: ENCRYPTOR 4.0 crack DEMO ([EMAIL PROTECTED])
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! ([EMAIL PROTECTED])
Re: Your Opinions on Quantum Cryptography (Anton Stiglic)
Re: Public Key w/o RSA? (DJohn37050)
Re: Public Key w/o RSA? (John Savard)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Patrick Juola)
Re: PALM PILOT PGP found here (Keith A Monahan)
Re: ENCRYPTOR 4.0 crack DEMO (JPeschel)
Re: RC4 in Kremlin US version 2.21 to tom st denis (Tom St Denis)
effect of password entropy on public key/ECC? (Bill McGonigle)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (fungus)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Nicolas Bray)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ENCRYPTOR 4.0 crack DEMO
Date: Fri, 12 Nov 1999 19:39:38 GMT
Ok let's try a little demo to show that Encryptor 4.0 is cracked.
First a known plaintext attack demo :
I have 3 files crypted with the same password with Encryptor 4.0
I know that the file : email.txt contains this : ( the header of an
email to me )
but the password used to encrypt the 3 files is unknow.
Delivered-To: [EMAIL PROTECTED]
it gives :
44 65 6C 69 76 65 72 65 64 2D 54 6F 3A 20 61 6C
65 78 61 6E 64 65 72 6D 61 69 6C 40 68 6F 74 6D
61 69 6C 2E 63 6F 6D
the ciphertext in the file email.txt.ecr is :
A5 85 CD 87 F5 B0 E4 B9 A2 32 CB B7 B7 40 A5 8E
A9 DB AF 9E 9D B0 D4 9E 81 DA EB 8F 73 77 C7 95
83 6A BE 35 6E BD DF
I substract each byte of the ciphertext to the plaintext
and it gives me the initial output of the stream cipher
of that key. ( example 0xa5-0x44 = 0x61,
0x85-0x65=0x20)
it gives ( this is the output of the stream cipher ) :
61 20 61 1E 7F 4B 72 54 35 05 77 48 7D 20 44 22
44 63 4E 30 39 4B 62 31 20 71 7F 4F 0B 08 53 28
22 01 52 07 0B 4E 72
You can see that the output of the stream cipher is only 7 bits
per byte ( not 8 )
Yet i can crack directly cracked the two other files :
a.txt.enc and b.txt.enc
a.txt.enc (ciphertext) :
B5 88 CA 91 9F B4 E5 74 9F 25 EB AD F0 94 64 8F
A9 D6 C1 91 A0 B0 82 83 79 C3 D8 A1 64 5A AC 35
2C 9D
I XOR this ciphertext with the output of the stream cipher,
it gives :
This is j test message RYRYRYRY
an error occurs for letter 'j', it should be 'a'
i don't know yet why but the soft seem to be cracked, no ?
I let you try to decode the file :
b.txt.enc (ciphertext) :
AA 40 D5 86 E8 B9 DD 74 B2 6D E0 BB 9D 93 B3 88
B8 83 B7 A3 59 AE D4 92 83 DC E4 B3 2B 29 60 32
Then Encryptor 4.0 cracked or not cracked ?? :))
For a ciphertext attack only, you can do as i described i an other post.
Even with only two ciphertexts with the same password, it can be broken.
As Jim Gillogly, he will explain this better than me.
You search in the two ciphertexts, probable words ...
Then Encryptor 4.0 cracked or not cracked ??
Alexander PUKALL
November 12, 1999
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 14:37:59 -0500
Reply-To: [EMAIL PROTECTED]
Coen Visser wrote:
>
> "james d. hunter" wrote:
>
> > It was never claimed that words are anybody's trademark.
> > It is suggested that the -same- word is better off -not-
> > being used in two completely different [contexts] simultaneously.
>
> Agreed.
>
> > [...] But, if you are implementing a dynamic system -digitally- :0), you
> > have to treat the mathematics as if it were a physical system,
> > if you want it behave correctly.
>
> And you have to consider the limits of computers if you want
> your model to behave correctly.
What makes you that computers have limits?
The fact that "scientists" sometimes misuse the concept
of limit. That's just philosophy that gets plowed under
as technology advances.
>
> > Theoretical Computer Science folks can do whatever they want, since
> > as far as I can tell, almost nothing they do concerns computers.
>
> I take it you are not a (theoretical) computer scientist.
Yes, that's correct. Theoretical computer scientists are
mostly philosophers also, since very little of what they
do concerns computers or science.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: Fri, 12 Nov 1999 19:38:38 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> fungus [EMAIL PROTECTED] writes:
>
> >JPeschel wrote:
> >>
> >> "Alexander PUKALL" [EMAIL PROTECTED] writes:
> >>
> >> >Why not cracked ??
> >> >Encryptor is a stream cipher with no salt key, then Encryptor is
dead.
> >> >
> >>
> >> I think you've found a faulty implementation, but you haven't
cracked the
> >> cipher, or for that matter identified it.
> >>
> >
> >Huh?
> >
> >Read the subject line "Encryptor 4.0 by Comotex.. .... cracked",
> >not "Algorithm XXX cracked"
>
> You read it. This guy hasn't cracked anything.
>
> Joe
>
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Your Opinions on Quantum Cryptography
Date: Fri, 12 Nov 1999 14:49:53 -0500
==============DB6B56373E8525E850CDD0FF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
John Myre wrote:
> Bill Unruh wrote:
> >
> > In <[EMAIL PROTECTED]> Jeremy Nysen <[EMAIL PROTECTED]> writes:
> >
> > >Also, quantum cryptography by itself doesn't prevent a middleman attack
> > >(though it does make it very difficult). Which means it should be
> >
> > Don;t confuse quantum crypto with quantum computing.
> > Also quantum crypto is immune to the "middleman" attack.
> > That is one of its strengths.
> >
> > >possible to set up a 'relay' box in between two communicating parties
> > >that pretends to be the other. You would still need a 'relay' box for
> >
> > No, that is exactly what quantum crypto prevents. Any such middle man
> > can be detected.
>
> It is my understanding that quantum crypto makes it impossible
> (well - arbitrarily unlikely) to eavesdrop passively, but that an
> active man-in-the-middle is still possible: Alice and Bob have no
> physical way to know who they are talking to. That is, Eve is
> out of luck, but Mallory is still in business.
>
> With normal communication methods, Mallory can replicate each
> side exactly, thus behaving as Eve. With quantum crypto, I
> think Mallory can no longer do this, as the information exchanged
> is only probablistic. Mallory can pretend to be Bob while
> talking to Alice, and pretend to be Alice while talking to Bob,
> but he cannot ensure that the two connections end up with the
> same session key.
>
> So in addition to quantum crypto, you still mathematical crypto
> to authenticate who you are talking to. (Even if we use the
> secure quantum crypto channel to ask about maiden names, proper
> authentication will require careful protocol design).
>
> John M.
Remember that quantum key exchange asks for classic authentification,
and thus we need a second channel. The attacker would have to be
able to authentic himself as Bob and as Alice..
--
___________________________________________
Anton Stiglic
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________
==============DB6B56373E8525E850CDD0FF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
John Myre wrote:
<blockquote TYPE=CITE>Bill Unruh wrote:
<br>>
<br>> In <[EMAIL PROTECTED]> Jeremy Nysen <[EMAIL PROTECTED]>
writes:
<br>>
<br>> >Also, quantum cryptography by itself doesn't prevent a middleman
attack
<br>> >(though it does make it very difficult). Which means it should be
<br>>
<br>> Don;t confuse quantum crypto with quantum computing.
<br>> Also quantum crypto is immune to the "middleman" attack.
<br>> That is one of its strengths.
<br>>
<br>> >possible to set up a 'relay' box in between two communicating parties
<br>> >that pretends to be the other. You would still need a 'relay'
box for
<br>>
<br>> No, that is exactly what quantum crypto prevents. Any such
middle man
<br>> can be detected.
<p>It is my understanding that quantum crypto makes it impossible
<br>(well - arbitrarily unlikely) to eavesdrop passively, but that an
<br>active man-in-the-middle is still possible: Alice and Bob have no
<br>physical way to know who they are talking to. That is, Eve is
<br>out of luck, but Mallory is still in business.
<p>With normal communication methods, Mallory can replicate each
<br>side exactly, thus behaving as Eve. With quantum crypto, I
<br>think Mallory can no longer do this, as the information exchanged
<br>is only probablistic. Mallory can pretend to be Bob while
<br>talking to Alice, and pretend to be Alice while talking to Bob,
<br>but he cannot ensure that the two connections end up with the
<br>same session key.
<p>So in addition to quantum crypto, you still mathematical crypto
<br>to authenticate who you are talking to. (Even if we use the
<br>secure quantum crypto channel to ask about maiden names, proper
<br>authentication will require careful protocol design).
<p>John M.</blockquote>
<p><br>Remember that quantum key exchange asks for classic authentification,
<br>and thus we need a second channel. The attacker would have to
be
<br>able to authentic himself as Bob and as Alice..
<pre>--
___________________________________________
Anton Stiglic <[EMAIL PROTECTED]>
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________</pre>
</html>
==============DB6B56373E8525E850CDD0FF==
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Public Key w/o RSA?
Date: 12 Nov 1999 19:56:24 GMT
For more info on elliptic curves, check out the white papers on ECC at
www.certicom.com.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Public Key w/o RSA?
Date: Fri, 12 Nov 1999 20:01:27 GMT
"Brian Greskamp" <[EMAIL PROTECTED]> wrote, in part:
>How many public-key crypto algorithms are there? I'm new to this, and I
>keep hearing about RSA, but are there others? And if so, then why is RSA in
>particular so popular?
Diffie-Hellman is another one, and it is more popular now, because its
patents have expired.
RSA, however, can actually be used to encrypt messages directly, while
Diffie-Hellman can only be used to produce an agreed-upon key for
encrypting a message using another (non-public-key) method. And RSA is
particularly easy to understand, although even it rests on some
complicated math.
And there are the newer elliptic-curve methods as well.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 20:23:33 +0000
"james d. hunter" wrote:
> > And you have to consider the limits of computers if you want
> > your model to behave correctly.
> What makes you that computers have limits?
Does "Halting problem" ring a bell?
> The fact that "scientists" sometimes misuse the concept
> of limit. That's just philosophy that gets plowed under
> as technology advances.
I'd really love to see them plow under the "Year 2000 problem" with
technological advances. A typical example of non-existing limits;
just add some memory, that will solve it. After that one is gone they
may
plow under the software crisis, with its 25-50% failed software
projects. Using just faster computers software will finally be
delivered on time and on budget. Let's tackle long range weather
forecasting and climate modelling. Even the tiniest difference between
our model and the real world and the two will diverge before
you can say: "we need infinite precision so we can calculate
with *real* real numbers."
> > I take it you are not a (theoretical) computer scientist.
> Yes, that's correct. Theoretical computer scientists are
> mostly philosophers also, since very little of what they
> do concerns computers or science.
I see. Shall we quit this thread?
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 12 Nov 1999 15:31:28 -0500
In article <[EMAIL PROTECTED]>, Coen Visser <[EMAIL PROTECTED]> wrote:
>"Trevor Jackson, III" wrote:
>
>> If you admit all finite strings there are no strings you can compress. Anything
>you compress
>> will displace (inflate) the string originally represented by the compressed
>representation.
>> I.e., you can only compress a subset of all finite strings at the expense of
>inflating another
>> subset. Further, the sum of the new lengths of the strings in the two subsets will
>be larger
>> than the sum of the old lengths.
>
>Keep in mind that compression is defined + O(1). So I allow for
>some overhead of a Turing Machine definition. Now I can compress all
>finite length strings of form "0101010101010101..." by preceding
>a string by a "0" if it doesn't have this form and "1" if it does
>have the special form. After "0" I copy the original string, after
>"1" I encode the number of "01" repetitions.
>
>> Losing game.
>
>I have just compressed infinitely many strings of a special form
>"010101..." and left all other strings untouched (+O(1)).
Howevever, that's *NOT* how compression is defined. If you were
to talk to one of the hard-core compression theorists like Ian
Witten and tell him that "compression is defined as +O(1)", you
would most likely get a reaction somewhere between a contemptuous
stare of disbelief and a painstaking, patronizing, monologue about
what "real compression" is.
Yes, you can define compression in terms of Universal Turing machines.
You can also define compression in terms of a permutation of the
set of strings (a mapping from (Sigma)* onto itself) and "expected length,"
which is a more common, useful, and natural definition -- and yields
a completely different set of properties.
>> > That sounds very useful. How would you use the definition and underlying
>> > theory to show that a RNG is not a TRNG?
>
>> Find some correlation in the behavior of the generator, predict its continued
>appearance,
>> confirm the prediction by further testing, and conclude that, within the confidence
>of the
>> test, the generator lacked randomness in at least the degree of correlation.
>
>So, you're use statistical tests. It happened to be proved that a string
>that passes all [*] statistical tests within the required confidence
>level
>is incompressible (and random because it passed the tests). So our
>definitions
>start to look dangerously equivalent.
*HOWEVER*, the output of a random coin-flipper is not necessarily
random in the Kolmogorov-Chaitin sense (it's random with probability
one, but that's *NOT* equivalent, thanks). Nor is it the case that
a number random in the Kolmogorov-Chaitin sense was generated by
the output of an appropriately random process (although, again,
it's true with probability 1 in the infinite case). Unfortunately,
any finite approximation will yield a finite probability of
disagreement.... and even in the countably infinite case, there
are still an infinite number of potential counterexamples.
So K-complexity yields *a* definition of randomness. However, the
definition it yields is neither a standard definition, equivalent
to a standard definition, nor particularly useful.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Crossposted-To: alt.security.pgp,comp.sys.palmtops.pilot
Subject: Re: PALM PILOT PGP found here
Date: 12 Nov 1999 20:41:18 GMT
Thanks John for pointing that out.
I thought that may be the case. I should have noted too that
this archive is only accesible from the US and Canada.
If that link does not work,
go directly to http://www.cryptography.org, answer the 3 questions
appropriately, go to the main index, select pgp under the
"Directories" heading, and then click the last entry on that list,
"palmopgp"
Keith
John Savard ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] (Keith A Monahan) wrote, in part:
: >http://cryptography.org/crypto/hnKpw9sv/pgp/palmopgp/
: Probably the name of the directory "hnKpw9sv" changes each day or
: hour: since the archive is North American, this may be part of
: compliance with export controls.
: Thus, one should go to their main page, rather than attempting to go
: directly to an URL in this form.
: John Savard ( teneerf<- )
: http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: ENCRYPTOR 4.0 crack DEMO
Date: 12 Nov 1999 20:46:46 GMT
[EMAIL PROTECTED] writes:
>For a ciphertext attack only, you can do as i described i an other post.
>Even with only two ciphertexts with the same password, it can be broken.
>As Jim Gillogly, he will explain this better than me.
>You search in the two ciphertexts, probable words ...
>
>Then Encryptor 4.0 cracked or not cracked ??
Not until you write a dedicated cracker that needs only one
ciphertext. From the sound of what you and Lyal have said you
shouldn't even need a probable word as your crib.
You can find examples, by Casimir, on my site and on Pavel's.
Goodluck, Al.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC4 in Kremlin US version 2.21 to tom st denis
Date: Fri, 12 Nov 1999 20:41:21 GMT
In article <80fe6d$b3o$[EMAIL PROTECTED]>,
"Alexander PUKALL" <[EMAIL PROTECTED]> wrote:
> He Tom, i don't say that RC4 is like VIGENERE i say that the
implementation
> of RC4 in KREMLIN with RC4 with CBC encryption mode not slected, is
INSECURE
> because it's like a Vigenere cipher.
> I speak about a bug in the implementation in Kremlin, no the cipher
itself
>
> Download Kremlin and try and you will confirme yourself !!
>
> If to report a bug is spamming, ok then i'm spamming :)
RC4 does not have an CBC mode, it's an RNG damnit.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill McGonigle)
Subject: effect of password entropy on public key/ECC?
Date: Fri, 12 Nov 1999 14:58:02 -0500
Reading Dr. Dobb's article on ECC, and the relative difficulty of
attacking a ECC system with a given key length vs. a public key system
with the same key length, the following occured to me:
If a password has n bits of entropy and the key size of an ECC system is x
and the key size of a public key system is y, does the ratio x/n vs. y/n
have a practical effect on the ease of attacking the system?
Or are the rest of the bits sufficiently random that it doesn't matter?
Thanks,
-Bill
=====
[EMAIL PROTECTED] / FAX: (419) 710-9745
Dartmouth-Hitchcock Medical Center Clinical Computing
------------------------------
From: fungus <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 19:20:08 +0100
John Savard wrote:
>
> You are correct here, as far as that goes.
>
> However:
>
> - there is a relationship between randomness and incompressibility.
> Given a properly random - or shall I be highfalutin' and say
> "stochastic" - message source, its output will be incompressible;
> there will be no net benefit in attempting to compress the occasional
> accidentally patterned output from it.
>
Not true.
Imagine I set up a radioactive decay gadget, which has an
average of one decay every ten seconds. I then sample the
device every second, outputting a 1 if there was a decay
and a 0 otherwise.
The output data will be very compressible, but It's also
truly random.
(The output of most "true" random number generators is
hashed for this reason. The output may be random, but
it's not much use for cryptography.)
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Nicolas Bray <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 13:21:43 -0800
On 9 Nov 1999 [EMAIL PROTECTED] wrote:
> No, the Borwein-Bailey-Plouffe algorithm is real. That a method for
> decimal digits exists, if that is true, is new news that not everyone has
> heard of yet.
>
> John Savard
It is extremely old news. I posted a message about it around a year ago.
------------------------------
** 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
******************************
