Cryptography-Digest Digest #790

2001-03-03 Thread Digestifier

Cryptography-Digest Digest #790, Volume #13   Sun, 4 Mar 01 00:13:00 EST

Contents:
  Is this prime? (An Metet)
  Re: Super strong crypto (David Wagner)
  Re: Cryptanalysis of GOST? (David Wagner)
  Re: => FBI easily cracks encryption ...? (CR Lyttle)
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Anthony 
Stephen Szopa)
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Anthony 
Stephen Szopa)
  Re: philosophical question? (Virgil)
  Re: OverWrite freeware completely removes unwanted files fromharddrive ("Tom St 
Denis")
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Benjamin 
Goldberg)
  Re: Is this prime? (Walter Hofmann)
  Re: ARCFOUR and Latin Squares ("Henrick Hellström")
  Re: RSA Key Generation (Luis Duarte)
  Re: RSA Key Generation (Luis Duarte)
  Re: OverWrite freeware completely removes unwanted files fromharddrive (HiEv)
  Re: ARCFOUR and Latin Squares ("Henrick Hellström")
  ½Ð¦h¦h«ü±Ð ("david")
  ½Ð¦h¦h«ü±Ð ("david")
  Re: ½Ð¦h¦h«ü±Ð ("Tom St Denis")
  Re: philosophical question? ("Douglas A. Gwyn")
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Anthony 
Stephen Szopa)
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Anthony 
Stephen Szopa)
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Anthony 
Stephen Szopa)
  super strong crypto, phase 3 ("Douglas A. Gwyn")



Date: Sat, 3 Mar 2001 20:29:11 -0500
From: An Metet <[EMAIL PROTECTED]>
Subject: Is this prime?

Could you tell me if this number is prime?

1442403906876930569032099720156167627535758375716296889356941448556686886222540568445876243533197

What method did you use?

The two factoring programs I have tried could not find any factors, so is it probably 
prime?




--

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 4 Mar 2001 01:36:28 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)

John Savard wrote:
>send E(P xor R, K1) and E(R, K2) and that way, both encryptions are of
>a totally random sequence.
>
>It's equivalent to double encryption, [...]

Well, they're not actually equivalent.

If you use two block ciphers -- i.e., E(P xor R, K1), E'(R, K2) -- the
former scheme is at least as secure as the stronger of the two ciphers.
In contrast, double-encryption does not have the same property.

The two schemes do have a similarity, though, in that they are both
susceptible to meet-in-the-middle attacks which are not much slower than
exhaustive keysearch on half the keyspace.

--

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Cryptanalysis of GOST?
Date: 4 Mar 2001 01:38:12 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)

Rebus Mauser wrote:
>Is anything known about practical attacks on the GOST algorithm?

No.  But keep in mind: There's a big difference between "no known attacks"
and "can be treated as secure".  In particular, I would imagine that GOST
has not received nearly as much scrutiny as, say, DES or even AES.

--

From: CR Lyttle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 04 Mar 2001 02:06:13 GMT

kroesjnov wrote:
> 
> > > Could not agree more with you.
> > > Although I am not an American, I would not mind, if the BVD (Dutch
> National
> > > Intellegence service) would have this abillity.
> > > I think they (Like any other country`s national intellegence service)
> should
> > > try their very best, to make this possible...
> >
> > Were you in Holland when the Nazi's invaded and took over all the police
> > records?
> 
> (Well this is going to be a touchy discussion...)
> 
> Nope, I was not there.
> I am only 19 years old.
> 
> I think this is slightly off the topic, but I will run with it any way:
> 
> I assume you are refering to the fact, that the Dutch administration (and
> with that, the National Intellegence agency) on people was to good organized
> (Thinks like race and religion where also archieved, so that the Nazi`s had
> a very easy job, finding out who was off jewish origin).
> If you want my opinion on this: This was wrong afcourse, and so history has
> teached us (The hard way).
> Yet I do not see the connection to the ability off a Secret Service being
> abble to crack an encrypted message (With effort afcourse), So that
> Terrorist could be intercepted, who are going to bomb some building in The
> Netherlands, or any other Country in the World.
> 
> Did I assume wrong, on what you are referrin

Cryptography-Digest Digest #790

2000-09-28 Thread Digestifier

Cryptography-Digest Digest #790, Volume #12  Thu, 28 Sep 00 14:13:01 EDT

Contents:
  Re: Josh MacDonald's library for adaptive Huffman encoding (SCOTT19U.ZIP_GUY)
  Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
  Re: Adobe Acrobat -- How Secure? (Dave Ashley)
  Deadline for AES... (Volker Hetzer)
  Re: I am only an egg... ("Trevor L. Jackson, III")
  new Pegwit ([EMAIL PROTECTED])
  Re: Chaos theory (Derek Bell)
  Re: Chaos theory (Derek Bell)
  How to get Certificate content after HTTPS Authentication ("Joyce")
  Re: Cipher Illiteracy (Mike Rosing)
  Re: RSA and Chinese Reminder Theorem (Bob Silverman)
  Re: Notice: Problems with DiehardC. ("Paul Pires")
  Chaining for authentication (Marc)
  Re: Non-Repudiation mechanism ("Kevin Crosbie")



From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression,comp.theory
Subject: Re: Josh MacDonald's library for adaptive Huffman encoding
Date: 28 Sep 2000 13:50:36 GMT

[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <39D2FDEB.E8BD92EA@t-
online.de>:

>
>
>Alex Vinokur wrote:
>> 
>> Josh MacDonald's library for adaptive Huffman encoding :
>> http://www.xcf.berkeley.edu/~ali/K0D/Algorithms/huff/
>
>I like to repeat a question I asked before. How does
>adaptive Huffman compare with static Huffman that
>employs an exact frequency distribution of the texts?
>Thanks.
>

   I see where you can get confused. I was reading an
article on the net the other day which claimed it was
talking about adaptive huffman compression but it was
talking static huffman compression,
   There are articles that tell what bounds adaptive
huffman compression to static huiffman compression,
   But doing tests on my own static huffman compression
( if you don't count space for table) usually beats 
adaptive huffman compression. But not always. Some files
are such that adaptive hufman compression beats the static
even if you don't count the table space. 
Hay its not that hard to test this yourself, but one
word of warning not all adaptive huffman compression programs
the same most use what you called a NYT followed by the ascii
coding of the symbol when a new symbol is incountered in
the input stream. Mine do not.

   My main one starts with a full tree and then the tree
changes based on input. There is no reason that if you always
compressing simialar files not to use a different starting tree
and a different amount of adapting. If one is only using a certain
class of files. I think a mod like above would beat static most
of the time since you can tune it the types of file you like.
  But like I said it is not that hard to play with it.



David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

--

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 28 Sep 2000 14:03:52 GMT

[EMAIL PROTECTED]=NOSPAM (Arturo) wrote in
> I doubt it.  The author is Bruce Schneier, boss-in-chief of
> Counterpane 
>security and writer of the "bible" in crypto, Applied Cryptography.  Not
>the kind of guy I think most likely to have been bought by the NSA
>

   Then please tell me the kind of guy you think the NSA would own.
Terry who seems not to have press conections or do you think I am
the type Arturo.

>> At least these
>>are my feelings about these fishy ciphers. It seems like NSA humour
>>to give both ciphers FISHY names.
>
> Rather blame the author.  

I see blame the author because this is nit the kind of twist
the NSA would do?

>
>>  But since the idea of a cipher is security. It is plain stupid to
>>say Twofish is better than Blowfish becasue Blowfish is a PC cipher.
>>If one has a PC and is sending messages to someone with a PC then why
>>use a cipher that could becasue of its ability to be run on many
>>machines would ecpoxe it to more attacks. Even if they algoritmically
>>had the same level security which can't be proved anyway.
>>
> Right, maybe.  But the AES is not being chosen just to play with on
> a 
>PC.  It is intended to be used as a general-purpose standard, PC,
>software, hardware or whatever.  It has to be strong, resistant to
>cryptanalysis, fast, have several block + key size features,

Cryptography-Digest Digest #790

2000-05-16 Thread Digestifier

Cryptography-Digest Digest #790, Volume #11  Tue, 16 May 00 15:13:00 EDT

Contents:
  Re: Is OTP unbreakable? (Paul Schlyter)
  Re: Unbreakable encryption. ("C. Prichard")
  bamburismus ("Ferrante Formato")
  Re: Definition of "Broken" Cipher (Mike Rosing)
  Re: Bigger numbers... ("C. Prichard")
  BIG NUMBERS for CipherText ("C. Prichard")
  Is there a patent protecting use of an encrypted 1024 byte mask ("C. Prichard")
  Quake Encryption (Donald R. McGregor)
  Re: Cascading Crypto Attack (Tim Tyler)
  Re: Is OTP unbreakable? (Paul Koning)
  Re: Definition of "Broken" Cipher (Paul Koning)
  Re: AES Comment: the Hitachi patent (Paul Koning)
  Re: Is there a patent protecting use of an encrypted 1024 byte mask (Eric Lee Green)
  Re: BIG NUMBERS for CipherText (Eric Lee Green)
  Re: Whitening ("C. Prichard")
  Re: Unbreakable encryption. ("C. Prichard")



From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Is OTP unbreakable?
Date: 16 May 2000 17:37:23 +0200

In article <8fr420$j1o$[EMAIL PROTECTED]>,
Simon Johnson  <[EMAIL PROTECTED]> wrote:
 
> Moreover, the key has to be the same length as the text you want to
> encrypt (repeating a key over the plain-text falls to an attack related
> to the one obove). Encrypting with a OTP is pointless simply because
> now you now have to figure out a way to secure the OTP key!!!
 
Well, OTP isn't always pointless.  If you need secure communication
of a limited amount of data with someone in the future, when you have
no secure communications channel available, and if you have a secure
communications channel available now, you can exchange an OTP key
now with that person, to be used in the future.
 
Still, OTP has two weaknesses though:
 
1. An eavesdropper can figure out the length of the message.  This
can be countered by adding random garbage to your actual message.
 
2. An eavesdropper can figure out that a message has been sent.
This can be countered in two ways: either by steganography (which
hides the message somehow), or by sending many extra messages
containing nothing but garbage.
 
-- 

Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   orpaul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch

--

From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Tue, 16 May 2000 17:27:31 GMT

YOU can't break a random MASK that holds a message unless YOU know the =
key.

You don't know the key, applied. Go figure how many permable =
combinations are created with 8 ordinates having 96 possibilities each.

Get out of the newsgroup if you can't grasp the content.

-Charles Prichard

Eric Lee Green <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> "C. Prichard" wrote:
> > Rather than distibute new masks for each message, its simply =
necessary to associate a mask key to create a somewhat unique mask.
>=20
> Sigh. Simple XOR? That was breakable a hundred years ago.=20
>=20
> There are standard terminology, techniques, and attacks. Learn them, =
then get
> back to us. The sci.crypt faq, posted once a month, has a large =
reference list
> of books to read before you can consider yourself "educated" in =
cryptography.
> You should at least read a couple of those before making a fool of =
yourself in
> this group -- or at least display some humility about the (lack of) =
knowledge.
> Lord knows I made a fool of myself plenty of times in the past, but =
was not
> ashamed to say that I knew little about cryptography and was having =
trouble
> understanding a concept or whether a certain technique was secure or =
not.
>=20
> Some key words or terms to think about:
>=20
> whitening
> public key encryption
> key exchange protocols
> replay attacks
> chosen plaintext attacks
> salt
> challenge
> ...
> =20
> --=20
> Eric Lee Green [EMAIL PROTECTED]
> Software Engineer  Visit our Web page:
> Enhanced Software Technologies, Inc.   http://www.estinc.com/
> (602) 470-1115 voice   (602) 470-1116 fax


--

From: "Ferrante Formato" <[EMAIL PROTECTED]>
Subject: bamburismus
Date: Tue, 16 May 2000 18:59:48 +0200

Any information about Turing's Bamburismus?
It was a probabilistic meythod settled to crack Enigma code in WWII
Thanks
Ferrante Formato



--

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Definition of "Broken&quo

Cryptography-Digest Digest #790

1999-12-24 Thread Digestifier

Cryptography-Digest Digest #790, Volume #10  Fri, 24 Dec 99 16:13:00 EST

Contents:
  DES Problem! ("Daniel Suberviola")



From: "Daniel Suberviola" <[EMAIL PROTECTED]>
Subject: DES Problem!
Date: Fri, 24 Dec 1999 14:45:47 -0600

Hello, everyone.

I am a high school senior writing a modified implementation of DES as a
science project. The work is being done in binary for now on a fixed 64-bit
data chunk and a fixed 64-bit key (both very simple), and I will add support
for real-world files once I am able to successfully get the fixed data and
key to encrypt and decrypt. Which brings me to my problem...

The DES algorithm, from what I have read, is supposed to work in both
directions, as long as the key order is reversed during decryption. I have
written and tested functions to handle the various permutations; as far as I
can tell, they work as designed. However, when I attempt to have my program
decrypt the 64-bit block it has just encrypted, I get a completely different
result from what I initially started with.

Below is a copy the current output:

*** ENCRYPTION

Round 0:  
(Round 0 is the original plaintext after the initial permutation.)

Round 1:  111010111010011101000101
USING KEY 0100011011010011010100101010110110101011

Round 2: 111010111010011101000101 1000110110001100010011100110
USING KEY 0100111001010010110100101110010110101011

Round 3: 1000110110001100010011100110 011100010010100100111100
USING KEY 1100101111011010101011100101100101110011

Round 4: 011100010010100100111100 111001110010011010001101
USING KEY 100110001010101010000100101101110010

Round 5: 111001110010011010001101 1100110111001100111001100100
USING KEY 10110001101110101010101011010101100001011000

Round 6: 1100110111001100111001100100 001000111101001001001011
USING KEY 1011001011010110110110011001011001011100

Round 7: 001000111101001001001011 01100110010001001010010100111000
USING KEY 0111010001100101010001011001011010101100

Round 8: 01100110010001001010010100111000 00000100010010111001
USING KEY 01000110010101110111110010101101

Round 9: 00000100010010111001 010010001000110101101101
USING KEY 11000110111001010111010100111010010010110101

Round 10: 010010001000110101101101 0010101110001110
USING KEY 11001100011100110011101010110110100110110011

Round 11: 0010101110001110 001010101101000100011101
USING KEY 11101001001110101011101001110110101100010011

Round 12: 001010101101000100011101 001011001011010110010010
USING KEY 1011101110010010110010110111001101010110

Round 13: 001011001011010110010010 0101000110100011
USING KEY 0011100101011010110110101101010110001110

Round 14: 0101000110100011 11010010010001000100
USING KEY 00110100000111011100010101001011011011001101

Round 15: 11010010010001000100 00001011101000110011
USING KEY 00010110011011010101010100101011010011101101

Round 16: 00001011101000110011 1101101010111010100101100011
USING KEY 010001101101010101010110101001001010

*** DECRYPTION

Round 0: 00001011101000110011 1101101010111010100101100011
(Round 0 is the original ciphertext after the initial permutation.)

Round 1: 1101101010111010100101100011 110001011011110001010111
USING KEY 010001101101010101010110101001001010

Round 2: 110001011011110001010111 11001110100100110011
USING KEY 00010110011011010101010100101011010011101101

Round 3: 11001110100100110011 10001010101100111001
USING KEY 00110100000111011100010101001011011011001101

Round 4: 10001010101100111001 10010010110101010110
USING KEY 0011100101011010110110101101010110001110

Round 5: 10010010110101010110 0110111001110111000111001000
USING KEY 1011101110010010110010110111001101010110

Round 6: 0110111001110111000111001000 11100100100011010001011010111000
USING KEY 11101001001110101011101001110110101100010011

Round 7: 11100100100011010001011010111000 00011101000100110001
USING KEY 11001100011100110011101010110110100110110011

Round 8: 00011101000100110001 11010101011101100101100100101101
USING KEY 11000110111001010111010100111010010010110101

Round 9: 11010101011101100101100100101101 10011101001110101100
USING KEY 01000110010101110111110010101101

Round 10: 10011101001110101100 000110010101101110101110
USING KEY 0111010001100101010001011001

Cryptography-Digest Digest #790

1999-06-28 Thread Digestifier

Cryptography-Digest Digest #790, Volume #9   Mon, 28 Jun 99 06:13:03 EDT

Contents:
  Re: determining number of attempts required (Keith A Monahan)
  Re: determining number of attempts required (Keith A Monahan)
  Re: The One-Time Pad Paradox (Anti-SpamNameHere)
  Re: The One-Time Pad Paradox (S.T.L.)
  PGP Key Signing Party in Massachusetts (Sherlock S. Holmes, D.D.)
  PGP Key Signing Party in Massachusetts (Sherlock S. Holmes, D.D.)
  Re: Tough crypt question: how to break AT&T's monopoly??? (JPeschel)
  Re: Tough crypt question:  how to break AT&T's monopoly??? (Thomas Wu)
  Re: one time pad (Rob Warnock)
  Re: determining number of attempts required (S.T.L.)
  Re: Tough crypt question: how to break AT&T's monopoly??? (JPeschel)
  Re: xtea ("Gary Partis")
  Re: A few questions on RSA (Gilad Maayan)
  Re: DES-NULL attack ("Douglas A. Gwyn")
  Re: The One-Time Pad Paradox ("Douglas A. Gwyn")



From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: determining number of attempts required
Date: 28 Jun 1999 05:12:57 GMT

Hi Joe,

Thanks for the response.

I actually have some blowfish example source, and of course Bruce's papers,
AC, and a couple of other things.  I would probably have a hard time
implementing everything, but I suppose I could write one.

The program I'm using is BestCrypt NP.

Mind passing my name/email to your friend Pavel Semjanov, or perhaps give me
his address so I can contact him?

I can tell you that the password picked is DEFINITELY not weak Designed
to resist attack.  There is only one (misspelled) English word in the 12
characters(approx) that I am searching for.

Unless I can find another way to attack the problem at hand, 2000 looks like
it will be my max.

Thanks,

Keith

JPeschel ([EMAIL PROTECTED]) wrote:

: Keith, as far as I know there aren't any Blowfish crackers on the net, with one

: exception. Markus Hahn wrote a program to recover Blowfish 97 passwords.
: It's to demonstrate the danger of using weak passwords.  (On the other
: hand, if you find or write a fast Blowfish cracker, send it to me and I'll add
: it to 
: my collection) 
:   
: If you're going to try a dictionary attack you're going to have to do a
: helluva lot better than 2,000 attempts per hour. My Russian friend Pavel
: Semjanov has some code called PCL that may help you. 

: What program created encrypted the file?  If you have access to that program
: there may be a more efficient way of breaking the system.  

: Joe  

: __

: Joe Peschel 
: D.O.E. SysWorks   
: http://members.aol.com/jpeschel/index.htm
: __


--

From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: determining number of attempts required
Date: 28 Jun 1999 05:24:26 GMT

Hi Tom,

Thanks for the explanation of the formulas.  That helps.

: Hmm why may I ask are you trying to hack your own password?

I could get into a long story about me NEVER forgetting any of my
passwords despite their complexity, but I'll skip that.  Suffice to say that
I don't remember the whole thing.

: Tom

Keith


--

Date: Sun, 27 Jun 1999 22:58:42 -0700
From: Anti-SpamNameHere <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox

Mr.Savard's concern over the possible (yet can be shown to be small in
probability) exposure of the message plaintext in the ciphertext output
of the OTP encryption can be mitigated with the use of code phrase books
common to Alice and Bob, who we assume are communicating here with two
copies of the OTP.  Alice takes the original message M and converts it
into a new message M' by substituting nouns, verbs, adjectives, entire
phrases that appear in M with alternatives in the code phrase book.  The
plaintext M' is now encrypted with the OTP.  Bob decypts M' with his
copy of the OTP and applies the code phrase book to regenerate M.  For
example, "The eagle has landed" may literally mean a raptor touched down
within sight of Alice.  Or, Alice may be reporting that she and her
special forces contingent just landed in the designated LZ with no
resistance and are on their way to the target. 

The substitution phrases must NOT rely on the shared history or
culture/sub-culture of ALice and Bob.  Assume Trent spots a cleartext
phrase in the ciphertext. Trent will know about Alice's and Bob's pasts,
what their interests are, their families, employment, education, habits
- anything public, assume Trent knows it. A random book of code phrases
(?) might be the best (and that's just as difficult to generate as the
random OTP.)  "The eagle has landed" holds strong cultural meanings to
different groups (Apollo 11 - moon landings, t

Cryptography-Digest Digest #790

1998-12-23 Thread Digestifier

Cryptography-Digest Digest #790, Volume #8   Wed, 23 Dec 98 08:13:03 EST

Contents:
  Re: Cryptography FAQ (01/10: Overview) (Gramps)
  Re: On living with the 56-bit key length restriction
  Re: Cryptography FAQ (01/10: Overview) (Karl-Friedrich Lenz)
  Re: HELP! Who can decrypt this? (Damian Weber)
  Re: md5 sample implementation (David Broughton)
  Re: HELP! Who can decrypt this? ([EMAIL PROTECTED])
  Re: md5 sample implementation ("Steve Sampson")
  Re: Stego in jpeg files ("Steve Sampson")
  Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
  Re: Encryption Basics ([EMAIL PROTECTED])
  Re: On living with the 56-bit key length restriction (Mok-Kong Shen)



From: Gramps <[EMAIL PROTECTED]>
Subject: Re: Cryptography FAQ (01/10: Overview)
Date: Tue, 22 Dec 1998 23:45:42 -1000

Bruce Schneier wrote:
> 
> This FAQ is over four years old.
> 
> It seems reasonable to update it.  Is there a cabal in charge of the
> FAQ, or has it been orphaned?

That information is available on a need to know basis, and you don't need 
to know.

>Is anyone interested in working on an update?

I can neither confirm nor deny this.
 
> Bruce

Many cryptographers are currently busy evaluating the AES candidates, so 
we don't have time to educate the unwashed masses while we try to figure 
out if Twofish is a quad-round or dual-round cipher so that we can fairly 
make comparisons with the other 14 candidates. You may ask David A. Scott 
if he has time to revise the FAQ verbiage. If you want his e-mail 
address, just ask for it.

Gramps

--

From: <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 17:38:08 +0100

On Tue, 22 Dec 1998, Mok-Kong Shen wrote:

> [EMAIL PROTECTED] wrote:
> > 
> 
> > The problem is not export of algorithms - nobody is able to control this,
> > and - much more important: There are already enough algorithms for all
> > purposes. This may change with the development of new computers and new
> > cryptographic attacks, but surely blowfish and AES will be strong
> > algorithms while this stupid crypto law will be gone.
> > 
> > The problem is software: Keep people from using strong algorithms in
> > commercial mailtools and other IP tools, in office programs and databases
> > and you are able to destroy most of the cryptographic infrastructure.
> 
> If nobody is able to control export, why does there exist export
> regulations as such and why does there exist authorities whose
> duty it is to exercise such controls?? (Or why did the government
> officials take the trouble to agree on export controls?) 
> ...

It is impossible to control algorithms, but it is possible to control the
export of software.

US law allows to export algorithms as long as they aren't in
mashine-readable form while the export of cryptographic software isn't
allowed.

> > A program that does the complete job from reading from your soundcard to
> > sending data to the phone line doesn't allow to add a second program to
> > superencipher your communication.
> > 
> > Once superencipherment is a single module it isn't exportable.
> 
> Modern software is structured into modules. There is certainly a
> module that does a mapping from bits to bits, i.e. the proper
> encryption part. If one can export two encryption pieces into a 
> foreign country, it shouldn't require an expert in software to 
> concatenate them, provided that these have compatible interfaces.
> 

It's quite a hard job to change a module without knowledge of the sources
of the program.

> >
> > > > Even export of OTPs from the US is allowed, so I'm quite sure.
> > > >
> > > > The main reason is: OTPs are not very useful.
> > >
> > > I prefer not to go far into OTP here (I plan to initiate a thread
> > > related to that sometime later.)  But back to the main item above,
> > > employing multiple channels means simply to divide a given message
> > > into several pieces and encrypt these (preferably with different
> > > keys, but still using 56-bit algorithms) and send these through
> > > different channels. The analyst then has the trouble of keeping track
> > > of the separation done. Note in particular that the pieces may be
> > > sent at different time points, i.e. intentionally non-synchron, so
> > > that the identification of those pieces that belong to one and a
> > > single message is a formidable one.
> > 
> > This doesn't work for real-time communication or in cases where it is
> > impossible