December 2003 - cypherpunks-legacy

No Subject
by Lurker 17 Dec '03

17 Dec '03

Could someone tell me where I can find a text file of *all* usenet newsgroups?

1 0

Suggestion for "the serious encryption customers" to end ITAR battle
by Ernest Hua 17 Dec '03

17 Dec '03

I think we can all agree that the level of confidence in software-only approaches to security is clearly lower than combination software plus hardware approaches. It is clear that what is available over the Internet is software. (It is much harder to distribute "hardware" as you can only really distribute design information. The closest analogy could be a FPGA program, a Verilog description or some other ASIC net list.) How about the following as an approach to resolving the dispute over encryption exports: 1. Allow arbitrary exports of software-only encryption. This means that PGP is exportable as is DES crypt libraries. 2. Restrict exports of hardware-only or hardware/software encryption. This means that smart cards, HP's crypto policy cards, crypto processors with tamper-resistant casing, etc ... are restricted. Why does this make sense? 1. Reality check on export control of software: Software is just too transportable to be restricted, no matter WHAT the software does. Any restriction on WHERE software may be or may go is just not feasible, and it's not going to get any easier in the foreseeable future. 2. Take John Deutch at his word: Deutch has claimed that "serious users of cryptography" would not trust software downloaded over the Internet. We clearly do not agree with him on this aspect, but if he truly believes it (and is not just making PR spin statements for the NSA), then he must believe that allowing software exports will not significantly increase the user base (and therefore, harm CIA's or NSA's intelligence capabilities), but it will shut up the software companies' complaints. 3. Give the NSA what it wants: Software tends to standardize. Encryption is only a small part of the chain of security measures. Other weaknesses are surely part of the NSA's target for intercepts (no self-respecting codebreaking agency should stick to exploiting only one class of failures; if it is, we should question the value we are getting out of the billions of dollars we blindly give to the NSA). If the NSA stops whining about what is too hard to break, then protocol weakness and other non-encryption problems could easily creep into standards, and the NSA would surely have an analytical advantage over anyone else. Since the NSA is happily bragging that it does not even need to crack the code to break in, it should be able to live with hardware-only export restriction. The fact that the NSA is no longer drawing any lines anywhere for software will leave the bad guys guessing as to what it can really decode. In addition, hardware manufacturers will probably have a tougher overturning export restrictions on hardware-enhanced solutions after that because software companies will probably not care. It is clear that the NSA only trusts hardware implementations, as it required Clipper to be manufactured in tamper-resistant cases. All constructive replies welcome. Ern

2 1

Confirmation for subscribe cryptography
by Majordomo＠c2.net 17 Dec '03

17 Dec '03

-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "cryptography(a)c2.net". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo(a)c2.net": auth 727e8b91 subscribe cryptography cypherpunks(a)toad.com If you do not want to this action taken, just ignore this message and no action will be taken. If you have any questions about the policy of the list owner, please contact "cryptography-approval(a)c2.net". Thanks! Majordomo(a)c2.net

1 0

Why Cryptography is harder than it looks?
by Brent Cunningham 17 Dec '03

17 Dec '03

Can you please either: 1) email me a copy; or 2) give me a pointer as to where I can get a copy; of Bruce Schneier's paper on "Why Cryptography is harder than it looks?" Much appreciated. - Brent Check out the Network Computing review of Entrust: www.nwc.com Brent Cunningham Nortel Secure Networks Post Office Box 190 Ramona, California 92065 Tel: 619 788-7676 Fax: 619 788-9696 Email: bc1(a)entrust.com www.nortel.com/entrust

5 4

[crypto] Avatar Protection?
by Ryan Russell/SYBASE 17 Dec '03

17 Dec '03

A graphic-designer friend of mine and I were talking about VRML avatars, and custom design work, and could he offer a service designing them etc... His worry is that since everyone in the same virtual environment as his customer would see the designer avatar, wouldn't they also be able to easily rip off his work? (or his customer's property, take your pick.) I wasn't sure...it seems to me that I read something vaguely along these lines for a cryptography protocol of some sort.. The problem is this: Is there a way for a user to "view" the client's avatar (and in this sense, the user usually has to receive a copy of the code to render the avatar and render it on the local machine) but not save a copy? Assume that a client with no save feature is not a viable option...too easy to work around. I suppose an analogy would be: Is there a way for a person to see the plaintext, but not record it? I think that question really answers itself - no. How about alternatives? If the server of the environment only renders "views" (say, certain angles, or a bitmap) of the avatar, rather than sending the description file? Any other thoughts? Ryan

5 4

No Subject
by Jose Luis Delgado 17 Dec '03

17 Dec '03

unsuscribe cypherpunks

1 0

RE: Anyone considered adding crypto into Microsoft Outlook?
by Robert Barnes 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have downloaded, and strongly recommend, Jon S. Whalen's Microsoft Exchange Client PGP Command Extension. It adds PGP functionality to Exchange Client in a very neat and clean way. Rob -----BEGIN PGP SIGNATURE----- Version: 2.63ui iQCVAwUBMqYkarl39AMaT2JtAQHmtQP/Yu8rh5OkkMC1GVEnz4hY6xFczeDM0Y3U 7toMIDZLVnDwRXuoo9+10sUMnB289mkjoi54fuAhbkjDKYejXVIFilJoSFq+s5FZ K0Rdcaj8qv6VkJwL63gXMdXsFlxHIyQ/oK9/3r7tBgFyzab3tcjVXUGRy/NE5sLD osrJm4WzfVU= =+ffh -----END PGP SIGNATURE-----

1 0

Re: Strong-crypto smart cards in Singapore and Germany
by um＠c2.net 17 Dec '03

17 Dec '03

Peter Gutmann writes: >The standardisation committee of the German banks have also produced >an electronic wallet which should have 25 million (yes, 25M) users by >January of next year. Again, this is a pure electronic wallet, with >2-key triple DES and 768-bit (to become 1024-bit) RSA encryption. >[...] This looks like a very nice system, and unlike Mondex doesn't >rely entirely on the hope that criminals can't get at the data on the >card. For 'security reasons', all transactions are logged in what is called 'shadow accounts'. Not what I would call a very nice system.

1 0

Microsoft & Key Escrow
by Blake Coverett 17 Dec '03

17 Dec '03

Following are some of the relevent snippets from http://www.microsoft.com/intdev/security/export/exporfaq-f.htm. The comments in square brackets are mine. ---cut here--- What is Microsoft's position on supporting key escrow? Key escrow encryption is not a market-driven solution and it raises serious privacy concerns for many customers. It is also new, undeveloped, untested, and uncosted, and it will take a long time to be worked out. Additionally, customers have expressed hesitation about mandatory key escrow, especially if they have to give the keys to the government or a government-selected third party. Therefore, we are not actively adding support for key escrow in our products and technologies. [About as good as we can ask for. I would, however, like that last sentence better if the word 'actively' was missing.] Shouldn't the U.S. government be able to access information that could prevent terrorist acts and crime? Strong non-key escrow encryption is already available from retail outlets, foreign companies, and off the Internet. Thus the U.S. government is already having--and will continue to have--a harder time in the future accessing plain text regardless of U.S. export restrictions. [I suppose it would be too much to expect a third sentence reading. 'This is a good thing.'] What is key recovery? How does it relate to key escrow? Market-driven data recovery refers to a product feature that allows users to maintain a spare private encryption key in a safe place. Generally, a data recovery system escrows a copy of the session key with the message or file and the user (or perhaps his employer) controls the decision whether to utilize this feature. With key escrow the U.S. government holds or has access to a user's private encryption key. It is not yet clear whether such systems are exportable. In the October 1 announcement, the U.S. government referred to "key recovery" without defining it; in all likelihood, however, they still have in mind government key escrow, and not market-driven data recovery. [Hmm... it's just possible that Microsoft's spin doctors are better than those of the US government. Perhaps they can sell the world on their definition of 'key recovery' instead of the one we know the TLAs intended.] ---cut here--- regards, -Blake

3 2

RE: Microsoft & Key Escrow
by Tom Albertson (LCA) 17 Dec '03

17 Dec '03

These issues are also addressed at somewhat greater length than in the FAQ in "Microsoft Policy on Export Controls on Encryption" at http://www.microsoft.com/intdev/security/export/expcont1.htm (updated since the recent Administration announcements). rgds tom >-----Original Message----- >From: Blake Coverett [SMTP:blake@bcdev.com] >Sent: Wednesday, December 04, 1996 6:12 PM >To: 'cypherpunks(a)toad.com' >Subject: Microsoft & Key Escrow > >Following are some of the relevent snippets from >http://www.microsoft.com/intdev/security/export/exporfaq-f.htm. >The comments in square brackets are mine. > >---cut here--- >What is Microsoft's position on supporting key escrow? > >Key escrow encryption is not a market-driven solution and it raises serious >privacy concerns for many customers. It is also new, undeveloped, untested, >and uncosted, and it will take a long time to be worked out. Additionally, >customers have expressed hesitation about mandatory key escrow, especially if >they have to give the keys to the government or a government-selected third >party. Therefore, we are not actively adding support for key escrow in our >products and technologies. > >[About as good as we can ask for. I would, however, like that last sentence > better if the word 'actively' was missing.] > >Shouldn't the U.S. government be able to access information that could >prevent terrorist acts and crime? > >Strong non-key escrow encryption is already available from retail outlets, >foreign companies, and off the Internet. Thus the U.S. government is already >having--and will continue to have--a harder time in the future accessing >plain text regardless of U.S. export restrictions. > >[I suppose it would be too much to expect a third sentence > reading. 'This is a good thing.'] > >What is key recovery? How does it relate to key escrow? > >Market-driven data recovery refers to a product feature that allows users to >maintain a spare private encryption key in a safe place. Generally, a data >recovery system escrows a copy of the session key with the message or file >and the user (or perhaps his employer) controls the decision whether to >utilize this feature. With key escrow the U.S. government holds or has access >to a user's private encryption key. > >It is not yet clear whether such systems are exportable. In the October 1 >announcement, the U.S. government referred to "key recovery" without defining >it; in all likelihood, however, they still have in mind government key >escrow, and not market-driven data recovery. > >[Hmm... it's just possible that Microsoft's spin doctors are > better than those of the US government. Perhaps they can > sell the world on their definition of 'key recovery' instead of > the one we know the TLAs intended.] >---cut here--- > >regards, >-Blake >

1 0