guess who likes anonymous Web surfing...
According to the 12 February Wall Street Journal, the CIA wants to surf the Web anonymously. They're buying a package called Triangle Boy from SafeWeb, though they're replacing the crypto with their own algorithms. And through their venture capital subsidiary (In-Q-Tel), they're buying rights to an equity stake in SafeWeb. The article notes the irony of a privacy company linking up with the CIA. Stephen Hsu, the co-founder, is quoted as saying "I'm sure we'll take a hit from the 5% of our most paranoid customers." And some folks are speculating that the CIA really wants to cloak cyberwar activities, or they want to learn the flaws of the product so they can penetrate anonymity. (Why not -- according to CNN, the NSA claims that Osama bin Laden has better communications technology than we do) --Steve Bellovin, http://www.research.att.com/~smb
Carnivore transformed
Today's Wall Street Journal reports that the FBI is changing the name
of Carnivore. It will now be known as the DCS1000 -- the "DCS" stands
for "Data Collection System".
Clearly, that resolves all of the problems with it.
--Steve Bellovin, http://www.research.att.com/~smb
Bleichenbacher finds flaw in DSA
According to CNN, Daniel Bleichenbacher has found a flaw in the
NIST-standard Digital Signature Algorithm. See
http://www.cnn.com/2001/TECH/internet/02/06/DSA.flaw.idg/index.html
for some details. Bleichenbacher says that he'll be presenting the
paper at Eurocrypt; it is not yet publicly available.
The attack is quite expensive; it requires O(2^64) operations, several
terabytes of memory, and 2^22 signed messages.
--Steve Bellovin, http://www.research.att.com/~smb
it's not the crypto
Every now and then, something pops up that reinforces the point that
crypto can't solve all of our security and privacy problems. Today's
installment can be found at
http://www.privacyfoundation.org/advisories/advemailwiretap.html
For almost all of us, the end systems are the weak points, not the
transmission!
--Steve Bellovin, http://www.research.att.com/~smb
Update on NIST crypto standards (fwd)
Forwarded with permission. There is also going to be an announcement on modes of operation; http://csrc.nist.gov/encryption/tkmodes.html should have the information within the next month or thereabouts. --- Forwarded Message X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 08 Jan 2001 13:20:18 -0500 To: [EMAIL PROTECTED] From: Jim Foti <[EMAIL PROTECTED]> Subject: Update on NIST crypto standards Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 70f288237482be01d5331b60aec89937 Hello- Here is a brief update on NIST's crypto standards efforts: 1. On January 5, 2001, we announced a Draft FIPS for HMAC (Keyed-Hash Message Authentication Code) that is a generalization of HMAC as specified in Internet RFC 2104 and ANSI X9.71. A 90-day public comment period ends April 5, 2001. Details are available at <http://www.nist.gov/hmac>. 2. On January 2, 2001, we posted a white paper that discusses our plans for developing standards and recommendations for public key-based key management. This will be a two-part process, involving the development of 1) a scheme definition document, and 2) a key management guideline. This paper is available at <http://www.nist.gov/kms>. 3. The Draft FIPS for the AES is anticipated for release for public review in the very near future. Final approvals for the release of this document are pending. When an announcement is made, information on the draft and for providing public comments will be available at <http://www.nist.gov/aes>. Best regards and Happy New Year, Jim [This note is being sent to those people who have attended any of NIST's AES conferences, the Key Management Standard (KMS) workshop in February 2000, the Modes of Operation workshop in October 2000, or who have expressed other interest in our efforts. If you would not like to receive similar notices in the future (which should be infrequent), please let me know, and we will remove you from our email distribution list.] *** Jim Foti Computer Security Division Information Technology Laboratory National Institute of Standards and Technology (NIST) 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 USA TEL: (301) 975-5237 FAX: (301) 948-1233 [EMAIL PROTECTED] *** --- End of Forwarded Message --Steve Bellovin
Carnivore draft report released
The draft Carnivore report is at
http://www.usdoj.gov/jmd/publications/carniv_entry.htm
I haven't checked yet to see if any of the redactions are reversible...
--Steve Bellovin
software patents in Europe
(Not strictly on-topic, but nevertheless of likely interest to many
readers of this list.)
According to the (online) Wall Street Journal, the board of
administration of the European Patents Office has voted to permit
software patents, by a 10-9 vote. Opposition to the change came from
the Germans, the French, and the British; smaller countries, such as
Switzerland, Liechtenstein, and Cyprus, supported it. A German
official is quoted as saying "We would have problems with the U.S.
tendency to patent everything that can be patented. That would stifle
innovation and cause a glut of litigation."
A final decision will be made in November.
--Steve Bellovin
Free speech and the DeCSS case
According to today's Wall Street Journal, the judge in the DeCSS case
against 2600 publisher Eric Corley (better known as Emmanuel Goldstein)
has asked both sides to submit briefs on whether or not software is
speech, and hence protected by the First Amendment.
--Steve Bellovin
Forwarded: Cable modems [and 3 other issues]
llect when applied to electronic communications. 4. On CALEA for the Net, note the following from the Q&A, which is meaningful, of course, only until January 20: > Q I am going to ask -- (inaudible). Your first proposal to expand wiretap >authority to Internet service providers, do you foresee any change in CALEA to >expand CALEA's function and the money associated with that legislation to >cover >ISPs? > > MR. PODESTA: I don't think we are looking at -- I am looking up at my >colleagues here -- I don't think we are thinking about any amendments to CALEA >or to the change of money or to apply that to the ISPs. That was a >decision that was made when CALEA was passed, in 1994, I guess. > Q John, I'm still a little confused about the -- extending these >wiretap-friendly capabilities to ISPs and cable modem providers. >Originally, if >we did that with the traditional phone companies, it resulted in CALEA, >government subsidizing some of the costs. Is it going to be a case where ISPs >and modem providers -- cable modem providers who provide that service will >have >to foot the bill for any technical changes to their software, hardware, or -- >(off mike)? > > MR. PODESTA: I don't anticipate that. And you know, we specifically >-- that specifically was rejected and left out of the bill when it was >passed. We're >having enough trouble trying to manage what we're trying to do under CALEA. I >don't see extending it at this point. --- End of Forwarded Message --Steve Bellovin
More one-time pads cracked?
A recent message (http://cryptome.org/krw-comint.htm) says that NSA
cracked a Chinese one-time pad during the Korean War. Does anyone have
any technical details?
The same posting also implies that the German foreign ministry used a
one-time pad known as GEE; this was also cracked. I've not heard of
GEE, and as far as I knew the ministry used online machines. Does
anyone have any details on either this system or its solution?
--Steve Bellovin
legal status of digital signatures
According to the AP, U.S. House and Senate negotiators have reached a compromise on legislation that will set national standards for digital signatures and the like. Details are in http://www.nandotimes.com/no_frames/technology/story/0,4500,500213819-500301920-501670828-0,00.html --Steve Bellovin
key agility and IPsec
(Note to ipsec@ readers -- this is a follow-up to a discussion on the cryptography list a week or so ago. To spare folks who subscribe to both, I've directed followups to the cryptography list ONLY. Subscription to it is via [EMAIL PROTECTED]) Following my exchange of notes with Ron Rivest on key agility for IPsec, I decided to gather some real data. I used a monitoring station on the plaintext side of one of our IPsec gateways to gather 7,000,000 packets in three sessions, two afternoon and one evening. Note carefully that this experiment is preliminary and small-scale. That particular gateway is a Linux box running FreeSWAN; it serves about 180 homes running Linux IPsec appliances (for details on the setup, see http://www.quintillion.com/moat/lisa-moat.ps or .pdf). Most of our endpoints have high-quality (i.e., short path) connections to the gateway. Packet headers were captured via tcpdump; lacking access to the ciphertext (and hence the SPI), I intuited the SA from the remote IP address and knowledge of our address assignment plan. Thus, since most people are assigned /29s, I assumed that I could mask off the low-order three bits of IP addresses in that range and get the security association. I split the received traffic depending on whether the gateway was encrypting or decrypting the packet. Users of this gateway typically have either a non-Windows machine or more than one machine on a home LAN. (People with a single Windows machine generally use a software client, and are homed on a different gateway.) I picked up converstations to about 145 home networks, and about 300 different machines. I made no attempt to account for rekeying; that should be infrequent enough that it wouldn't affect key agility requirements. The network behavior was about as expected. There were more packets to the home than from it (4,189,877 vs. 2,810,123) and many more bytes (1,705,033,395 vs. 297,915,963), for an average of 406 bytes/packet downstream and 106 bytes/packet upstream. While I haven't yet analyzed packet size distributions for upstream vs. downstream, the different average sizes certainly suggest that a larger percentage of the upstream packets are made up of tinygrams. To assess the key agility requirements, I simulated an LRU cache of infiite depth. The number of cache hits at a given depth should then indicate how large a cache would be needed to avoid a new key schedule calculation. (Note: I think that this approach is reasonable -- does anyone disagree?) I could have, but didn't, discard cache entries when too much time had elapsed since the last use, thus indicating a likely rekeying operation. To achieve an 80% hit rate, a cache size of 5 entries is needed for the encrypt (to the home) side, while a 8-element cache would be needed for decryption. To achieve a 95% hit rate, 11 and 17 element caches would be needed. The cache size differences agree with intuition. The gateway decrypt side requires a bigger cache than the encrypt side to achieve the same hit rate; this is probably a function of the mechanisms I suggested a few days ago: smaller packets which allow for more interleaving, delayed ACK strategies, and some lack of "packet trains". IPsec decryption is in some sense more demanding than encryption; since MAC-checking can be done in parallel with decryption, multiple packets can be decrypted back-to-back, without needing to reuse the data path for serial encrypt/MAC generation. On the other hand, the upstream data rate was considerably less, allowing more time for key-switching. I did some preliminary analysis of packet train lengths. Downstream packets show some evidence of packet clustering, though not as much as I had expected -- 60% of the trains downstream were of length 1, compared with 70% of upstream trains. I'm not sure what further analyses I should perform on this data. I do caution people that these are small-scale measurements from one site; I would be very interested to see data from other sites with IPsec gateways, especially big gateways. As I noted, I saw less than 150 SAs; it is not clear to me what would happen with 1500 or 15,000 SAs. For actual assessment of key agility requirements, a larger study is needed. I've attached the output summary files. The first column is the LRU depth; the second is the number of hits at that depth, and the third is the cumulative packet percentage for that depth. (The first line is the number of different SAs, and while it does figure into the cumulative percentages, its effect is obviously minimal.) 0 147 0.00 0 179123942.76 1 712719 59.77 2 470323 70.99 3 298255 78.11 4 203250 82.96 5 149886 86.54 6 116415 89.32 7 92641 91.53 8 73355 93.28 9 58140 94.67 10 44887 95.74 11 33712 96.54 12 24349 97.12 13 17899 97.55 14 12586 97.85 15
nothing major at AES-3...
I spent the week at the Fast Software Encryption and AES-3 conferences in New York. The big news is that there was no big news. All five candidates still look solid, and there were at least as many papers on performance as on cryptanalytic results. Not only that, the former were more enlightening -- what can one conclude from a result (I won't call it an attack) that requires 2^229 partial encryptions, 2^69 bytes of memory, and 2^69 chosen plaintexts -- all to deal with a significantly-weakened version of a cipher? (Let me be fair -- the authors recognize that that isn't even a certificational attack. At most, they say, it may pave the way for future work that is more substantive.) There were several conclusions from the performance studies. First, RC6 and and MARS are by far the worst at key agility. This may be a serious concern for hardware implementations in some circumstances, especially for VPN gateways. (I spoke briefly at the rump session of AES-3 on why IPsec was a very demanding a situation for key agility.) A fair number of people seemed to feel that key agility is a major performance issue, as opposed to just bulk encryption. When looking at hardware implementations, Serpent did very well. This is in marked contrast to its well-deserved reputation for being slow in software. My own view, not necessarily shared, is that all of the algorithms can do at least 10 Mbps on modern CPUs in software without breaking a sweat, and that above that one is likely to be using hardware regardless. There was fairly strong opposition to the idea of picking two "standards". That said, the notion of a primary and a backup algorithm did seem to have broad support. Note that the criteria for a primary/backup pair versus an AES1/AES2 pair are different -- for the latter, I'd be more inclined to pick two choices with different performance niches, while for the former I'd pick an extremely conservative cipher for the backup. My rationale is that they all look very strong today, which means that a real crack would be likely only from major new cryptanalytic results. Such a result would be likely to affect all of the candidates; thus, one would want a backup with a high margin of safety. Besides, by the time one had to switch, Moore's Law would have dealt with many of the performance issues. Which will be the eventual winner? Rijndael still looks like a very strong contender. It's very fast in hardware and software, and (from the comments during the panel session this afternoon) was the second choice of most of the submitters, if their own algorithm were not chosen. Some people feel that Rijndael should use more rounds, out of conservatism; fortunately, its structure is amenable to that. Each of the finalists submitted a summary statement; these should be on the NIST web site (www.nist.gov/aes) shortly. These are worth reading, since they provide a capsule summary of the strengths of each algorithm, plus (in some cases) refutations of the major criticisms leveled against them.
book by Sarah Flannery
Sarah Flannery -- the Irish teenager who had invented a new public key
cryptosystem -- and her father have written a book, "In Code: A Mathematical
Journey". It doesn't seem to be available yet in the U.S.; however,
amazon.co.uk is perfectly willing to ship it. My copy is on order...
--Steve Bellovin
secret-sharing code
Are there any freely-available secret-sharing packages around? Specifically,
I need to be able to set up modestly complex policies to protect a sensitive
signature key.
While source code would be best, I'd also be interested in smart card-based
products.
--Steve Bellovin
The Zimmerman Telegram
John Keegan's book "The First World War" states that although the U.S.
government was informed of the Zimmerman Telegram by British intelligence, the
"U.S. State Department" had also intercepted it. This particular claim is not
footnoted.
Does anyone know anything more about this? I know that Zimmerman (ab)used
U.S. facilities to transmit the message, but it was encrypted in 0075 code, as
I recall.
--Steve Bellovin
Internet lobbying group
According to the Wall Street Journal, nine Internet firms (AOL, Amazon.com, Yahoo, eBay, Excite@Home, DoubleClick, Inktomi, theglobe.com, and Lycos) have formed a Washington lobbying group. The purpose is to focus on issues of concern to Internet companies. The article does list privacy regulation as a concern of the group; it does not list encryption, which strikes me as an obvious choice. It is possible that this group will be quite influential, especially if more online firms join. To the extent that our employers are or may become involved, we may want to lobby internally to make sure that the group does the right thing about encryption. (There are also privacy issues; those are largely out of charter for this group, so I'll say no more on that subject here.)
Shamir's factoring machine
Shamir's paper describing his design for a factoring machine is now available (with permission) at http://www.research.att.com/~smb/twinkle.ps -- I'll leave it there for a few weeks.
tapping the nte
To: [EMAIL PROTECTED] From: Dave Farber <[EMAIL PROTECTED]> Subject: IP: "Intercepting the Internet" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: [EMAIL PROTECTED] Precedence: list Reply-To: [EMAIL PROTECTED] >From: "Caspar Bowden" <[EMAIL PROTECTED]> >To: "Dave Farber (E-mail)" <[EMAIL PROTECTED]> > > >http://www.newsunlimited.co.uk/The_Paper/Weekly/Story/0,3605,45981,00.html >Intercepting the Internet > >A secret international organisation is pushing through law to bring in >eavesdropping points for websites and other forms of digital communication. >Duncan Campbell reports > >Thursday April 29, 1999 > >European commission documents obtained this week reveal plans to require >manufacturers and operators to build in "interception interfaces" to the >Internet and all future digital communications systems. The plans, drafted >by a US-led international organisation of police and security agencies, will >be proposed to EU Justice and Home Affairs ministers at the end of May. They >appear in Enfopol 19, a restricted document leaked to the London-based >Foundation for Information Policy Research >(http://www.fipr.org/polarch/index.html) > >. The plans require the installation of a network of tapping centres >throughout Europe, operating almost instantly across all national >boundaries, providing access to every kind of communications including the >net and satellites. A German tapping centre could intercept Internet >messages in Britain, or a British detective could listen to Dutch phone >calls. There could even be several tapping centres listening in at once. > >Enfopol 19 was agreed by an EU police working party a month ago. It was >condemned last week by the civil liberties committee of the European >Parliament. But the European Parliament will shortly dissolve to face >elections in June. Meanwhile, EU ministers are preparing to adopt a >convention on Mutual Legal Assistance, including international interception >arrangements. > >If the Enfopol 19 proposals are enacted, internet service providers (ISPs) >as well as telecommunications network operators face having to install >monitoring equipment or software in their premises in a high security zone. > >Ministers were told two months ago that an international committee of >experts regarded new European policy on tapping the internet "as an urgent >necessity". But they will not be told that the policy has been formulated at >hitherto secret meetings of an organisation founded by the FBI. Known as the >International Law Enforcement Telecommunications Seminar (Ilets), police and >security agents from up to 20 countries including Hong Kong, Canada, >Australia and New Zealand have been meeting regularly for seven years. > >The Ilets group was founded by the FBI in 1993 after repeatedly failing to >persuade the US Congress to pass a new law requiring manufacturers and >operators to build in a national tapping network, free of charge. Since >then, Ilets has succeeded in having its plans adopted as EU policy and >enacted into national legislation in a growing number of countries. > >The group first met at the FBI research and training centre in Quantico, >Virginia, in 1993. The next year, they met in Bonn and agreed a document >called the International Requirements For Interception, or IUR 1.0. Within >two years, the IUR "requirements" had, unacknowledged and word for word, >become the secret official policy of the EU. They became law in the United >States. > >In June 1997, the Australian government succeeded in getting the >International Telecommunications Union (ITU) to adopt the IUR requirements >as a "priority". It told the ITU that "some countries are in urgent need of >results in this area". Ilets and its experts met again in Dublin, Rome, >Vienna and Madrid in 1997 and 1998, and drew up new "requirements" to >intercept the Internet. Enfopol 19 is the result. > >Linx, the London Internet Exchange, is the hub of British Internet >ommunications. According to Keith Mitchell, chairman of Linx: "Anything >along the lines of the Enfopol scheme would probably have astronomical cost >implications. In the event such a scheme was ever implementable, the costs >should be met by the enforcement authorities. Since the industry cannot >afford it, I doubt the public sector could "This kind of monitoring approach >is based on a world view of telecomms operators which is both technically >and economically outdated." --- End of Forwarded Message
McCain and 64-bit crypto
Before cheering too much about McCain's apparent change of heart, it's worth doing some arithmetic. 64-bit ciphers are vulnerable to a brute force attack that costs 256 times what an attack on the same 56-bit cipher would cost. Plug in EFF's 250K and you see that a similar design would cost $64M. That's probably adequate for commercial security, but it won't protect you against a government. Add in a few generations of Moore's Law, and it becomes obvious that even business-grade security won't be available for very long. Is the bill an improvment? Sure. And the new review board is a definite improvement. But I think that there's less here than meets the eye -- or the wiretap.
Re: PGP compromised on Windows 9x?
> But what you imply, that PGP (and other programs that request passwords > and passphrases from the user) should be more picky in what it accepts, is > an excellent idea. Of course, it's impossible to force the user to choose > a good passphrase, but requiring no fewer than, say, 12 characters that > look 'random' (upper, lower, digits, and punctuation), or no fewer than 30 > characters that look 'regular' (English text) would not be a bad idea. In principle, that's not a bad idea. In practice, it's very hard to make something foolproof because fools are so damned clever and persistent. In other words, people *aggressively* pick bad passphrases.
Re: Pop Count Instruction and crytanalysis
In message <00a701be4bcc$7c9f9f80$[EMAIL PROTECTED]>, "Jitze Couperus" writes: > > Some 30 years later, I find the paper cited by Steve Bellovin > on "Probable Plaintext Cryptanalysis" to be extrememely > interesting - in particular it cites another paper > about "A Programmable Plaintext Recognizer". This is > the only open documentation I have ever come across that > discusses this kind of mechanism in any detail. Thanks for a very interesting article. The other paper you cite is by David Wagner and myself, and can be found at http://www.research.att.com/~smb/papers/recog.ps (or .pdf).
Re: Pop Count Instruction and crytanalysis
In message <003901be4af4$ea5b9a20$[EMAIL PROTECTED]>, "Jitze Couperus"
writes:
> John Mckay wrote:
>
> About the "sideways add" or pop-count instruction - indeed
> Seymour Cray's first supercomputer (the Control Data 6600)
> sported such an instruction, as did all subsequent Control
> Data machines until the advent of the 180 series in the mid
> '80s.
>
...
>
> We always wondered what such an instruction might be useful for -
> until one of the first of the 180 series (n'th generation successor
> to the 6600) was delivered to such a customer, and cries of
> anguish erupted that this machine didn't have such an instruction.
> We scrambled and had to create a very tight code sequence within the
> instruction stack that could be generated via a Fortran intrinsic
> function.
For years, I had heard the story about NSA liking that instruction.
But I never understood why, until I started working on plaintext recognizers,
and independently derived the need for it. See, for example,
http://www.research.att.com/~smb/papers/probtxt.ps.
There are other instruction types that are useful for cryptanalysts.
The CDC Star had a lovely set of vector operations under masks. And
the Harvest add-on to the IBM 7030 (Stretch), described in a book by
Buchholz ("Planning a Computer System", McGraw-Hill, 1962) was intended
for NSA as well.
Re: Intel announcements at RSA '99
In message <[EMAIL PROTECTED]>, Colin Plumb writes: > > Well, as I mentioned, I said so in fairly emphatic terms once already, > although I don't know whether such access was planned or if my comments > had any effect. I'm having another, more detailed discussion with the > responsible designers on thursday. I'll have to find out what details > are okay to repeat here, but I can obviously discuss what I plan to > bring in. What I was told at RSA was that the SHA-1 whitening was done by the driver. The driver (I think it was the driver, rather than the hardware) also does its own quality checks on the hardware RNG. > > My basic point is the same as the above: software can whiten the bit > stream just as easily as hardware, so including any such processing > in hardware is not a very valuable use of transisitors. However, > access to the unwhitened bitstream is essential for quality assurance > purposes. Serious users need that to assess the quality of the random > numbers and, indeed, whether the generator has failed entirely. > > If anyone would like to add the weight of their names to my discussion, > I'd be happy to include a list of people who agree with me. > > Just send me some e-mail with > - Any contact information beyond name @ e-mail you want oe to include > - Any amplification on my basic point that you'd like to include. > - A title, position, or similar brief statement of qualifications > > Does that seem reasonable? > -- > -Colin > > (I'm also curious what people think is a good rate. I think we surprised > them by saying that one bit per second was adequate. Anything more can > be generated by cryptographic means.) I asked about speed; I was told that that isn't public yet. I do not agree that one bit per second is adequate. Apart from any question of the strength of the cryptographic RNG, it means that it would take many minutes to have enough entropy for even a single true-random DH exchange. Their own goal was "fast enough for IPSEC", which is not that fast, though more, I would guess, than your statement.
Intel announcements at RSA '99
Intel has announced a number of interesting things at the RSA conference. The most important, to me, is the inclusion of a hardware random number generator (based on thermal noise) in the Pentium III instruction set. They also announced hardware support for IPSEC.
"publishing" inventions
I asked a friendly patent attorney. The Patent Office accepts what are called "statutory invention registrations" that serve this purpose. I don't know how to file one, or what they cost.
RSA's Australian deal
According to today's Wall Street Journal, RSA is going to market "compatible technology" developed by Eric Young and Tim Hudson, via an Australian subsidiary. This is an end-run around the export rules, and has already been approved by the U.S. Dept of Commerce. "The key to that is neither U.S. technology or U.S. personnel could be involved in making the product", according to DoC. The article does note the recent Wassenaar Agreement, which might induce Australia to regulate crypto exports, too.
Re: Wassenaar vs. CipherSaber
In message <[EMAIL PROTECTED]>, Jim Gillogly writes: > "Arnold G. Reinhold" <[EMAIL PROTECTED]> writes: > > ... descriptions on the CipherSaber web site http://ciphersaber.gurus.com . > .. > > > Any comments, suggestions, endorsements and publicity are welcome. > > I'll endorse it -- the pages give a good overview of the problem and solution > , > and it is indeed easy to implement and test: one interested novice programmer > with little crypto background was able to crank out a version (I think he > used VB) in under a day that interoperated with mine. I've plugged it here > and there, including in my "President's Column" for the American Cryptogram > Association during my tenure (which ended this year). > > It's a nice idea, since it's still legal in most countries to write and > run your own code and to exchange encrypted information, even if you're > not allowed to export the code. I'm glad the site is up, but for many purposes it solves the wrong problem. Encryption algorithms are easy to write, or even to type in or scan from printed programs. But what's interesting is easy-to-use crypto, or crypto that can interoperate. Remember that most of PGP is *not* crypto algorithms.
Re: Reuters story-Wassenaar on crypto
In message <896C7C3540C3D111AB9F00805FA78CE2013F85F3@MSX11002>, "Brown, R Ken" writes: > > More to the point - I have*only* seen that Reuters press release or comments > based on it so far. The NY Times story is at http://www.nytimes.com/library/tech/98/12/biztech/articles/04encrypt.html
