Cryptography-Digest Digest #571, Volume #10 Mon, 15 Nov 99 19:13:03 EST
Contents:
Re: AES Candidate Specs? (John Savard)
Enigma simulator ?? (Neil Bell)
Re: Washington Post article on drug traffickers use of encryption (Medical
Electronics Lab)
Re: Elliptic-curve cryptography (Doug MacKay)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
Re: Washington Post article on drug traffickers use of encryption (SCOTT19U.ZIP_GUY)
Re:SCOTT16U SOLUTION ON THE WEB (SCOTT19U.ZIP_GUY)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (fungus)
Re: Washington Post article on drug traffickers use of encryption ("Douglas A. Gwyn")
Re: Short replacement for assymetric algorithms for authentification ("Gary")
Re: Short replacement for assymetric algorithms for authentification (John Savard)
Re: EncryptedChat V2 Dead ? (greenjh)
Sv: Tell me about GOST algorythm... ("wOODY")
Re: SCOTT16U SOLUTION ON THE WEB ("Douglas A. Gwyn")
Re: Washington Post article on drug traffickers use of encryption (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES Candidate Specs?
Date: Mon, 15 Nov 1999 17:25:01 GMT
[EMAIL PROTECTED] wrote, in part:
>I have downloaded and read all 6 AES candicates specifications. The
>only one that I can understand is the RC6, I was actually able to write
>the code to perform the algorithm. The other 5 seem to be written in
>the same format which I obviously do not understand. Is there any other
>documents that describe the other algorithms from a software angle that
>might help me. Am I the only one that can't read these other specs?
My web site contains descriptions of some of the AES candidates, that
I put in my own words. I tried to make them easier to understand, and
included diagrams in some cases. (I found MARS not to be too hard to
understand, but some of the others were more difficult.)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Neil Bell <[EMAIL PROTECTED]>
Subject: Enigma simulator ??
Date: Mon, 15 Nov 1999 09:20:33 -0800
IS there is a freeware enigma simulator avaialbel on the web anywhere?
Something simple like a 3-rotor??
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Washington Post article on drug traffickers use of encryption
Date: Mon, 15 Nov 1999 11:45:09 -0600
* wrote:
> Does the 24 hour computer runtime to decrypt a message
> enable one to make any assumptions?
Either the story is bogus, like all the other DEA crap,
or the drug lords need a lesson in how to pick larger
key sizes!
>
> Anything else heard about this?
Nope, given the source it's a planned "leak" designed to
get money for political purposes. Situation normal :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Doug MacKay <[EMAIL PROTECTED]>
Subject: Re: Elliptic-curve cryptography
Date: Mon, 15 Nov 1999 17:43:35 +0000
> > Do anyone know the application ,the theory and the source code of
> > Elliptic-curve cryptography ?
>
> The source code? Oh yeah, you want some buzzword compliant crypto to
> throw in your application to meet a checklist you probably don't
> understand.
Perhaps you could relax a bit before flaming people. Sure, if he was
planning on just pasting the code into a program then you have a right
to complain. Fortunately there is a good chance this is not the case.
For people who have been programming for a while it is often _very_
helpful to see an algorithm implemented in their favorite programming
language. Seeing such examples can often make the strangest ideas
perfectly clear.
-doug
------------------------------
Date: Mon, 15 Nov 1999 13:24:21 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Coen Visser wrote:
> "Trevor Jackson, III" wrote:
>
> > I was not referring to your constant O(1). I believe it to be irrelevant to the
> > claim you made of compressing all strings of the form "01"*.
>
> > Your proposal was to prepend a code bit to every possible string indicating whether
> > the remainder should be interpreted literally or as a repeat count for "01". You
> > claimed that this constituted compression of the set of strings of the form "01"*.
>
> > I observed that the cost of any such compression distributed over the universe of
> > all strings was larger than the space saved. Only by considering the probabalistic
> > properties of the source would compression be useful.
>
> Yes, because I only compressed strings of the form "01"* and not all
> other
> compressible strings. I fully agree that you can only compress a string
> if
> you have thorough knowlegde of its structure. This does not mean that
> you need
> to know the probabilistic properties of the source. Any compression
> program in
> use uses the statistical properties of the string it compresses. So it
> uses
> information inherent in the string.
Not quite. Every existing compression program has some kind of source model. For
instance, adaptive dictionary methods that replace repeated substrings with references
to
previously found strings all have a window or dictionary size that depends upon the
expectation of the number and/or length of patterns worth entering into the dictionary.
For those with a limit on the number of patterns, a sequence composed of limit+1
repeated
subsequences would not be compressed at all. Such a sequence would fall outside the
model of the expected source.
For dictionaries with a maximum length entry, a sequence containing only of
contantenation os a subsequence who length is lenmax+1 would not be compressed at all
because the sequence would fall outside of the model of the expected source.
> > This distinction is based on the difference between compressing one string and
> > compressing a set of strings. The single string compresses to nothing. A set of
> > strings worst case compression (uniform distribution) is logarithmic on the
> > cardinality of the set. A set of strings best case compression (probabalistic
> > model) is identical to the Shannon Information contained in the set of strings.
>
> > Thus, unless you amplify your treatment of compressibility to include sets of
> > strings, you are only dealing with the degenerate case of single strings. And
> > there are no incompressible single strings.
>
> I am dealing with the (infinite) set of *all* finite strings. All
> popular
> compression algorithms in use are defined on strings of arbitrary
> length.
> All I am saying in this compression argument is: use the most optimal
> compression method to compress a specific string. If you are compression
> a text use Winzip, if you are compressing a bitmap use GIF et cetera.
> In theory you use of course an even better but unspecified optimal
> method,
> but that is not important for the argument. I want to abstract from any
> specific method.
OK, if your input can be any finite string and you get to choose your UTM to match the
properties of each individual string, then the binary quality "compressibility" is not
a
figure of merit. The UTM representation of some strings is smaller than the raw bonary
of the string. The UTM representation of other strings is larger than that of the
binary
string. Dividing strings into two categories "compressible" and "incompressible"
implicitly assumes that the shortest representation of an incompressible string is the
string itself. But it's not. The shortest representation of an "incompressible"
string
is _longer_ than the string itself due to the overhead of the UTM representation.
One could set the division point between "compressible" and "incompressible"
arbitrarily. Trivially there will be strings whose UTM representation is the same
length
as their binary representation. The definition of "compressible" might include those,
or
leave them out. (c.f. RLE-style encoding of both flavors).
If the strings whose length are the same in binary and UTM representations are defined
as
"incompressible" then there is some non-zero minimum degree of space gain that
qualifies
a string as compressible. There is no reason to set this threshold at a single bit.
One
could set it at 50% with as much justification.
Only when considering the utility of the transform to UTM representation is there value
is setting the threshold to a single bit -- space gain > 0. But considerations of
utility require a source model. If you expect a uniform distribution over all finite
strings this definition of compressibility is not useful because on average the size of
the UTM versions of the strings is larger than the size of the binary versions. If you
have a non-uniform distribution the UTM overhead increases with the non-uniformity.
Note also that the UTM representations treated as binary strings are extremely far
from a
uniform distribution. They must halt because you stated the universe of interest
included only finite strings. Thus not all UTMs will be suitable. It is undecidable
which are suitable and which are not in the general case. But there are specific cases
that are clearly unsuitable: "state1: write zero; goto state1;". Excluding these cases
lowers the information density of the UTM representation of strings, and thus makes
them
unsuitable as random numbers.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Washington Post article on drug traffickers use of encryption
Date: Mon, 15 Nov 1999 19:47:16 GMT
In article <80penv$oma$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (*) wrote:
>x-no-archive: yes
>
>from
>
>http://www.washingtonpost.com/wp-dyn/articles/A64-1999Nov14.html
>
>=========
>
>U.S. and Colombian officials found the traffickers were
>making use of the latest technology to protect and advance
>their business. Bernal's operation kept in touch by using
>Internet chat rooms protected by firewalls that made
>them impossible to penetrate, officials said. In addition,
>each part of the operation fed its information on the day's
>sales and drug movements to a computer on a ship off the
>coast of Mexico, the officials said, so that if one computer
>were taken down, it would be impossible to trace the rest of
>the network.
>
>
>The traffickers also had access to highly sophisticated
>encryption technology, far beyond what law enforcement has
>the capacity to break quickly, sources said. One U.S.
>official said it took some of their best computers 24 hours
>to crack a 30-second transmission by the traffickers,
>making the exercise pointless. They also used sophisticated
>cellular phone cloning technology, stealing numbers that
>were already assigned to legitimate users, using them for a
>short period of time, then moving on to new numbers.
>
>=========
>
>It appears from the entire article that the
>hardware/software used was off the shelf. What encryption
>products are available for use in phones? Private key/
>Public key. Does the DEA & FBI maintain their own code
>breaking units or is it reasonable to guess they farmed out
>the work to NSA? Other news recently seemed to indicate
>that Congress gave the FBI some money to start their own
>code cracking unit, but I thought that would not start until
>next year. Any guesses if that will be a waste of money?
>
>Does the 24 hour computer runtime to decrypt a message
>enable one to make any assumptions?
>
It means that the story is most likely bogus.
Or they are using NSA approved code such as any of the
AES candidtes that the goverment is pretending to be safe.
But the US would never admit to breaking code with in 24
hours so I guess I would go with the bogus story.
>Anything else heard about this?
>
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Mon, 15 Nov 1999 19:41:04 GMT
In article <[EMAIL PROTECTED]>, Anonymous User
<[EMAIL PROTECTED]> wrote:
>It is well known that ECB mode is week and not recommended for use with
>Block ciphers. However CFB and CBC are stronger and more complex. Which
>Mode are you using for your analysis of aes? ECB? If so, yes, your
>results would make sense....try using the more complex modes...
>
obviously you have not tried what I said since your anwser makes little sense
the work I did was based on CBC which does have the weaknesses I describled.
Since you don't seem to know this I assume you have never got off your ass to
test this.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: Mon, 15 Nov 1999 17:40:27 +0100
JPeschel wrote:
>
> He has found a weakness that can be exploited. In order to
> fully crack this program, he needs to fully understand the
> encryption algorithm and write a dedicated cracker.
A vanilla stream cipher cracker will do it. Nothing special
is needed for this particular program.
> He has, however, found a pretty good attack, one that I think
> can be developed so that is requires only one ciphertext.
This is exactly what he hasn't found - a shortcut to brute
forcing. I presume a brute force attack is as slow as ever.
What he has found is a massive weakness in the system. If
somebody has a bunch of files encrypted with the same password
then their security is practically zero.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Washington Post article on drug traffickers use of encryption
Date: Mon, 15 Nov 1999 20:42:13 GMT
John Savard wrote:
> "Highly sophisticated encryption"..."far beyond"...
Don't read too much into news-media reports.
They hardly ever get technical points right.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Short replacement for assymetric algorithms for authentification
Date: Mon, 15 Nov 1999 21:49:14 -0000
Mind you even a 128 bit authorization code, about 25 5 bit characters is
less than a 512 bit signed message. You could get away with less than 128
say 96 even.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Short replacement for assymetric algorithms for authentification
Date: Mon, 15 Nov 1999 22:11:37 GMT
Alex Birj <[EMAIL PROTECTED]> wrote, in part:
>>Won't work. Your program can always be disassembled. If you can
>>generate the key, so can they.
>The program won't have a key, it will apply a supplied key to given
>ciphertext contained withing the program code and compare the
>result with the given text. So disassembling won't reveal the key
>and a key generator cannot be produced, so changing program code
>will be needed to make it work (but this is another question).
But then you either have to make a custom version of your program for
every customer, or you cannot generate keys any better than the
hackers.
If the key is a function of the serial number plus the activation key
- if this is the model you're using - then while a hacker would need
one good serial number/activation key to find the desired output from
the security procedure, the hacker could still use the other function
- the function of the serial number that produces the activation key -
to generate new serial number/activation key pairs.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: greenjh <[EMAIL PROTECTED]>
Subject: Re: EncryptedChat V2 Dead ?
Date: Mon, 15 Nov 1999 22:14:59 +0000
On 15 Nov 1999 06:25:36 GMT, [EMAIL PROTECTED] (JPeschel)
wrote:
>[EMAIL PROTECTED] (Jerry Coffin)
>
>>It actually has a number of different methods - brute force, Pollard's
>>p-1, Brent's, William's p+1, Lenstra's elliptical curve and MPQS. It
>>basically starts with the easy ones and progresses to the more complex
>>ones if the earlier ones don't succeed (or at least leave large
>>composite factors).
>>
>>In this case, it found the factors courtesy of Bob Silverman, so to
>>speak -- I.e. using MPQS.
>
>I downloaded it, and is it fast! Thanks for the link.
>
>Joe
Can we use factor.exe to test the strength of PGP? In other words,
can we make PGP output a composite number which it would typically use
and then submit that number to factor.exe? If PGP refuse to output
the number (even when asked), can the number be sucked out?
Is there an upper limit to the numbers which factor.exe can handle?
I ask because factor.exe sometimes gave negative factors to a positive
test number.
TIA
JG
------------------------------
From: "wOODY" <[EMAIL PROTECTED]>
Crossposted-To: alt.binaries.cracks.encrypted
Subject: Sv: Tell me about GOST algorythm...
Date: Mon, 15 Nov 1999 23:15:10 +0100
check out http://home7.inet.tele.dk/hunter
--
-woody^drn
www.come.to/cib
ïÓÉ, âÀÒÏ-í <[EMAIL PROTECTED]> skrev i en
nyhedsmeddelelse:80p0h6$nac$[EMAIL PROTECTED]
> Dear Sirs!
>
> I would be please, if you tell me about strongest cryptography algorythm
> GOST.
>
> Thank.
>
>
> Baranenko Constantine [[EMAIL PROTECTED]]
>
>
>
>
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: SCOTT16U SOLUTION ON THE WEB
Date: Mon, 15 Nov 1999 21:14:40 GMT
"SCOTT19U.ZIP_GUY" wrote:
> the work I did was based on CBC which does have the weaknesses I describled.
How do you reconcile that with the proof that CBC is secure (within
tight bounds) if the underlying block cipher is? Reference:
M. Bellare, A. Desai, E. Jokipii and P. Rogaway. A Concrete Security
Treatment of Symmetric Encryption: Analysis of the DES Modes of
Operation. Extended abstract in Proceedings of 38th Annual Symposium
on Foundations of Computer Science, IEEE, 1997. Full version available
from Mihir Bellare's Web site.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Washington Post article on drug traffickers use of encryption
Date: 15 Nov 1999 22:25:18 GMT
"Douglas A. Gwyn" [EMAIL PROTECTED] writes:
>John Savard wrote:
>> "Highly sophisticated encryption"..."far beyond"...
>
>Don't read too much into news-media reports.
>They hardly ever get technical points right.
It's likely the technical details given to the news-media
were purposely vague.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
