Re: Automatic passphrase generation

[j]

-BEGIN PGP SIGNED MESSAGE-

Steve Reid <[EMAIL PROTECTED]> wrote:
> 
> This is not nearly as good as I had hoped. Does anyone have any
> suggestions for producing output that is more correct english? I'm
> wondering if maybe the lexicon I'm using isn't so good. Or maybe my
> knowledge of sentence structure hmm, with Yoda on par it is.

I tend to favor long passphrases with full meaning taken from real
works:
"d God said, Let there be light: and there was light. And God 
saw the light, that it was good: and God divided the light
from the darkness. And God called the light Day, a"

Obviously, if you know it comes from a book you don't need to random
try for the key. But still, and if you don't take actual sentences,
you get a nice number of options (e.g. starting at any word and using
the next 20-40 ones you'd get ~[size-range] * [number-of-words-in-book
- - min-size-of-passphrase]). Using partial words would increase options
proportionately. That's still too little.

But, make it be a bigger number of books and you get a bigger number of
options. 

Use a thesaurus to substitute words by synonyms and increase it (just
think how many alternate versions of Murphy's law there are around).

"...
peered the light, that it was fine: & Deity parted the flame
..."

Makeing use of alternate (mis)spellings you may further increase 
uncertainty.

"...
peered the lit; that 'twas fin -- & deity parted the phlame
..."

Making its length have greater variability does so even more. Mixing 
various languages (if feasible) helps a bit more...

"...
vu la lumier; that 'twas fin -- & deity parted the phlame
..."

Yet, for automatic generation you are bounded by electronic books,
which are still relatively few. But there's the Internet with a 
source of electronic text in the form of web pages, e-mail, USENET 
news messages; and there are translation tools, and so on...

Oh, and don't forget acrostics: take the first (or second or...) 
letter/word from a poem and off you go.

So it would run something like

pos = random number between 0 and collection-size
go to pos in literary-collection
size = random number between min-len and max-len
phrase = fetch size characters/words starting at pos
for every work in phrase
randomly select synonym in thesaurus 
with probability p = f(x)
randomly select equivalent in language Y 
with p = f(y)
randomly select alternate (mis)spelling in 
degenerate thesaurus with p = f(z)
for every symbol/character in phrase
randomly select alternate equivalent with p = f(v)
& so on...

Obviously too, after several transformations you may as well end up
with a nonsensical sentence. Note that repeating the steps more than
once will result in sensible meaning drifts (adding to the fun and the
entropy).

I may be wrong, but my impression is that increasing entropy may not 
be so difficult with long enough (>150 char) fragments.

It may also help producing the passphrase and showing the user the 
process used to develop it so s/he may learn to do it by him/herself. 

Just my 2c worth.

j


-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: noconv

iQEVAwUBORgtvrgsTQLvQjxFAQEzEAf/e1f1OvfBDaOimrPJb3fh75sHm+vxHtmK
Bo13sYdfd+PF3+c9Cp8oPv00dC68L2XazS4AeWqYJNaIUjeCrI7GwncSxZycKlBa
UF30PJCWR/pg8fiBva4Ay+kL+6sR5cPtPzjpW/0SeYHyJ6wuxxulhqUt5fR7BsMq
V/ChQyrV/8jMCmOYILTmcwtgVJ4Zg0mGdNqDbUmIE2bqKwowmc5FosS8GBSQp9mz
LVouObnZ6qTwO+Pb78YOLLAphA/sA7f6NddWGfqHcEsAm69CtGXM5rUhiw4J6Iyg
0ezqDzvYSVXNQtZ6pGOMXhMH3D9J2CWHjwrpXXPUlEPPKRlMoZfxhw==
=rqo8
-END PGP SIGNATURE-

Newsletter on Internet voting, privacy and security issues

[Lance J. Hoffman]

I'm delighted that this is being made available.  However, I think the
newsletter should fix its subscription policies first.  It appears that by
subscribing you agree to receive email information from Safevote or any of
its business partners. A "business partner of Safevote is an entity such
as, but not exclusively, a licenser named in the section "LICENSES AND
COPYRIGHTS"  [in their legal notice] or one of Safevote's OEM, VAR or
Reseller distributors."  There is no such section, though there is one
"MARKS, COPYRIGHTS, AND LICENSES".  Presumably this information (who the
business partners are) changes over time.

Many enlightened firms give the option to just subscribe and receive
nothing else unless you ask for it. I'd hope that Safevote would add that
option also.  

Lance Hoffman

Lance J. Hoffman, Director, Cyberspace Policy Institute
and Professor, Dept. of Computer Science, The George Washington University,
Washington DC 20052.  Phone (202) 994-5513 Fax (202) 994-5505.
http://www.seas.gwu.edu/seas/institutes/cpi/

Re: time dependant

[j]

-BEGIN PGP SIGNED MESSAGE-

>I want to know whether there is a crypto building block which doesn't allow
>someone to open an encrypted message before a certain date.
>
>[Damn hard. Math functions don't grok "date". The only reasonable way
>to do this without a trusted third party is to pick an encryption
>algorithm that will take at least as long to decrypt (in likely
>available computer time) as are needed. -Perry]
>
Agreed. Even so, the user might gain access to a faster CPU or
multi-CPU implementation.

The only workaround I see is to include the date in the IV _AND_
make sure the current date can only be checked from a trusted, authenticated 
time server, _AND_ that the user can in no way tamper with your program
code at all (even if he may not modify it, he might gain enough 
intelligence to simulate the time server by DNS spoofing or some such).

That or you simply encrypt your message with a suitable private
key which is held secret by you or a trusted party until the date
specified. Until that time the user may harass the key holder as much
as he wants, but only after that date will the decryption key be 
available and the message readable.

The key holder needs a trusted source of time to make sure he
is not releasing the key too soon or late. That, in turn depends on
how paranoid you are, but in general a GPS source might be enough.

j


-BEGIN PGP SIGNATURE-
Version: 2.6.3i
Charset: noconv

iQEVAwUBOMZHZrgsTQLvQjxFAQE0iQf+PhhxfOj5DTp5a8saJn71QYEl63BM3N8W
4NUeb/WFkCbmvtaMe3Cz422xqZbPaGoO7yLVOZFv5Sp9fHLIbcUsdMEleElvThcj
qxKslo1NJN7HgmyWrFXmekaBEbAor/LQs1HpQ5mSqU//8WknEs4ZwjFdQzZ9p6QM
pbaeK9WP6o6fbLLqKzBzXVsJhmKrpGsmK4PwdKKb/MJ3zNdOOSRxJfCQSoJF8El4
Yh2SzL2nP66M9LSostEb1jjBwiJarPDjuJufsGov77uxD/sPJTPYgccy0006ezF6
5QBDIB3RjLG+e1FdjgGcCUQkoH13NpdYkOrFT79Q3R538SedE768OA==
=/VtF
-END PGP SIGNATURE-

Re: Godzilla crypto tutorial updated

[Shabbir J. Safdar]

[I have sent to Declan, cypherpunks, and cryptography.  Please 
forward appropriately. -Shabbir]

ICIJ, a working network of the world's leading investigative 
reporters, is seeking volunteers to help ICIJ members in Latin 
America install PGP.  Note that PGP training is provided by ICIJ 
staff, and not at issue.  However we need assistance in getting PGP 
installed on several members' computers in Latin America.

If you have the technical background to help a novice computer user 
install PGP, and are in or near Lima, Peru, Buenos Aires, Argentina, 
or Mexico City, Mexico, please contact Maud Beelman at 
[EMAIL PROTECTED]  Reasonable expenses can be accomodated.

ICIJ members are probably behind many of the big investigative 
stories you know and love, including the research and exposure of 
ECHELON by ICIJ member Duncan Campbell.  Give something back to the 
world by lending them a hand!  To learn more about ICIJ (the 
Investigative Consortium for Investigative Journalists), please go to 
http://www.icij.org/

Thanks!

Re: The problem with Steganography

[j]

> question becomes, without identifying the location of the ciphertext in a
> prior agreement or on some outside channel, can a person communicate with
> friends without alerting enemies to the existance of secret communications?

In this case you are entering the realm of psychology. There may be a number
of methods, but they should be explicit enough for the friends to notice, and
this in turn depends on their knowledge and willingness.

How so? Some people may be intelligent enough to notice that letters from
their bank form an acrostic of a URL, but others may need detailed
explanations about what stego is.

Bottom line is, you know your friends, you know your enemies, use your
imagination.

Example: money laundering works in almost every country, if they can "hide"
their activities so can you too. Or you may use hidden knowldege about them
and refer to it. Or you may trade off a major gain for a minor loss, say
become a cigarette smuggler in the foreground to hide your setup message.

Again, that all falls in the realm of psychology.

    j

Re: Unrestricted crypto software web posting

[Shabbir J. Safdar]

Amazing.  If you could get this address publicized far wider than the 
original BXA address, it would save the folks at EPIC countless hours 
of FOIA filings to find out what's been sent to [EMAIL PROTECTED] :-)

-Shabbir

At 3:37 PM -0500 1/20/00, Matt Blaze wrote:
>Consider it done; the alias:
>
>   [EMAIL PROTECTED]
>
>now appends to http://www.crypto.com/exports/mail.txt, and also mails to
>[EMAIL PROTECTED] (currently empty, but that will change as people use it).
>
>-matt
>
>
>  > Wouldn't it be great if "we" could get put on the "[EMAIL PROTECTED]"
>  > mailing list?  Failing that, perhaps eff.org, crypto.com, or similar
>  > could set up a "export-notice" mail alias that forward to the BXA,
>  > but also archives them for folks (e.g., JYA :) to keep.
>  >
>  >/R$
>  >
>  > PS:  Just for the heck of it, I tried something and got back:
>  >The message that you sent was undeliverable to the following:
>  >[EMAIL PROTECTED] (user not found)
>  >[EMAIL PROTECTED] (user not found)
>  >
>  >Possibly truncated original message follows:
>  >...elided
>  >

Re: Universal Quantum Computers

[Stanley J Houghton]

I realise it was a comment in jest but this area is more significant than
many of us may think.  

If quantum computation comes of age, cryptography will have to change
enormously since we are faced with potential new technology that overcomes
classical limits underlying cryptographic systems, eg factorising very
large numbers.  I am referring to the enormous parallelism that may be
achieved through superposition of values in quantum bit based registers.

See
http://eve.physics.ox.ac.uk/qcweb/intro/intro.html
and I believe
http://www.qubit.org 
for relevant information.

Hope it is of interest

Stan


At 08:46 01/12/1999 +, Ben Laurie wrote:
>People may be interested in last week's Nature article, D. Gottesman and
>I.L. Chuang, "Demonstrating the viability of universal quantum
>computation using teleportation and single-qubit operations", Nature
>402, 390-392.
>
>One thing that should make software authors jump for joy is that the
>method involves quantum software that is hard to make yet is consumed
>during the computation. Enforcable software leasing, woo! [1]
>
>Whether it is of any significance that the authors work for Microsoft
>and IBM respectively I leave to the reader to decide.
>
>Cheers,
>
>Ben.
>
>[1] No, I don't think this is a good thing.
>
>--
>http://www.apache-ssl.org/ben.html
>
>"My grandfather once told me that there are two kinds of people: those
>who work and those who take the credit. He told me to try to be in the
>first group; there was less competition there."
> - Indira Gandhi

Re: DEA says drug smugglers used crypto & Net but cops got around it

[Marcus J. Ranum]

>>including use of the Internet, encrypted telephones, and cloned cellular
>>telephones

They don't say what "encrypted telephones" mean, either. Remember,
these are the same guys who try to tell people that spread spectrum
is "encryption" or at least "secure."

I'll bet $100 to a $1 that if there was a way to find out, we'd
find out that the "encrypted telephones" in use in the case in
question were not "encryption" as most of the members of this
list understand it. Is there enough information in Mr. Marshall's
description to be able to associate the FUD with a case and then
find out what kind of evidence they present?

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Re:

[Marcus J. Ranum]

>What happens if you happen to come home early and 
>catch these guys in the act? They can't reveal 
>their methods; so do you just "disappear"? 

A more positive way of looking at it is that _they_ can't reveal
their methods but _you_ can. If you made yourself look sufficiently
like a cheese that you caught a spook-mousie you could go public
with the information (especially if you _were_ innocent) and you
could embarrass them bigtime.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Re: US Urges Ban of Internet Crypto

[Marcus J. Ranum]

I've thought for some time that it's time to just solve the
problem.  All we need is a couple hundred million bucks.
Given that Ross Perot was able to make a credible run for
President on a hundred million dollars, it should be perfectly
feasible to find someone who is electable, marketable, has a
skeleton in his closet, and who will sign an executive order
once elected.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Clear Session ID in SSLV3

[Marcus J. Ranum]

Does anyone have a pointer to why the session ID in SSLV3 is
in the clear, rather than encrypted? I'm sure there's a good
reason for it (audit? logging? other...?)  but I'm trying to
pin down exactly why it was done that way. Can anyone point
me in the right direction?

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Relative use of SSLV3 versus SSLV2

[Marcus J. Ranum]

Does anyone out there have any statistics about usage of
SSLV3 versus SSLV2? I'm trying to get a feeling for how much
product support there needs to be for V2 -- is there even
a significant user base for it anymore? Does anyone keep any
measures of version usage??

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Micro lock?

[Marcus J. Ranum]

I saw a thing on CNN today about a micro silicon lock that they
are developing at Sandia. Of course, since this was CNN, it was
going to be the solution to internet security. It apparently is
a micromachine with "over a million combinations" (WOW!)

Anyone know anything about this device? I can't think of what
good it'd be that a microprocessor with some crypto can't do better.
Which must mean I'm missing something since it presumably took
a lot of work to make.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Re: [IRR] Problems with Eudora plugin for PGP 6.0.2i

[J Horacio MG]

~~> From: Jon Callas <[EMAIL PROTECTED]>
~~> 
~~>1. All encrypted or clearsigned messages go out as _attachments_, and
~~>not as message bodies. This leads to a profusion of files with the
~~>extension .MSG in the \WINDOWS\TEMP directory. The plugin apparently
~~>does not delete these files after sending.
~~> 
~~> You probably have the preference for "use PGP/MIME by default" turned on.
~~> Turn it off. MIME security encodings are a crock, as you well know.

Blaming MIME/PGP encoding for what a crappy O.S. is not able to deal
with seems a bit unfair to me.

~~> With all due respect, (1) is neutral to security. (2) is debatable. I know
~~> that many people have complained that the plugin did *not* include the
~~> .sig. I've found it annoying myself, because my old sig included contact
~~> information and I wanted that signed. I think that (2) is fixing a bug,
~~> myself.

There's enough information in a mail headers, plus you may add more...
if that weren't enough for you, then you may still add a personal sig at
the end of the message.
Digital signatures are for verifying the sender, and they must keep
functional in this line (which I think pgp/mime adds to this
functionality).

Regards

P.D.  using Mutt and GnuPG with no problems whatsoever (under
Debian/Linux).
-- 
Horacio
[EMAIL PROTECTED]
Valencia - ESPAÑA

More on Triple-DES in Schlumberger's Java Card

[J. Orlin Grabbe]

In a previous email, I commented on problems in the Triple-DES
implementation in Schlumberger's Java Card (which is called the
"Cyberflex Access Card").

Apparently Schlumberger has addressed some of these problems
with a new version which has an ATS (answer to reset) with a
hex string ending in "...811F".  The previous version ended in
"...810F".

Following is a copy of email from Cyberflex Project Manger
Neville Pattison.

Orlin Grabbe
http://www.aci.net/kalliste/homepage.html

*
Hello Orlin,

I have been made aware of your report on our Cyberflex Access card
and it's crypto deficiencies.

Can you let me know which Cyberflex Access you used for the tests.
By the sound of it you used cards that the ATR ends with ...810F. This
version of the card had several problems working with DES. Keys cast
from byte arrays in Java. In Cards ending with ...811F we have attempted
to fix most of these problems.

I wrote CryptoTest as a simple example of using the new crypto commands.
This was written for the revised Cyberflex Access cards with ATR ending in
...811F. I probably didn't make that clear.

I would be glad to send you some revised cards if you don't have them at hand.
I have some release notes too that describe the other areas that are known to be 
problematic etc.
I'll enclose this with new cards.

Where do you want me to send them?

Regards
Neville
**
Neville Pattinson
Cyberflex Project Manager.

http://www.cyberflex.slb.com

Schlumberger Austin Product Center,
P.O.Box 200015
Austin, Texas, 78720-0015
USA.

Email: [EMAIL PROTECTED]
Tel+ 1 512 331 3297
Fax+ 1 512 331 3059
**

Triple-DES in the Schlumberger java card

[J. Orlin Grabbe]

A javacard created by Schlumberger (the "Cyberflex
Access Card") both implements cryptographic functions
(RSA, triple-DES) and allows you to download your
own programs to the card.  Moreover, you can reuse
the EEPROM space by deleting a program and
downloading a different one into the same space.

Here I will comment on Schlumberger's implementation
of the javacard specification with respect to triple-DES
(3DES). Schlumberger has a sample java program showing
how to do 3DES on the card posted at their Austin web site
for anyone to download (http://www.cyberflex.slb.com).
(This program will not run without the encryption engine
on the Access Card.  Schlumberger will only send
encryption-enabled smart cards to U.S. addresses.)

There are some problems with the 3DES implementation.

I will begin by explaining some of the differences
between ordinary java and javacard java, as this will
also highlight some features that are specific to
Schlumberger's  implementation of the javacard
specification.

Programs for the javacard are simply written in java.
But because of the resource constraints on a smart card
(memory and processing power), some of the features
of java cannot be used, however.  These include
32 and 64-bit integers, floats and doubles, unicode
characters, threads.  There is no dynamic class loading
and no garbage collection.

Since there is no dynamic class loading, the java virtual
machine can be (and is) split up into two parts.  The
first of these is used as a preprocessor to further process
the java byte code before downloading onto the card.

Schlumberger's preprocessor is call "mksolo32.exe".
So suppose you write a java program des3.java.  You
then compile this with the java compiler in the ordinary
fashion to des3.class.  Next, you compile des3.class with
mksolo32.exe to create a file called des3.bin.

Note that in the javacard documentation the extention of
compiled class programs is ".cap" (for compiled applet)
not ".bin".  But Schlumberger calls its compiled class
programs "cardlets" instead of "applets", and the
change in name seems justified, because in the
Access Card you can write java programs that use the
main() method, as well as those that extend the
Applet class.

After compiling des3.class to des3.bin, you are ready
to download des3.bin onto the card.  Schlumberger
provides a software development kit for downloading
and managing cardlets.  The kit also comes with a
cardreader-the Lintronic 210, which does not need
a separate power supply, because it draws power
from the keyboard port. (The kit also contains an
APDU manager, for sending byte instructions to
the card, and receiving and displaying byte output.
Alternatively, you can use your own card terminal
implementation.)

To download the des3.bin cardlet, you only need to
assign it a filename and sign it with a verification
key corresponding to the cardlet verification key
which is already stored on the Access Card.
The Access Card will authenticate the cardlet before
allowing it to be download into EEPROM. (This is
in addition to the requirement to authenticate yourself
to the card through one of the card's authentication
keys, which shows you have permission to perform
this type of activity.)

Once the program (des3.bin) has been downloaded
on the smart card, you create an "instance" of the
program, which includes an allotment of memory
space for the data container needed by the program.
You can create multiple instances of the same
program

The program is accessed by sending it bytes (APDUs)
in five-byte instruction sets, along with any data.
These are usually labeled {CLA, INS, P1, P2, P3,
data}.  P3 is the length of the data.  CLA is the
"class" byte, while INS is the "instruction" byte.
P1 and P2 are there to be used as switches (much
like CLA and INS, except that CLA and INS must be
specifically declared).

The 3DES program listed at Schlumberger's site is
called CryptoTest.java.  The following group of
APDUs does a triple-DES ECB encryption on the hex
string "0102030405060708": {03,50,00,00,08,
0102030405060708}.  The output from the card should
be "01B45F3A1C9C703E".  Cross-checking with other
3DES programs shows this is the correct sequence
of encrypted bytes.

However, the CryptoTest program simply locks on
the card that came with my development kit.

Inspection of the code shows that the following
line under the RunTest5() class must the changed
from

des3key.setKey(key3, (short)0);

to

des3key.setKey(key3, (short)0, (short)0, (short)16);

This part of the program then runs fine.  Similar
changes must be made in RunTest1 (a DES encryption),
RunTest2 (another DES ECB encryption-decryption),
RunTest6 (a MAC with 3DES), RunTest7 (a MAC with
DES), and RunTest8 (3DES on a 24-byte message to
illustrate cipher-block chaining).

With this change, Tests 1-5 will run correctly.
However, Tests 6-8 still will not work.  These
three latter tests use cipher-block chaining, so
as you might expect, there is a problem with
the ini

Triple-DES with the Cryptix class library

[J. Orlin Grabbe]

I have found the Cryptix class library works fine for
3DES and other encryptions.  It's a little slow.

Here are two java programs I wrote which illustrate
how 3DES works using the Cryptix class library.

The first program encrypts a string (in the program)
using a key (in the program), and prints the string,
the key, and the encrypted string out to a text file
("DES-EDE3.out").  Sample output is shown following
the program listing.

The second program generates its own 3DES key, prints
this out to a textfile ("DES-EDE3.out"), reads in a
plaintext file (passed as an argument to main()),
encrypts the plaintext file with the key, and writes
the ciphertext to a ciphertext file.  Then, to check
the process, it deciphers the ciphertext bytes that
are still in memory and writes these out to to the
textfile.  Next, it reads in the ciphertext file,
decrypts the ciphertext, and also writes the decrypted
bytes to the textfile.  Sample output is shown also.

Orlin Grabbe
http://www.aci.net/kalliste/homepage.html


/*test2x3DES.java***/

//
/* test2x3DES.java takes a 3DES key input   */
/* and a text string from the program,  */
/* encrypts the string, and writes the key  */
/* the plaintext string, and the encrypted  */
/* result to a file DES-3EDE3.out   */
/* If cipher block chaining (CBC) is used   */
/* instead of ECB, an intilization vector   */
/* must be set first (lines not included).  */
/* --Orlin Grabbe   */
//

import java.io.*;
import java.security.*;
import java.math.*;
import cryptix.util.core.BI;
import cryptix.util.core.ArrayUtil;
import cryptix.util.core.Hex;
import cryptix.provider.key.*;


class test2x3DES {

public static void main (String[] args) {

 try {
 FileOutputStream outFile1 = new FileOutputStream("DES-
EDE3.out");
 // Note: PrintStream is deprecated, but still works fine in
jdk1.1.7b
 PrintStream output1 = new PrintStream(outFile1);

 RawSecretKey key2 = new RawSecretKey("DES-
EDE3",Hex.fromString("3812A419C63BE771AD9F61FEFA20CE633812A419C63
BE771"));
 //Use the following line instead for DES encryption
 //RawSecretKey key2 = new
RawSecretKey("DES",Hex.fromString("3812A419C63BE771"));
 RawKey rkey = (RawKey) key2;
 byte[] yval = rkey.getEncoded();
 BigInteger Bkey = new BigInteger(yval);
 String w = cryptix.util.core.BI.dumpString(Bkey);
 output1.println("The Encryption Key = " + w);
 Cipher des=Cipher.getInstance("DES-
EDE3/ECB/NONE","Cryptix");
 //Use the following line instead for DES encryption
 //Cipher des=Cipher.getInstance("DES/ECB/NONE","Cryptix");
 des.initEncrypt(key2);

 byte[] ciphertext =
des.crypt(Hex.fromString("01010101010101010102030405060708090A0B0
C0D0E0F101112131415161718"));

 /* print out length and representation of ciphertext */
 output1.print("\n");
 output1.println("ciphertext.length = " +
ciphertext.length);

 BigInteger Bciph = new BigInteger(ciphertext);
 w = cryptix.util.core.BI.dumpString(Bciph);
 output1.println("Ciphertext for simple encryption = " + w);

 /* decrypt ciphertext */
 des.initDecrypt(key2);
 ciphertext = des.crypt(ciphertext);
 output1.print("\n");
 output1.println("plaintext.length = " + ciphertext.length);

 /* print out representation of decrypted ciphertext */
 Bciph = new BigInteger(ciphertext);
 w = cryptix.util.core.BI.dumpString(Bciph);
 output1.println("Plaintext for simple encryption = " + w);

 output1.println(" ");

 output1.close();

  } catch (Exception e) {
System.err.println("Caught exception " +
e.toString());
  }

 }}
/end of test2x3DES.java**/


/**sample output from test2xDES.java**/

The Encryption Key = Multi-Precision Integer 190 bits long...
 sign: Positive
 magnitude: 3812A419C63BE771 AD9F61FEFA20CE63 3812A419C63BE771

ciphertext.length = 32

Ciphertext for simple encryption = Multi-Precision Integer 255
bits long...
 sign: Positive
 magnitude: 741038365B8C4BC2 01B45F3A1C9C703E 5DE9007B2288BDBD
5203FEB4F80C5BD0

plaintext.length = 32
Plaintext for simple encryption = Multi-Precision Integer 249
bits long...
 sign: Positive
 magnitude: 0101010101010101 0102030405060708 090A0B0C0D0E0F10
1112131415161718
/***end of sample output test2x3DES.java*/


/**testx3DES.java/

//
/* testx3DES generates its own 3DES key */
/* then reads in a plaintext file, encrypts */
/* the plaintext file, writes the encrypted */
/* bytes out to a ciphertext file.  Next it */
/* decrypts the ciphertext bytes which are  */
/* still in memory, and writes these to the */
/* general output file.  Next it reads in   */
/* the ciphertext file, decrypts it and */
/* writes this to the general output file.  */
/* If CBC is used instead of ECB, lines to  */
/* set an initialized vector will have to   

What's it worth? (Re: references to password sniffer incident)

[Daniel J. Frasnelli]

> With this being the state of the art in protection, why bother with
> intercepts, cryptoanalysis etc?

Why try to protect your information if someone is eventually going to
discover it? Like so many things in life, the game of security is based 
on the probability of a certain event occurring and what you can do to
reduce the probability of occurrance.  
A student came up to me after a security course the other day, and asked a
simple question: How do you determine information security? 
I told him something that sounded good at the time (sounds wordy now) -

The level of information security you can achieve is based primarily 
on three factors: 
1) How large your funding is.
2) Who you ticked off.
3) How large their funding is, and how motivated they are.

That's a funny thing to come out of the mouth of a security analyst, isn't
it?  But it's absolutely true in my opinion.  The best way to not have
people pickpocketing information from you is to keep a low profile and not 
do things to make Folks With Deep Pockets(tm) mad at you.  Now, I'm not
suggesting you go live out in a cave somewhere - Theodore Kaczynski
learned that information security through obscurity just doesn't work
after you annoy the good folks at the ATF and FBI.

It's been said before - there is no such thing as complete security nor
privacy, whether electronic or physical.  Everything in security is
relative; most people in the public would define their level of 
information security as how many locks on the front door, or how
well-tested the intrusion detection system is, or perhaps which vendor
developed their firewall software.  
I flip that on it's head and say it is the opponent (intruder) who
determines your level of security, not any barriers you quickly throw up
in their path.  If one untrained man is trying to get into your castle,   
a closed door with one lock may suffice.  If a herd of elephants with
Hannibal and his troops atop are charging your door - well, you should
find a good pair of jogging shoes and a large pot of coffee. 

The situation today is that we have a lot of products and methods that
work well for one line of defense but not another.  In the case of
computer security, you really need an adaptive solution that combines
various techniques during an attempted breech and raises the bar as the
attack intensifies.  A single technique or technology is just
not going to cut it with a sophisticated intruder.  If you choose a
single-track solution, be prepared to fight off a pack of lions with 
a toothpick. 

Dan

Re: P1363: Re: The name of "RSA"

[Michael J. Markowitz]

At 04:58 PM 4/9/99 -0400, Vin McLellan wrote:
>
>The discussion of alternative names for "RSA" has been an amazing
>and entertaining carnival, spawned by a wildly exaggerated interpretation of
>a 3/1/99 SDTI letter to the P1363 working group.  SDTI, RSA's parent firm,
>for which I have been a consultant for many years,  never said they were
>going to restrict the use of the term RSA by real people, or even members of
>standards groups. 

Vin:

1) the interpretation *by* the working group -- which, in the end,
is all that matters -- has not been exaggerated... and our response 
needs to be appropriate and consistent with our responsibility for 
the standard

2) that should be "RSADSI's parent firm" not "RSA's parent firm"  
(your slip is noted with appreciative humor)

3) SDTI may not have said *they* would "restrict the use of RSA by 
real people," but RSADSI has a history of doing exactly that going
back at least 12 years (yes, Schlafly and I are real people as well 
as members of P1363); a legitimate fear is that, once the patent
expires, this will be the preferred means of stifling competition

4) the P1363 working group has no reason to believe that SDTI will 
be any less litigious in the future than RSADSI was in the past... 
in fact, there is considerable recent evidence to the contrary.

> The RSA brand name  issue, as SDTI sees it,  is whether commercial
>competitors will be allowed to mislead consumers as to who crafted a module
>of implementation code.  

I find it simply amazing that you presume to speak for SDTI (as not 
even Margaret Seif seems to be doing that very well), but since you've
assumed that role...

>anyone curious about SDTI's actual claims about RSA as a brand
>name should check out SDTI's new letter to IEEE at:
<http://grouper.ieee.org/groups/1363/letters/SecurityDynamics2.jpg>

I've checked out this letter and I'm still curious... and confused.  
It says "... we ... accept that ANY party creating a product which
conforms with the P1363 standard will be able to state that the
product incorporates the RSA algorithm..."  (emphasis mine)

Since you're speaking for SDTI now, was it in fact Margaret's intent
to provide Schlafly and me with relief from that particular clause 
of our 1987 Consent Agreement that has since barred us from using 
the dreaded three letters in ANY commercial context?

Looks like we may see yet another letter clarifying this last one...
if only to add the list of individuals and corporations SDTI wants
to explicitly prohibit from using their "trademark."  Warning: that
list may look suspiciously like the list of entities who have
not licensed BSAFE.

-mjm


==
Michael J. Markowitz, VP R&D   Email: [EMAIL PROTECTED]
Information Security Corporation   Voice: 847-405-0500
1011 Lake Street, Suite 212Fax:   847-405-0506
Oak Park, IL  60301WWW:   http://www.infoseccorp.com   

RSA patent on ECC

[P. J. Ponder]

RSA has a note on their web site about a patent issued April 7, 1999,
which provides a memory efficient means of converting between polynomial
basis and normal basis stored numbers.

http://www.rsa.com/pressbox/html/990407.html

Re: references to password sniffer incident

[Daniel J. Frasnelli]

> At the 2600-coordinated Beyond HOPE conference (NYC, 1997), it was made
> very clear to users that passwords transmitted in-the-clear would be
Right, passwords always have been the weakest link.   
> panel singled-out an unlucky telnet user, announcing a domain name and
Not just telnet is vulnerable, as you know.  I've watched as 
security consultants ssh to a site, logout, and procede to login to 
another site using stock ftp.  The people are not stupid or anything,
they just don't think - hey, this protocol sends passwords in plaintext.  
You can get around that by establishing a secure tunnel or using 
Skip/an IPSEC implementation, but most folks don't do that yet. 

> Perhaps that the kind of shock factor that's necessary to get people
> (certain people, anyhow) thinking realistically about security.  We even
Ding ding ding, you've been awarded the "have clue" prize of the 
day ;).   Think I mentioned this on coderpunks, but Schneier has two 
"reality check" essays on Counterpane's site.  Good reading. 

> considered sniffing passwords and hooking up a line printer in a central
> location. nah! :)
Someone I knew who was using a weak password (a foreign word from a 
 semi-obscure foreign language) challenged me one day, claiming I would 
never find it out.  
A few keystrokes and a sniff later, the password was in hand.  
Using pop3 to transfer your mail to and from an offsite system 
can be very revealing ;) 
Seriously though, it's frightening to think of all the possible
ways an account can be compromised, and the limited public education
on how to prevent or delay many of these attacks.  

Dan

Stego for watermarking Perl5 code?

[Shabbir J. Safdar]

So I'm looking to protect some Perl code from the situation where someone
might break into my site and copy it and start marketing it.  I'm mostly
interested in going beyond what the lawyers are telling me to do, and it
occurs to me that it ought to be relatively easy to do stegonography over
Perl code, given the relatively free form nature of the language and the
fact that I can throw in all sorts of comments.

So, off I go looking through various online resources, only to find that
most of the tools are for watermarking image, audio, and video files.  The
few companies I've called so far say their utilities that work on text are
in prototype, or don't exist at all.  The Texto tool comes close, but isn't
really right.

I'm fairly motivated, and could adapt a decent library to a tool (in perl,
ofc ourse) should one exist.  Does anyone have any leads on where I might
start looking?

-S

Re: Newsnight Crypto Bazaar

[Marcus J. Ranum]

>Why would an eavesdropper need to modify the network configuration?  I would
>just hook up a sniffer and set it to promiscuous mode.

This talk of monitoring traffic at ISPs has me kind of
perplexed.

I'm the CEO of a company that makes network monitoring
and traffic analysis systems: just the kind of thing that
would presumably appeal to the spooks who are supposedly
doing this stuff. We haven't heard from them! :)

But that's irrelevant. I wanted to comment on some of
the technical problems inherent in tapping large-scale
networks. We've been living with them at NFR for over
2 years and let me tell you it's not as easy as just
slapping a promiscuous mode interface on a network and
collecting all the packets. First off, when you're doing
packet capture of, say, a fairly saturated FDDI ring,
running at 80% capacity, you're looking at, perhaps,
17,000 packets/second of varying sizes. Sure, you can
get a network card that will be able to handle that
in promiscuous mode, but doing anything with the data
becomes a trick. For proper spooky purposes, you'd want
to do stream reassembly (so as not to miss key words
in context) which is pretty expensive. We've found it
takes most of a 400Mhz intel box to handle just reassembly
and capture at those kind of speeds. Searching gets
comparably more expensive. Let's suppose you're The Spooks
and can throw custom hardware at it: a 450Mhz machine
with a TRW fast data finder chip on top of a partial
IP reassembly stack, and a fast RAID, would be adequate
for doing searching and select recording on a single
FDDI. But some of the big ISPs, like UUnet, are running
multiple rings with split traffic, and are running almost
entirely on switched architectures. Collating traffic
at a packet level between multiple switches is a Hard
Problem (at least we think it is, anyhow) when you
are dealing with huge streams of data that simply never
stop coming. It's not like you can process it offline,
there are queueing problems to deal with.

I'm sure that an IP ECHELON project would be well funded,
but I'm not sure that it's practical or feasible. It's
certainly not practical or feasible with off the shelf
stuff. If it were done with custom stuff it'd be a pretty
interesting (and obtrusive) looking unit. In the last
3 years I've been in a _lot_ of ISP's machine rooms,
and never seen anything that would look like the kind of
packet sucker from hell we're talking about. I also tend
to disbelieve that the ISPs are being tapped because a
lot of the networkers there are not the kind of folks who
would keep their mouths shut if that sort of thing was
going on in a major, organized way. Too many tongues would
wag. Is there any _proof_ that this kind of thing is
going on? I'd like to see some of the specs of the packet
suckers in question, as well as photographs of one
installed. Call me a doubting thomas, if you will.

In short: if someone thinks the spooks are actually
tapping big ISP backbones, I want to know where I can
buy the kind of stuff they're using! :)

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Re: new bill getting through congress?

[Shabbir J. Safdar]

The complete audio/video/written archives of that hearing are at
http://www.computerprivacy.org/archive/03041999/

The Deputy Director of the NSA (Barbara McNamara) testified; you can watch
the tape.

-Shabbir


At 5:27 PM -0500 3/11/99, Steven M. Bellovin wrote:
>In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes:
>>
>> Anyone know anything about this?
>>
>> Thursday March 11 11:15 AM ET
>>
>> Bill To Relax U.S. Controls On Encryption Advances
>>
>> WASHINGTON (Reuters) - A bill to relax strict U.S. export controls on
>> computer data-scrambling products passed a small hurdle Thursday,
>> gaining approval from a House Judiciary subcommittee by voice vote.
>
>Let me point folks at thomas.loc.gov.  30 seconds with it shows that the
>bill is H.R.850.  Hearings were held a week ago by the Subcommittee on
>Courts and Intellectual Property; this is presumably the panel that approved
>it.  It's also been sent to the Committee on International Relations.

Provable security & questionable reporting

[P. J. Ponder]

A rather sketchy and somewhat misleading article:

http://www.mercurycenter.com/svtech/news/breaking/merc/docs/084300.htm

Posted at 7:30 a.m. PST Friday, February 12, 1999 

New encryption code could remain a secret
BY MICHAEL BROOKS
The Guardian 
If you have an uneasy feeling about the security of Internet
commerce, you have probably reassured yourself that the
high-tech security programs which safeguard your privacy are
written by the world's best cryptographers. Think again.
Victor Shoup, a cryptography researcher at IBM's Zurich
laboratory, has come up with a world first: a practical encryption
technique that has provable security. You might be surprised to
learn that it may never make it onto the market.
Unfortunately for the public, quality and security are near the
bottom of the priority list when it comes to turning a scheme into a
product. The spoils go to the fastest.
``If you're first, you win, and it doesn't really matter if the product
is crap,'' Shoup explains. ``A lot of what's out there is not the best
that could be done, even without sacrificing any practicality.''
The upshot is that cryptographers have minimal say in the
development of new products.
<. . . .>


There is a related story, dated August 24, 1998, at:

http://www.zurich.ibm.com/News/CRYPTO/

Re: Quantum emulation

[Daniel J. Frasnelli]

(Disclaimer: Off-topic, but relevant to anyone who might be interested in the 
 quantum sim project)

> This is quite cool.
> 
> I assume this will come in handy for checking out some of the ideas in
> quantum computation and quantum crypto, long in advance of actually
> being able to build a real machine.  Proofs are very handy beasts, but
> there's something to be said for tinkering around, too...
I've been active on the mailing list for a couple months or so,
mainly testing "what about this?" ideas on our big iron machines. 
Quantum crypto is obviously my main motivation for involvement. 
> Very nicely set up website, too.
There is a remote possibility the project will be relocated to
Europe in the next couple months.  Without getting into the gory details,
a fellow wrote software to do quantum simulation on the Mac, patented it
in the U.S., and has threatened to sue all developers, users, etc. of
Open Qubit.  We obviously get around him by moving the main development
tree to a location not governed by such silly laws. 
> Wow. 63. And it's not exactly fast:
Multithreading has been discussed on the mailing list several
times.  At this point, memory efficiency of our implementation is 
a greater limit to the ability to do quantum factoring simulation
than processor speed.  I am attempting to guide the main developers
towards MPICH, PVM, and various distributed shared memory packages.
> That's right, 14 seconds on my AMD-K6/2-400[1] Linux box.
Your friend may want to apply the 
"yp-diagnostics_addon-pre-0.2.0rafal" patch to the source tree and 
recompile, for somewhat more meaningful statistics.  My system is 
a mean, lean 500Mhz 21164a w/2M L3 cache and 128M ram.  Because the
current implementation is bottlenecked at physical memory size,
the largest number I can factor is below 130.  I am, however, 
able to factor 111 in 3 minutes, 19 seconds (keep in mind that 
Shor's algorithm assumes exponential complexity)).  Not too shabby,
but I'd love to stick more memory in and see what she can really do.

Best regards and hope to see you on the Open Qubit list,
Daniel
-- 

Sites for Army "Basic Cryptanalysis" field manual & other resource

[Daniel J. Frasnelli]

> Seems to me we paid for this thing. Shouldn't it be available to all who
> are interested? IOW, where's the ftp site? Not that I would expect too
> much from it.
I mentioned to Mike in a reply that I honestly have no clue where
my copy came from (timestamp is from 1996).  I found hundreds of 
public FTP sites with the manual available from 
 using the keyword "basic_cryptanalysis".  
Having interested people download it this way is probably better, as they
can select a site close to them. 
Also, a student found and pointed out that the LANAKI 
(Randy Nichols) "Classical Cryptography" lecture notes can be found at 
.  They 
tend to go more in-depth with digram/trigram analysis of monoalphabetic
ciphertexts and character occurance frequency than the Army FM does.

Best regards,
Daniel 
-- 

Army "Basic Cryptanalysis" field manual legal status?

[Daniel J. Frasnelli]

Greetings,
We are teaching an introductory cryptography and computer security
course in our department.  One of my responsibilities is to create a resource
page with links to various useful documents, sites, etc. 
From my personal archives, I found a tarfile containing what appears
to be a scanned-in copy of a Department of the Army cryptanalyst field 
manual.  Not sure exactly where I found it, but I provided a local copy
for the students anyhow.  The professor called me to the floor on the 
issue of legality of this manual, and after reading the first few pages, 
I really do not know how to answer him.  
The document is Field Manual No. 34-40-2 (FM 34-40-2) and has 
"Headquarters.  Department of the Army.  Washington, DC, 13 September 1990"
on the first table of contents page.  Title is "Basic Cryptanalysis", 
and a nice little note at the bottom reads "DESTRUCTION NOTICE: Destroy
by any method that wilt prevent disclosure of contents or reconstruction of
the document".  Any idea if this doc has been placed in the public domain
yet? 
It's not a big issue for me, but the professor (obviously) does not
want to have an illicit book available from a public website on a school
server.  Apologize for being slightly off-topic, but chances are the 
crypto policy newsgroups have never heard of the document before.

Thanks,
Daniel
-- 

Re: PGP compromised on Windows 9x?

[Michael J. Fromberger]

quoth Tom Garner:
> Greetings/Salutations,
> 
> It troubles me, how lazy and stupid the average person is.  How many TIMES
> do we have to say "don't use a passphrase that is..." or "make your
> passphrase 8 ALPHA-Numeric...".
> 
> I say that it is TIME for programmers to QUIT giving us (and I say us, as in
> all of us), the opportunity to choose a passphrase that can be easily
> guessed by p.phrase hacking techniques.
> 
> Isn't it possible w/out degrading any further on PGP's side the ability to
> have someone enter a passphrase and its either scrambled, or rejected for
> having "English words" in it?
> 
> I've been reading for years how the PassPhrase is probably the only weak
> part in PGP, and why?  Why GIVE US THE choice?  Obviously we are not
> responsible enough to handle PassPhrase correctly.
> 
> I'm sorry to sound a bit harsh, but I'm sick/tired of reading about
> passphrases being weak, and passwords being weak, and there is only one
> reason, that is our laziness.
> 
> Tom
> ICQ:  4580576

While I think I agree with you in principle, there is an essential
dilemma here for the person writing the software: If users do not like
using your software, they will not use it.  "Inconveniences" such as
this are often a big sticking point for your average "user on the
street," if you will permit me to label the typical consumer so.

More broadly, this is a problem which affects developers of both
commercial and open source software.  In the commercial world, user
dissatisfaction translates into a customer for your competition.  In
the open source world, it translates into a derivative version of your
program which disables the "inconvenience" at will.  In either case,
this is strong negative feedback.

Ultimately, I think we all need to think hard about how to combat the
real root problem here, which is educating people.  

As I see it, there are three components of this:  People need first to
understand -what- security is, and what correlation it has directly in
their own lives.  Second, they have to understand -how- to maintain
security, both in terms of encryption products, and the personal
disciplines required to make them useful.  And third, they need to
understand -why- security needs to matter to them, not only for their
own sake, but also for the public good.

Right now, I think the public is at a fragile stage with regard to
cryptography and information security.  Choosing good pass-phrases is
part of the "how" stage -- and if they don't even understand "what"
yet, forcing them to do this is nothing but an annoyance.  

Turning off the user on the street is dangerous for us not only as
developers, but also in a political sense.  We need the people to buy
in to "our" model of privacy and security, with strong crypto and no
key escrow...rather than the usual NSA/FBI driven model where strong
crypto is carefully regulated and the government gets all the keys.
If we torque too many people the wrong way, particularly at this early
stage, we'll poison our own well.

So, in summary, while I think you have your heart in the right place,
I also feel this is a bigger and more serious problem than can be
fixed simply by trying to legislate behaviour with the code itself.

Cheers,
-M

-- 
Michael J. FrombergerSoftware Engineer, Thayer School of Engineering
  sting  linguist.dartmouth.edu   http://www.dartmouth.edu/~sting/
xmnr9kXP/a0kTU1wvI+WTgEKWIJc/WrzrCD59vsGC5XXrYzcv42dWnaJap44nvVUAexMIY06

Re: IQ.ORG Cryptography Server

[Daniel J. Frasnelli]

> mybox$ ssh -v -l irc -p 443 -L 6667:crypto.iq.org:70 irc.iq.org &
> mybox$ irc myname localhost:6667

Just want to point out that if you're using ssh 2.x, you need
to use the 'ssh1' executable because the iq.org server is running 
1.2.26.  

Regards,
Daniel  

An IBM announcement in Edupage, 28 January 1999

[P. J. Ponder]

This is a snippet from today's Edupage:

SECURITY-CONSCIOUS THINKPADS
IBM is offering a new feature on its popular ThinkPad laptops -- a two-layer
security system to protect the mobile machines and their files.  The IBM
Smart Card Security kit provides software that automatically encrypts data
as it is stored on a computer, and a personal ID smart card that carries the
encryption key for decoding the information.  In addition, an Asset ID tag
prevents access to data if the computer has been removed without
authorization from the designated premises.  Companies can place sensors
around doorways that will inactivate the computer the computer through a
wireless radio-frequency transmitter.  "Now you can tie the face to the
asset," says Sam Dusi, IBM's worldwide marketing director for ThinkPads.
"It's not just who left the building but what they left with."  According to
the Computer Security Institute, companies incurred losses of more than $11
million in stolen laptops during 1996 and 1997.  (TechWeb 28 Jan 99)



Edupage, 28 January 1999. Edupage, a summary of news about information
technology, is provided three times a week as a service of EDUCAUSE,
an international nonprofit association dedicated to transforming higher
education through information technologies.

you can get more info & subscribe from:
http://www.educause.edu/pub/pubs.html

RE: France Allows 128 Bit Crypto

[P. J. Ponder]

On Thu, 21 Jan 1999, David R. Conrad wrote:

> Doesn't this just amount to saying, "If we subpoena a document you have to
> turn it over or face the consequences"?
> 
> It seems to me that a) this is relatively non-objectionable and b) this is
> probably unavoidable.

There was a US case discussed in a similar thread a year or two ago (and I
think it was on this list, although it may have been on cypherpunks) where
the issue was a safe combination, and the power of the court to hold a
person in contempt until the safe was opened.  This seems similar to me to
the 'hand over the plaintext'.  My recollection of the case was that US
judges could force unwilling parties to divulge combinations to safes, and
therefore by extension, could also force people to reveal passphrases or
codes that were used to protect encrypted information.

As to whether or not it is objectionable, I guess that varies.  What if
the information had to do with government corruption, or the locations of
mass graves where the government had buried its political enemies?  Is it
not objectionable then for the government (judicial, executive, whatever) 
to compel witnesses to reveal the plaintext?  Maybe it was the risk of
government access to the data that caused it to be encrypted in the first
place. 

As to unavoidability, there has been discussion already on protocols that
require collusion, 'durress keys', etc.  It is a goal of some systems to
make this 'avoidable'.  This is part of what 'information hiding' is
about. 
--
pjp

> 
> > ... PLAINTEXT, not just the key.  That could present problems for
> > crypto-protection by multi-jurisdictional key-splitting applications.
> > 
> > Clearly, this has to be nailed down.  It could get ugly.
> 
> Certainly we should find out exactly what they mean, although as you know
> far better than I, we may have to wait until a French court rules on it.
> 
> David R. Conrad <[EMAIL PROTECTED]>
> This is why I love America -- that any kid can dream "I'm going to get
> naked with the President" ... and that dream can actually come true.
> What a great country!  -- Michael Moore

Patent restrictions on Crypto++ lib?

[P. J. Ponder]

Wei Dai's recently announced crypto library has some notes in it about
licenses and mentions in the documentation that there may be patent
restrictions on some of the code included in the distribution.  I figure
the RSA stuff is covered by a patent (due to expire in a year or two?) and
I know that IDEA is covered by a European patent and is only free for
personal use, not for commercial use.  Other than those, does anyone know
what other restrictions there may be on the software for US developers?

the software is at:
http://cryptography.org/cgi-bin/crypto.cgi/libraries/crypto30.zip

If anyone has looked into this, please let me know what you've found.
Thanks.
--
On an unrelated matter:
Great job Vin McLellan on your recent posting about Australia & RSA, &c.

Re: Ruthless.com

[Lance J. Hoffman]

I listened to "ruthless.com" on tape, but have not read the *paper* book.
I think the tape was abridged.  I was actually considering using the book
in an information warfare class I am teaching this spring.  Clancy weaves a
great yarn; however, the spectacle of a physical assault on a key escrow
center in California (as if the keys *there* would be stored in the clear)
and a number of other loose threads convinced me that my students could
(and have) written better scenarios/games themselves.

Robert Hettinga writes:

>With a back cover like that, it'll probably be a jingo-statist diatribe and
>Clipper apologia good enough to make even Dorothy Denning blow coffee out her
>nose, laughing so hard...

It is, but you can expect that from Clancy.  The book gets an A for writing
but a D for content.





Lance J. Hoffman, Director, Cyberspace Policy Institute
and Professor, Dept. of Electrical Engineering and Computer Science, The
George Washington University, Washington DC 20052.  Phone (202) 994-5513
Fax (202) 994-5505.  http://www.seas.gwu.edu/seas/institutes/cpi/

US House Commerce Comm. Press Release

[P. J. Ponder]

Excerpt from a US House Commerce Committee press release.  The full text
can be found at:

http://www.house.gov/commerce/releases/pr122198.htm

Talks about easing export controls on strong encryption, and there is
mention of creating a 'technologically neutral' national standard for
electronic authorization, seeing as how several states have adopted
dissimilar laws.


House Committee on Commerce 
News Release

For Immediate Release 
Contact: David Fish 
December 21, 1998 (202) 225-5735 

Chairman Bliley Announces House Commerce Committee Agenda

WASHINGTON, D.C. 
 The chairman of the House Commerce Committee, Representative Tom Bliley
(R-VA), announced the highlights of his committee

<. . . .>

"Moving to the exciting world of the INTERNET, the Committee will take
steps, including the passage of legislation, to further open up Electronic
Commerce, the new marketplace of the 21st Century. 

"First and foremost, the committee will continue to be a bulwark against
over-regulation and taxation of the INTERNET. I will not allow the
INTERNET to become a cash cow or plaything of the IRS and federal
bureaucrats.

"We also need a technologically neutral nationwide standard for electronic
authentication. This is the so-called electronic signature that allows
people to do business on line. 

"Add to that an easing of restrictions on the export of strong encryption
products. This is the technology that allows people to conduct safe and
secure transactions on-line by helping to prevent invasions of privacy and
security. 

"I am working with the industry to develop an enforceable and
self-regulating system to protect privacy on-line. People will not do
business on line if their finances, medical histories or other personal
information can be accessed by strangers. 

<. . . .>

-30- 

News Home 

The House Committee on Commerce
2125 Rayburn House Office Building
Washington, DC 20515
(202) 225-2927
[EMAIL PROTECTED] 

Calif. Gov't E-Commerce panel recommendations

[P. J. Ponder]

This is from a recent E-Commerce report in California.  It highlights the
'Cat Being Out of the Bag' argument against crypto controls.  The full
report is available from: http://www.e-commerce.ca.gov/


6  The federal government should overhaul its current restrictions on the
export of encryption technology, taking fully into account actual foreign
availability of comparable technologies. For example, Netscapes Internet
browser and e-mail application  "Communicator"  that incorporates 128-bit
encryption technology may not be exported from the US to foreign
consumers. Yet, using any of the popular Internet search engines, it takes
only a few minutes to find foreign-based websites from which one can
obtain free add-on software  independently developed by foreign software
developers  that will augment Communicator so that it will have 128-bit
encryption capabilities. This fact should justify eliminating the current
ban on exporting the 128-bit version of Communicator, and a truly rigorous
foreign availability review of encryption technology would support
substantially broader deregulation.


The report has a catchy title, too:
"If I'm so empowered, why do I need you?"
Defining Government's Role in Internet Electronic Commerce

Re: Building crypto archives worldwide to foil US-built Berlin Walls

[Marcus J. Ranum]

I've seen a lot of discussion on this list pertaining to making
crypto archives in order to foil increasing export restrictions.
Isn't this exactly the kind of thing that the eternity service
is designed for?http://www.dcs.ex.ac.uk/~aba/eternity/

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

Tommy Flowers, Engineer who cracked German communications, etc

[Paul J. Bell]

while Colossus is often said (mostly by the British (-: )  to be
the world's first
digital computer, (an argument i try to stay away from)  it
certainly wasn't a
general purpose machine.  it did run a program of sorts, but not
a 'stored program'
that was readily changed. there is no indication that it was
ever used for anything
other than the attack on the Lorenz codes.  changing the program
would have been a
non-trivial task and it's unlikely that Tommy Flowers would not
have been involved
in or at least aware of such a change, and he has specifically
said that to the
best of his knowledge, Colossus was used for only the one
purpose for which it was designed.

cheers,
-paul


-- 
"There is magic in the web" - Shakespeare (Othello, Act 3, Scene
4)