Cryptography-Digest Digest #570, Volume #10 Mon, 15 Nov 99 14:13:03 EST
Contents:
Tell me about GOST algorythm... ("ïÓÉ, âÀÒÏ-í")
Re:SCOTT16U SOLUTION ON THE WEB (SCOTT19U.ZIP_GUY)
cryptoanalysis tool ("Olaf Dokter")
Re: EncryptedChat V2 Dead ? ([EMAIL PROTECTED])
Re: Bracking RSA Encryption. Is it possible. (fungus)
Re: What's gpg? <PHILOSOPHY 101> (Andrew Haley)
Re: Public Key w/o RSA? (Kent Briggs)
Re: Question about ElGamal (Anton Stiglic)
Short replacement for assymetric algorithms for authentification (Alex Birj)
SAFER for the 6811? ([EMAIL PROTECTED])
Re:SCOTT16U SOLUTION ON THE WEB (Anonymous User)
AES Candidate Specs? ([EMAIL PROTECTED])
Re: Re: intelligent brute force? (CoyoteRed)
Re: New NSA patent explicity mentions machine transcription ("Tim Wood")
Re: High Speed (1GBit/s) 3DES Processor ("Tim Wood")
Re: cryptoanalysis tool ("Douglas A. Gwyn")
Re: Short replacement for assymetric algorithms for authentification (Alex Birj)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Richard Herring)
Re: Codebook examples on Web? (Jim Reeds)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
Re: Washington Post article on drug traffickers use of encryption (John Savard)
Washington Post article on drug traffickers use of encryption (*)
Re: Cryptography for Dummies ("Joseph Ashwood")
----------------------------------------------------------------------------
From: "ïÓÉ, âÀÒÏ-í" <[EMAIL PROTECTED]>
Crossposted-To: alt.binaries.cracks.encrypted
Subject: Tell me about GOST algorythm...
Date: Mon, 15 Nov 1999 14:33:20 +0200
Dear Sirs!
I would be please, if you tell me about strongest cryptography algorythm
GOST.
Thank.
Baranenko Constantine [[EMAIL PROTECTED]]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Mon, 15 Nov 1999 14:22:46 GMT
In article <[EMAIL PROTECTED]>, Gondolin Remailer
<[EMAIL PROTECTED]> wrote:
>Are you telling me you have done this with all the AES methods and all the
>Cipher modes (ECB,CFB,OFB etc)...and you get the same result...
No I am saying this is an fundametnal weakness that is in all
short block ciphers. Use your on S-table or least make up just enough
entries of the S-table to see that it works. It is a fact that short block
ciphers with the stanard chaining methods are weak in the ways I
stated.
>
>If that is the case , then dont use the 3 letter chaining modes....you
>seem to be confusing two issues:
I don't use them. I use "wrapped PCBC" but most people have no idea
how to do it. The crypto gods do there best to conufse people about secure
chaiing when it comes to encrypting files.
>
>1. The Strength of the Cipher
>2. Chaining Mode...
>
>Ciphers like IDEA, CAST are very strong and have stood up the test of
>time and analysis... and DES was only broken by a brute force attack...
You don't know if IDEA CAST and the such have with stood the
test of time and analysis. You may knwo that there are no widely published
attackes that are readily available. But it is foolish to think otherwise.
>
>If you have a problem with 3 letter chaining modes, dont use them .
>
>May I suggest you try your test on 3DES, IDEA and CAST and see if you get
>the same result...
Obviosuly you don't understand the problem and the crypto gods have done
a great job giving you misinformation. It works on all block cipher that have
no internal feedback to change state from one block to the next.
>
>The problem with your method is that :
>
>a. There has been no serious crypto analysis work done on it
Depends what you mean. There is not open literature work done on
it other than Wagner repeated comments on how it would obviously fail
his Slide Attack. Which he repeatedly stated over and over. But when
push came to shove he was full of shit.
>b. Your method is isolated...cant e.g. use it with another block cipher
>
The chaining method is not isolated and can be used any block cipher
method. However it requires at least three passed through the encyption
system. However it gives you and "all or nothing" type of encryption and
you can encrypt files without changing the file size. I think people should
be very careful about any crypto system that can't encrypt files with out
first forceinf the file to be in some unnatural multiply of bytes.
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: "Olaf Dokter" <[EMAIL PROTECTED]>
Subject: cryptoanalysis tool
Date: Mon, 15 Nov 1999 14:23:48 +0100
i am newe in this newsgroup and i have read now a lot about
cryptoanalysis-tools. can i find some of them in the internet ? if yes,
where ?
are there any good books about cryptoanalysis available ?
thank you
olaf dokter
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: EncryptedChat V2 Dead ?
Date: Mon, 15 Nov 1999 13:40:58 GMT
> > >
> > >The above number is composite.
> >
> > Factors are: still being caculated.
>
> FWIW:
>
> 287895462580028491
> 5832864341798915401
>
I suppose the prime number is 'e' in RSA and the composite number is
the 'n', correct ?
If yes, could Joe confirm that EncryptedChat Version 2 is dead ? and is
not secure ?
Regards,
Alexander
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Bracking RSA Encryption. Is it possible.
Date: Mon, 15 Nov 1999 14:07:15 +0100
"Allan G. Schrum/Theresa C. Schrum" wrote:
>
> I would be curious to know exactly how, given a good integer
> factoring method, RSA could be broken. What is the approach?
>
Simple, you take the enemy's public key and factorise it.
Once you've done this the rest is easy.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: What's gpg? <PHILOSOPHY 101>
Date: 15 Nov 1999 15:00:01 GMT
Wil Baden ([EMAIL PROTECTED]) wrote:
: The professor was A. W. Tucker, who invented the Fast Fourier
: Transform.
Among many others. Gauss started it all, AFAIK...
Andrew.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Public Key w/o RSA?
Date: Mon, 15 Nov 1999 15:17:24 GMT
DJohn37050 wrote:
> 1) DL systems can be used to do signatures (DSA, NR), and encryption, as well
> as key agreement as in DH.
Yes, and proof of that is my Puffer program which has been using a DH discrete log
system for file and message encryption as well as digital signatures for over two
years now:
http://www.briggsoft.com/puffer.htm
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Question about ElGamal
Date: Mon, 15 Nov 1999 10:30:47 -0500
==============60887B20D1C9BF802C36F7CC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
yes, P and G can be public. This is because the ElGamal system relies
basicaly on a problem called the discret log problem which is the following:
given Y, G, P, find an X such that G^X = Y mod P. It is beleived to be hard.
The public key is in fact (Y, G, P), beleiving that the discret log problem is
hard, one cannot found X given this public key.
Anton
Mark Trade wrote:
> I have a question about ElGamal encryption, more specially about the private
> key. As far as I understand it is composed by P (prime), G (G < P) and Y
> (Y=G^X mod P where X is the private key and X < P).
> In "Applied Cryptography" I read that P and G can be shared among a group of
> users, but what about Y? Should the public key be PG or PGY?
> I tried it with simple numbers and found out that a message can't be decoded
> with PG of the sender and X of the receiver, but I am afraid I missed
> something...
>
> Thanks for your help
>
> -Mark
--
___________________________________________
Anton Stiglic
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________
==============60887B20D1C9BF802C36F7CC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
yes, P and G can be public. This is because the ElGamal system
relies
<br>basicaly on a problem called the discret log problem which is the following:
<br>given Y, G, P, find an X such that G^X = Y mod P. It is beleived
to be hard.
<p>The public key is in fact (Y, G, P), beleiving that the discret
log problem is
<br>hard, one cannot found X given this public key.
<p>Anton
<p>Mark Trade wrote:
<blockquote TYPE=CITE>I have a question about ElGamal encryption, more
specially about the private
<br>key. As far as I understand it is composed by P (prime), G (G <
P) and Y
<br>(Y=G^X mod P where X is the private key and X < P).
<br>In "Applied Cryptography" I read that P and G can be shared among a
group of
<br>users, but what about Y? Should the public key be PG or PGY?
<br>I tried it with simple numbers and found out that a message can't be
decoded
<br>with PG of the sender and X of the receiver, but I am afraid I missed
<br>something...
<p>Thanks for your help
<p>-Mark</blockquote>
<pre>--
___________________________________________
Anton Stiglic <[EMAIL PROTECTED]>
Jr. developer & specialist in cryptology.
Zero-Knowledge Systems Inc.
___________________________________________</pre>
</html>
==============60887B20D1C9BF802C36F7CC==
------------------------------
From: Alex Birj <[EMAIL PROTECTED]>
Subject: Short replacement for assymetric algorithms for authentification
Date: 15 Nov 1999 05:54:24 -0700
The idea is that given text and cyphertext it is difficult to find a key
for symmetric algorithms. I want to apply this idea e.g. to make creating
key generators for shareware programs impossible. Linear increase
of time will provide exponential increase in number of users authentified.
So the problem of supplying long keys for assymentric authentification
will be circumvented as well as using libraries for big numbers.
Let us suppose we have a text 'hambomat'. Let us take three arrays of
100 elements each. Every element will be cyphertext corresponding to
the text encrypted with 300 different predefined keys.
To authentify a client we'll send her/him three keys that encrypted
one of cyphertexts from each arrray. For RC5 we can send 8*3=24
byte or 24*4/3=32 byte Base64 (i.e. ASCII2) key. The program will search
for a match in every array at cost maximum 300 decrypting or encrypting
operations which is very fast. In so we can produce 100**3=1000000 different
combinations.
Key1 Key2 Key3
<------ Sending to a user
cypertext 1-1 cyphertext 2-1 cyphertext 3-1
<------Contained in the program
..... ... .....
cyphertext 1-100 cyphertext 2-100 cyphertext 3-100
text = hambomat <-----Contained in the program
Cheers,
Alex Birj
------------------------------
From: [EMAIL PROTECTED]
Subject: SAFER for the 6811?
Date: Mon, 15 Nov 1999 15:44:27 GMT
Hello,
I'm the guy who was asking about RSA for the 6811. Well, I've decided
that it's just gonna be too slow for what I'm trying to do here.
So, I was looking through the online Handbook of Cryptography, and SAFER
caught my eye, as it was designed to be implemented on 8-bit processors.
Since I am a strong believer in code reuse, plus I'm also a little lazy,
I'd be interested in knowing if someone has already implemented it for
the 6811 (or a processor that has a similar instruction set).
I found an assembly implementation for the 386 in the Cryptlib toolkit,
but that seems quite unlike the language of the 6811.
Thanks,
Derek.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 15 Nov 1999 16:50:56 +0100
From: Anonymous User <[EMAIL PROTECTED]>
Subject: Re:SCOTT16U SOLUTION ON THE WEB
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...
------------------------------
From: [EMAIL PROTECTED]
Subject: AES Candidate Specs?
Date: Mon, 15 Nov 1999 16:09:57 GMT
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?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: intelligent brute force?
Date: Mon, 15 Nov 1999 16:19:00 GMT
Reply-To: this news group unless otherwise instructed!
On Mon, 15 Nov 1999 01:24:09 -0500, Keith Monahan <[EMAIL PROTECTED]>
wrote:
>P.S. I'm looking for smarter ways to construct test passphrases.
>Although it shouldn't matter, the algorithm involved is 256 bit
>Blowfish in CBC mode. Brute forcing the passphrase is
>computationally difficult due to its length and composition.
So, you are looking to gain access to a key via entering a passphrase?
Something other than a full blown dictionary attack?
How much do you know about the key holder? ... habits, etc. How
concerned with security is he? ...how complacent?
This will determine the direction that you should take when trying a
"brute force, while trying most likely passphrase first."
If the key holder uses a system of, say, using an unabridged
dictionary and flipping pages randomly and pointing to a word blindly,
and chooses 6 of said words, then it's going to be tough. Tough,
because he isn't using a "smart" way to select his passphrase,
therefore there isn't a "smart" way for you to duplicate his efforts.
But a collection of the target's names, hobbies, brand names around
him, dates, and associated numbers would be a start. You would then
try these in different combinations, including substitutions of $ for
s, 1 for I, 0 for O, etc. Try adding one to each digit of SSN, etc.
and so on. While this is still force, it's less brawny and more
brainy.
While some rely on physical security of a passphrase and keep it
separate from the machine when not in use, (then a passphrase can be
exceedingly complex), most passphrase need to be remembered easily and
NOT written down, if properly used. So take it from there.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: New NSA patent explicity mentions machine transcription
Date: Mon, 15 Nov 1999 16:42:13 -0600
Hi, thanks I found this interesting however
>In today's Indy:
> http://www.independent.co.uk/news/Digital/Features/spies151199.shtml
and a brief synopsis would have been enough.
and from FAQ.
>2.2. Do political discussions belong in sci.crypt?
> No. In fact some newsgroups (notably misc.legal.computing) were
> created exactly so that political questions like ``Should RSA be
> patented?'' don't get in the way of technical discussions. Many
> sci.crypt readers also read misc.legal.computing, comp.org.eff.talk,
> comp.patents, sci.math, comp.compression, talk.politics.crypto,
> et al.; for the benefit of people who don't care about those other
> topics, try to put your postings in the right group.
later
Tim
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Mon, 15 Nov 1999 16:44:43 -0600
[EMAIL PROTECTED] wrote in message
<[EMAIL PROTECTED]>...
>We have developed a prototype Encryption system which runs 3DES at 1
>GBits/sec (this is not just processing but with real IO at 1 GBit/sec).
>Are there any commercial applications for this type of technology?
Isn't it usual to find out if there are commercial applications before you
develop something?
Unless of course you just do it as a hobby ;-)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: cryptoanalysis tool
Date: Mon, 15 Nov 1999 15:42:31 GMT
Olaf Dokter wrote:
> i am newe in this newsgroup and i have read now a lot about
> cryptoanalysis-tools. can i find some of them in the internet ?
> if yes, where ?
There are a few such tools, but it sounds like you may be
expecting too much from them. The most powerful tool for
cryptanalysis is a mind with suitable aptitude, training,
and experience. If you have that, you should be able to
readily create your own software tools when you need them.
> are there any good books about cryptoanalysis available ?
"Classical" cryptanalysis, which contains many important
lessons even for attacking modern systems, can be learned
from the Military Cryptanalytics series, reprinted by
Aegean Park Press. (It is a good idea to first study
cryptography, e.g. Kahn's book "The Codebreakers".) An
Army field manual teaching cryptanalysis is available at:
http://www.und.nodak.edu/org/crypto/crypto/army.field.manual/
My personal recommendation is to work through the MilCryp
exercises, *especially* the Zendian problem, before trying
to learn techniques specific to more modern cryptosystems.
------------------------------
From: Alex Birj <[EMAIL PROTECTED]>
Subject: Re: Short replacement for assymetric algorithms for authentification
Date: 15 Nov 1999 07:00:08 -0700
>Maybe the only problem is that by acquiring several keys other
>keys can be easily produced.
>
So the mechanism described above will work only when
a program contains one array instead (i.e. 8Kbytes per 1000 users that
isn't so bad). Also the index in the array might be included into
a key that will consume only 8 bytes now (or 12 bytes in Base64) + index
if necessary.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 15 Nov 1999 16:59:43 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, james d. hunter ([EMAIL PROTECTED])
wrote:
> [EMAIL PROTECTED] wrote:
> >
> > james d. hunter ([EMAIL PROTECTED]) wrote:
> >
> > : No you don't need infinite precision. Somebody decided
> > : 2000 years ago that it would be convenient if really, really, really,
> > : real numbers existed, and humans have been imagining that really,
> > : really
> > : really, real and really, really, really imaginary numbers existed ever
> > : since.
> >
> > Oh, dear. You wouldn't like my web site then; I have a description of
> > Cantor's diagonal proof there.
> Well, I read Cantor's original once, that seemed to be enough times.
> So, why do you think I would want to visit a "scientist" web page
> to read it again.
Why would you assume it's a '"scientist" web page' [sic]
if you haven't visited it?
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Jim Reeds <[EMAIL PROTECTED]>
Subject: Re: Codebook examples on Web?
Date: Mon, 15 Nov 1999 16:57:27 GMT
UBCHI2 wrote:
> Are there any examples of famous codebooks on the net? I want to see how the
> Gray code and other historical diplomatic codebooks were constructed.
I have put one page of the decode section of a 1929 U.S. State Department code
on my web site, at
http://www.research.att.com/~reeds/d1.txt
Features to note: The code was designed to be superenciphered. There are very
few long phrases. There is liberal provision of spelling groups. Some of the
plain text
entries are ominous (NEPON=Detention camps). The vocabulary seems designed to
cover a much wider range of topics than found in tactical military codes. The
code
groups seem to all obey a CVCVC constraint; there seems to be an upper limit of
36,000
possible entries; the groups do not obey a mutilation table constraint.
I have not proofread my transcription. I have a few other pages from that book,
which
I might type in, but I make no promises.
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
Date: Mon, 15 Nov 1999 12:40:29 -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:
>
> > Coen Visser wrote:
>
> > > > My generator is a fair coin. If you specify an infinite sequence
> > > > you believe is incompressible
> > > > (just how are you going to do that?),
>
> > > That is impossible: if I can give an effective description I can
> > > compress it.
>
> > OK, so you cannot give an effective description of an incompressible string. What
>makes you
> > believe that there are any strings that meet your definition of incompressibility?
>
> There is a counting argument that shows that most strings
> can hardly be compressed. Say you want to compress all
> (bit)strings up to length N, take all strings of length <= 8 for
> example. There are 256 strings of length 8, but there are only
> 2+4+8+16+32+64+128 = 254 smaller strings if we don't count
> the empty string. So there are at least 2 strings of 8 bits
> that can not be compressed. Furthermore all strings smaller
> than 8 bits can't be compressed either because they are all
> used to compress the 8 bit strings.
Please decide on what rules you are going to use, and then stick with them. Last I
heard you had
claimed that compressibility was an attribute of individual strings. Has this
changed? Did I
misinterpret your claims?Your answer addresses the issue of compression collections
(sets) of
strings. My question was aimed at instances of single strings that are
incompressible. Do you
have such an example?
> > > > my generator will produce it "eventually".
>
> > > For an infinite random sequence the chance is zero, absolutely,
> > > there are uncountably many sequences. I would say your fair coin
> > > compresses
> > > one specific infinite length random number of which we have no other
> > > information than that it is produced by your coin.
>
> > Does this mean that every fair coin encodes a distinct incompressible string?
>
> I think the chance that two distinct fair coins
> produce the same string goes to zero exponentially fast.
> One could throw two distinct fair coins four times and throw
> "0101" and "0101" but that gets harder and harder if the
> string lengths grow. So for all practical purposes the answer
> would be yes.
First, you are using a probabalistic argument applied to the generator of the strings
rather than
the strings themselves. Second, we don't care how long it takes for the coins to
match. The
starting point of one coin's sequence may be found deep within the other coin's
sequence. It's an
expected wait problem. The procedure is as follows:
Flip coin A, append results to A's string
Flip B until the tail of B matches the entire A string.
Repeat.
At the conclusion of each cycle B's string contains A. (c.f., Zeno's paradox).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Washington Post article on drug traffickers use of encryption
Date: Mon, 15 Nov 1999 17:42:23 GMT
[EMAIL PROTECTED] (*) quoted (from the Washington Post), in
part:
>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.
It would be pointless to predict the weather 30 seconds from now if it
took a computer 24 hours to do it; presumably, the traffickers are
setting up their drug meets less than 24 hours in advance.
"Highly sophisticated encryption"..."far beyond"...would take a bit
more than 24 hours to break. Either the NSA has some *really* powerful
computers, about which word should not have leaked out...or we're
talking 56-bit DES.
Unless the FBI used its own computers, in which case it could be A5;
they don't quite have the NSA's budget for this sort of thing. But I
think the "sources" would be embarassed to call an off-the-shelf PCS
phone "highly sophisticated encryption technology".
Other forms of surveillance can be used; it is regrettable that it is
harder to catch drug traffickers, but a general ban on private use of
encryption is not worth the price. However, radio transmission - even
on a cell phone - is regulated by law, so existing laws should be able
to deal with people making unauthorized modifications to cell phones,
and they certainly are able to deal with people stealing the service.
So a law against strong, unescrowed encryption wouldn't give the
authorities anything in this case they don't have already ... except
that the traffickers wouldn't have been able to buy DES chips as
easily.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (*)
Subject: Washington Post article on drug traffickers use of encryption
Date: Mon, 15 Nov 1999 17:06:47 GMT
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?
Anything else heard about this?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cryptography for Dummies
Date: Mon, 15 Nov 1999 09:44:13 -0800
> If the hash function is strong,
I was attempting to address the varying ideas of strong when it comes to
hash functions, there is the concept that it should be completely
non-invertable (in my terminology earlier highly convergent) competing with
making it difficult to find a message that has the same output value (which
in the perfect case is truly "non-convergent", and hence invertable, even
though it may be with some difficulty). Each hash function designer has to
sooner or later deal with trying to find their own personal answer to where
in the grey area their function lies, if one leans too far towards
"convergent" then it becomes easy to find inverses, but if one moves towards
"non-convergence" then it becomes easier to find inversions.
I can present 2 trivial examples, a simple output of 1 (regardless of input)
is completely convergent, and we can all see that finding another input to
match the out is easy, however even knowing a large portion of the input, it
is impossible to reverse the process, this method is overly convergent. OTOH
a checksum is highly non-convergent when a fairly significant amount of the
original text is known (provided that the unknown text is not too much
larger than the hash), giving us an easy job of inversion, but I'm sure we
can pretty much all agree that for cryptographic purposes a checksum is near
worthless.
> then finding a preimage will be
> infeasably difficult even where an existing preimage is shorter than
> the output of the hash function.
Quite true. I think SHA-1, as the original poster suggested, actually does
this quite well.
> So I don't think you need worry
> about this. Especially since it might be read as persuading people to
> go for hash functions with shorter outputs, which would be a mistake.
I hadn't thought that someone might read it that way, the reasonable
solution (that I see) to the problem is to increase the salt to at least the
length of the hash, guarenteeing that there will be overflow into multiple
blocks, and of course the longer the salt the better.
Joe
------------------------------
** 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
******************************
