December 2003 - cypherpunks-legacy

European Commission on "Illegal and harmful content on the Internet"
by wfgodot＠iquest.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- A recently released European Commission Communication on "Illegal and harmful content on the Internet" may prefigure the nature of coming European Union regulatory initiatives concerning the net. This Communication was in response to a 27 September resolution by the Telecommunication Council on "preventing the dissemination of illegal content on the Internet, in particular child pornography." The document reportedly reflects what will be ongoing work to "present practical measures in time for the next Telecommunications Council on 28 November 1996." The Communication describes its aims as: firstly to describe briefly the different types of illegal and harmful content, secondly to examine the technical context in which action can be taken to deal with illegal and harmful content, and finally to suggest a number of practical measures designed to be rapidly implemented Among the points of interest, it states with emphasis that "additional international cooperation is required to avoid 'safe havens' for documents contrary to general rules of criminal law." With respect to anonymous communications it discusses proposed "measures to close known loopholes and improve traceability and that anonymous remailers record details of identity." As is typical of these agendas, the devil will be in the evolving details of enforcement. It looks like 1997 will be a busy year for proponents of greater state control over internet content both here and abroad. If they can conjure up enough sufficiently compelling bogeymen, it could be a very successful one for them as well. The HTML version of this document can be found at: <http://www2.echo.lu/legal/en/internet/content/communic.html> Links to RTF and Word versions along with the accompanying press release and related documents can be found at: <http://www2.echo.lu/legal/internet/html> - -Michael -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 iQCVAwUBMmaw0tGJlWF+GPx9AQGMLgP+JC5Lyd0NZDukq8AWipUNcDUgb6m16iUN 3smYcPdPYvsUDSWznx7ZQsklQV0oz9u5Ru7s8VoOQfA2wqSoiai3LiUiJg5WkfOg HTAbvVQCeoUaRmkmmbFJSzfqVzGB4VkJRCE4htPmmqYhCwwmMjooTi3bAClySGTD 7YcLjv0pC5w= =4EZY -----END PGP SIGNATURE-----

1 0

Re: DES cracker.
by Adam Back 17 Dec '03

17 Dec '03

[cc'd to cypherpunks] Michael Johnson <mikej2(a)Exabyte.COM> writes: > On Thu, 17 Oct 1996, Ted DiSilvestre wrote: > >... > > As someone posted a few weeks ago, rather than find one message to crack we > > should work on ten or a hundred simultaneously if possible. This seems to > > be the easiest way (assuming we can find this many "good" messages) to > > increase cracking efficiency by orders of magnitude. > > Hmmm... I don't see that this increases cracking efficiency. The suprising > (to me) result is that it doesn't really hurt it any. The increase in > average expected time to find a particular key is offset by the fact that > more keys are tried at once. We could crack just as many keys per year, on > average, but we become less sure of which keys will be cracked first. You do save something: you only need one key schedule per key that you try. You can try the key against multiple ciphertexts. A negative effect is that you might loose cacheing opportunities as code and data are increased. For timings you're likely to get for DES, you suffer from the law of diminishing returns quickly, and the additional keys/sec from doing more keys tapers off asymptotically. The number of keys it would be most efficient to use (say where adding another key speeds things up by less than 1%, or whatever) hinges heavily on the actual balance between how fast the key schedule can be made to go as compared to a CBC block operation (or whatever mode you're attacking). Also the protocol you are attacking, and the position of the known plaintext in this block affects things greatly, the further along the plaintext, the more blocks you have to cycle through, and more data you have to move around. To illustrate the effect, here's some quick cacluations based (loosly) on the timings being quoted. With Peter Trei's projected DES block timing from pentium 90 to pentium 133, and approximate equivalence of ecb and cbc demonstrated by Eric's code (this set of figures is hand-waving: I'm not at all sure like is being compared with like, and we are now extrapolating from extrapolations), combining with Eric's keyschedule timing: keyschedule 12.2us (Eric Young's) DES cbc block = 0.47us (from Peter Trei's extrapolated pentium 133Mhz) n keys | key | DES | elapsed for | elapsed per | at a time | sched | cbc | n key tests | key test | keys/sec ----------------------------------------------------------------------- 1 12.2us 1.4us 13.6us 13.6us 73.5k keys/s 2 12.2us 2.8us 15.0us 7.5us 133.2k keys/s 4 12.2us 5.6us 17.8us 4.5us 224.2k keys/s 8 12.2us 11.3us 23.5us 2.9us 340.7k keys/s 16 12.2us 22.6us 34.8us 2.2us 460.3k keys/s 32 12.2us 45.1us 57.3us 1.8us 558.3k keys/s 64 12.2us 90.2us 102.4us 1.6us 624.8k keys/s 128 12.2us 180.5us 192.7us 1.5us 664.3k keys/s 256 12.2us 361.0us 373.2us 1.5us 686.0k keys/s So 256 keys gives ~9x improvement in keys/sec with these even less accurate guestimates, and using more keys won't increase that improvement all that much, asymptotically tailing off around 9.5x for reasonable numbers (< 64k keys). Improving the key schedule in the second table doesn't add hardly anything, because it is basically irrelevant when you get to 256 keys. (However, a faster key schedule _is_ significant for 1 key at a time). I think that Peter Trei / Phil Karn are fairly close to the limit, and if anything the resulting figure will be a fair bit short of what I have extrapolated because I suspect their peak Mb/s figure will go down when you start doing practical things with the addition of extra data shifting, etc. So it all depends on what corners can be cut in the key schedule, and how much you gain by coding the keyschedule in hand optimised assembler, and all the other factors discussed above, in summary: - keyschedule / CBC block timings ratio - how far into the message is the known plaintext (how many blocks to cycle) - cache limits (additional restriction on optimal number of keys) - extra code overhead over peak cache Mb/s (moving data, extra code) - extra code size and complexity (for multiple key code) Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

1 1

Re: EC patent
by jim bell 17 Dec '03

17 Dec '03

At 04:53 PM 10/17/96 -0400, Robert Hettinga wrote: >--- begin forwarded text >Date: Thu, 17 Oct 1996 14:03:34 +0800 >From: James Lee <jlee(a)ccl.itri.org.tw> >Reply-To: jlee(a)ccl.itri.org.tw >+----------------------------------------------------+ >Addressed to: set-discuss(a)commerce.net >+----------------------------------------------------+ > >I heard that CitiBank has filed for a patent in Japan with 140+ claims >covering many aspects of electronic commerce, security electronic >transaction, etc. Does anyone know more about it? What impact will it >bring to all SET members? >James Lee >--- end forwarded text Maybe Japanese law is different, but don't I recall reading somewhere that "methods of doing business," business practices in general, are not patentable? Not that it would surprise me if the Patent Office idiots were to change their minds, like they did concerning software, algorithms, and mathematics in general... Jim Bell jimbell(a)pacifier.com

1 0

Netscape Show - Security API
by Ray Arachelian 17 Dec '03

17 Dec '03

I was at the Netscape show and attended the Security API. Looks pretty impresive. The slides for this should be available a week from now on www.develop.netscape.com (?) for those interested. This will be available in Netscape 4.0 Everything is a plug in module, and you can even replace the crappy DES and crippled RSA mods with stronger ones and even write a PGP signature checker/signed/encryptor, etc for both server and browser. Very cool stuff. PGP was actually mentioned! Catch is this: the international version is again crippled, however it is interesting to note that they got a module loadable crypto API to pass ITAR. They did this by having the international versions check modules for signatures that say "US Export Allowed" :) Possibilities around this (not that I am advocating any, just restating what was said): export the USA version (of course breaking the ITAR), modifying the code that checks the signature and allow it to load any module, making a DIFF file between versions and exporting that (would this be legal?) They mentioned (someone asked) that the signature authentification methods that check a module are part of the same API, but hinted that they couldn't be overridden. This could of course be tested, and hopefully they can be disabled. :) But time will tell. There was also some talk of expiring signatures - not sure if it was regarding modules or mail or key certificates. If module signatures expire every six months that would make an interesting situation. In the USA, you can write any module to do anything! Would be cool to have a Netscape Mail PGP set of modules!!! This could indeed solve the problem of having software that's secure and yet also easy to use. What sucks is that someone in England couldn't write their own plug in modules to get better crypto for use in the international versions. Perfectly legal in the point of view of international laws and ITAR, but crippled! Netscape says they won't sign non-USA produced crypto modules for the international versions -- or at least that was the message they gave. The folks at Netscape said that the US Government (NSA wasn't mentioned) did not want the situation to exist that someone from outside could build stronger crypto and have it be imported to the USA... Looks like we have an Iron (Crypto) Curtain situation here. In the end the USA suffers since we are only one country, but I won't start ranting on that here since it's been discussed to death already. :) Several folks from outside the USA, one guy from England actually did express concerns at this problem. Some of the authentification methods they were showing were smart cards and such, and one of the comapnies there was giving eval models out! Litronic had a couple of models - one a serial port one (9600 only with 512 bit RSA, also 768 bit, 1024 bit models will be due out in mid '97) the other plugs right into the keyboard grabbing your keystrokes before they reach the application! If you need eval models for your company to do development call'em at 714-545-6649 or go to contact them at litronic.com, whatever. :) The serial port model is likely to be the most useful since it (should?) work on PC's (Running Linux too!), Suns, Macs, and even C64's. :) Not sure if the API for this is software or an RS232 protocol, if the latter, these will work with pretty much anything. Not sure how trustworthy they are, after all you can't disassemble the smart cards and check their properties to make sure there are no holes, but possibly a dual method would work. That is, send a message to the card, have it sign or encrypt the message with the private key, take that signature/encrypted message, and also ask the user to type in a second passphrase (or use the same hashed differently) that's handled on the local machine. If the user has both, even if the card is crippled, you are secure, and even if someone finds the card they won't be able to use it. (I won't go into rubber hose key recovery here or any other details, see Tim C. May's excellent Cyphernomicon if you need background info on that.) Over all, the message I got from this is that Netscape is doing the right thing, they are for strong crypto - but are forced to abide by the ITARs. They are for voluntary key escrow for companies, NOT mandatory key escrow. They'd like to provide strong crypto functionality to all and would if not for the ITARs. ============================================================================= + ^ + | Ray Arachelian |FL| KAOS KERAUNOS KYBERNETOS |==/|\== \|/ |sunder(a)brainlink.com|UL|__Nothing_is_true,_all_is_permitted!_|=/\|/\= <--+-->| ------------------ |CG|What part of 'Congress shall make no |=\/|\/= /|\ | "A toast to Odin, |KA| law abridging the freedom of speech'|==\|/== + v + |God of screwdrivers"|AK| do you not understand? |======= ===================http://www.brainlink.COM/~sunder/========================= If the Macintosh is a woman... Then Windows is a Transvestite! ActiveX! ActiveX! Format Hard drive? Just say yes!

3 2

Re: Anonymous Auth Certificates [was: Re: Blinded Identities]
by azur＠netcom.com 17 Dec '03

17 Dec '03

>> >> >Steve Schear <azur(a)netcom.com> writes: >> > >> >[much cut] >> >> >> >> I've been charged with developing an Internet service which needs to >>assure >> >> its clients of anonymity. However, we fear some clients may abuse the >> >> service and we wish to prevent the abusers from re-enrollment if >> >> terminated for misbehavior. (In your example, it would be the person(s) >> >> trying to discover the service host via flood). >> >> >> >> My thought was to base enrollment on some sort of 'blinding' of their >> >> certified signature (e.g., from Verisign) which produces a unique result >> >> for each signature but prevents the service from reconstructing the >> >> signature itself (and thereby reveal the client's identity). I'm calling >> >> this negative authentication. >> > >(Sorry about quoting so much, but I liked Steve Schear's succinct problem >statement.) > >I don't see how authorization certificates solve this problem. How >would you determine if someone was qualified to receive an authorization >certificate? And what would you do to make them stop using the service >if they abuse it, and to stop them from getting new authorization >certificates? > >Thanks, >Hal It seems that one crux of the problem revolves around the CA and its method of certificate issuance. A CA which uses biometric data to reduce/eliminate the chance that an applicant could get several, unrelated, certificates issued would provide a basis for negative authentication (similar to a negative credit file). A one-way function performed, by the client, on their certificate from this CA would yield a token which unambiguously binds it to a valid certificate of the CA (and therefore uniquely identifies them) w/o revealing the certificate itself. -- Steve

1 0

Re: European Commission on "Illegal and harmful content on the Internet"
by azur＠netcom.com 17 Dec '03

17 Dec '03

>-----BEGIN PGP SIGNED MESSAGE----- > >A recently released European Commission Communication on "Illegal >and harmful content on the Internet" may prefigure the nature of >coming European Union regulatory initiatives concerning the net. >This Communication was in response to a 27 September resolution >by the Telecommunication Council on "preventing the dissemination >of illegal content on the Internet, in particular child >pornography." The document reportedly reflects what will be >ongoing work to "present practical measures in time for the next >Telecommunications Council on 28 November 1996." > >The Communication describes its aims as: > >firstly to describe briefly the different types of illegal and >harmful content, > >secondly to examine the technical context in which action can be >taken to deal with illegal and harmful content, > >and finally to suggest a number of practical measures designed to >be rapidly implemented > >Among the points of interest, it states with emphasis that >"additional international cooperation is required to avoid 'safe >havens' for documents contrary to general rules of criminal law." >With respect to anonymous communications it discusses proposed >"measures to close known loopholes and improve traceability and >that anonymous remailers record details of identity." > >As is typical of these agendas, the devil will be in the evolving >details of enforcement. It looks like 1997 will be a busy year >for proponents of greater state control over internet content >both here and abroad. If they can conjure up enough sufficiently >compelling bogeymen, it could be a very successful one for them >as well. > It looks as if a functioning AP system can't be here any too soon. I can't wait to bet that these sorts of thought-crime restriction won't be seen as reasonable.

1 0

[NOISE::SECURITY] Disabled ports in Navigator
by Rick Osborne 17 Dec '03

17 Dec '03

I was thinking about how to fix a sendmail program for our server when the (most likely unoriginal) thought cam to me: why not use your web broser as a telnet tool? You could embed CRLFs into the request field and the receiving program would just throw the GET /[etc] out like I messed up or something. I could then add subsequent logins & commands to my heart's content (or the string length of that particular browser's request field). Being behind a firewall, I tend to think of these things. The only problem would be with the fact that no EOL is ever sent, but with a good browser that displays as content is streamed, you wouldn't have to worry about that. Like I said, I doubt it's original because when I tried to do it in Navigator I get a Sorry, Access to the port number given has been disabled for security reasons. error dialog. I got this for all of the obvious ports (21,25,110, etc). I only have 3.0 on my machine, so I don't know if it works with previous versions. MSIE3 doesn't disable the ports, but it doesn't start displaying anything (it suffers from the stupidity of not displaying as it streams). Has anyone else personally tried this? My original idea was to see my home email, with something like: http://mail.here.com:110/user%20me%0D%0Apass [... etc] Any comments, suggestions, etc? Rick Osborne / C++ VB Pascal HTML VRML Java / osborne(a)gateway.grumman.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The NSA is now funding research not only in cryptography, but in all areas of advanced mathematics. If you'd like a circular describing these new research opportunities, just pick up your phone, call your mother, and ask for one.

2 1

[NOISE] I never knew that Dimitri Vulis was a net.legend
by Mark O. Aldrich 17 Dec '03

17 Dec '03

While the message blew by a little while ago (and I didn't save it), someone had posted a URL with information about Dimitri's sordid/alleged past on the Net. At roughly the same time, I ran across (by accident) a URL that lists Dimitri as a "net.legend" and offers yet another perspective. Apparently, Dimitri is far more well known that any of us (at least me) gave him credit for. The notion that the idiom "dandruff covered" is indicative of anti-semitism is one passage that I found rather amusing. Check it out for yourself at http://www.math.uiuc.edu/~tskirvin/home/legends/legends3.html ------------------------------------------------------------------------- |some people get by | Mark Aldrich | |with a little understanding | GRCI INFOSEC Engineering | |some people get by | maldrich(a)grci.com | |with a whole lot more | MAldrich(a)dockmaster.ncsc.mil| | -- Sisters of Mercy | | |_______________________________________________________________________| |The author is PGP Empowered. Public key at: finger maldrich(a)grci.com | | The opinions expressed herein are strictly those of the author | | and my employer gets no credit for them whatsoever. | -------------------------------------------------------------------------

6 10

Re: Binding cryptography - a fraud-detectible alternative to key-esc
by Bill Stewart 17 Dec '03

17 Dec '03

I haven't seen the technical papers behind the postings you've made to the net, but the overall approach sounds very similar to "Clipper II", the Software Key Encryption work that the TIS people (Steve Walker?) and Dorothy Denning were touting a year or so ago. It wasn't in your references, and it's clearly close enough to be worth your attention. The design was interesting - it chose a set of public and symmetric key encryption that allows the recipient to validate the sessionkey-encrypted-to-key-copy-holder*. A not-highly-technical description of the TIS CKE Commercial Key Escrow system is at http://www.tis.com/docs/products/cke/present.html, particularly present9b.html. It's worth reading for the appalling graphics alone :-) I don't seem to have a copy of the technical description anywhere. <IMG href="http://www.tis.com/docs/products/cke/pres7a.gif"> A major capability that was missing from Walker's SKE work is the ability to split the copied* key into two or more parts, all of which are need to recover the session key, while making it possible to validate that the pieces do add up to the session key. (This was also missing from the Clipper chip in hardware, which pretended to do it in the master key setting process.) Can you extend the approaches you're using to allow an outside party, or at least the recipient, to validate that the two parts of the copied key contain the complete session key? [* I'm using the terms "copied key" and "Key copy holder" to refer to the copy of the key that you're giving to some third party and the third party. The term "escrow" is generally not applicable to the applications that transmit a copy of the key to some third party, and the technologies involved don't specify, communicate, or enforce conditions for access. TIS's CKE does at least cart around a 32-bit user-defined string for specifying recovery conditions, but there's not technical enforcement. ] # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk Imagine if three million people voted for somebody they _knew_, and the politicians had to count them all.

1 0

Production of ALPHACIPHER for Windows 95 and DOS Cancelled!
by ! Drive 17 Dec '03

17 Dec '03

This may have already been posted, but I found it interesting... from: http://www.aa.net/cyber-survival-hq/ Development of the ALPHACIPHER product line has been voluntarily cancelled due to the possibility of non-compliance of users of ALPHACIPHER with the new key escrow law. Every key created by a user that would encrypt messages for international correspondence would have to be registered with the US Government. Cyber-Survival-HQ cannot insure that the users of ALPHACIPHER would voluntarily comply with this new law, and so ALPHACIPHER is hereby withdrawn from the marketplace. ALPHACIPHER currently has no built-in key generation function, and the proposed release of an ALPHACIPHER key generator has been terminated. All purchasers of ALPHACIPHER are entitled to a complete refund, and this has already been done. The New ADFGVX cipher is still offered for sale, as it is a breakable cipher, at least in theory.

3 2