December 2003 - cypherpunks-legacy

ASN.1 and Kerberos version 5
by jis＠mit.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Perry E. Metzger writes: >I've heard people associated with the decision to use ASN.1 in >Kerberos V say it was a mistake. Frankly, I think ASN.1 is a blight >which should be exterminated from the planet. I'll say it. I was the person who pushed for the use of ASN.1 in Kerberos version 5. I had this disease at the time that made me think that ASN.1 was a good idea. I got better, unfortunately we have been living with the results of my braino for quite some time now... poor Ted. However, the problem with ASN.1 isn't its waste of space (which actually isn't that bad for a mechanism for encoding arbitrary objects). The problem is that it is the product of a standards making process that didn't (and doesn't) value interoperability. Adherence to the ISO specifications does not guarantee interoperation. Instead regional "workshops" negotiate aspects of implementations to obtain interoperation. What does this mean for ASN.1? It means that the definition of ASN.1 is a bit abstract (as its name implies). Problems result when two organizations (say MIT and OSF!) attempt to implement from the specification in ASN.1 but use different ASN.1 compilers and things then don't work. Arguments then ensue about whose compiler (or manually written parsing code) is "correct" in terms of doing the right thing with ASN.1. This is particularly so when using DER (for Distinquished Encoding Rules) which is itself an after-thought added to ASN.1 later in the process. It is required in order to verify digital signatures (which have to be computed on the "encoded" form of an object because there is no good way to calculate a signature on an "abstract" object). If the Kerberos specification said: "pub this byte here and that one there" none of these arguments and problems would happen. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEiaf8UtR20Nv5BtAQFzNAP/Q/LuIMbxAPAp64Kn2PSPd600TYlRAUJh QbsuL/iRhGXWrxSjsFzkcr6e3sIpSFggxglFU38TJT/DG2AD8MOid3Uj4pRJVbyo z7Au0Vp1NiotmRBHq2udItzJ7LLPM0j38FHQenqPs9mkX2Cq5kVgGUBO94HabEuE S9XPCgV8E1Q= =kTyw -----END PGP SIGNATURE-----

2 1

SSLRef (SSLtelnet)
by don＠cs.byu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have been looking at a number of SSLTelnet/FTP programs (available from utopia.hacktic.nl by the way) and they would seem to all require Netscape's library. Anyone know about this? I found the following link for SSLRef but I was just wondering if it was the only way to implement SSL telnet&ftp. I would hate to see people not be able to use them simply because there's no illegal copies available. URL: http://home.netscape.com/info/sslref.html If anyone knows of any clones or foreign sources please speak up. Don -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMElX4cLa+QKZS485AQERIQL/SBZAOAdAWSzfl/W9GNfDEU7e+3pBua5s z84iGGuT5CfCGM4X5rYGKV4DuRVfFPyNQc++bn8SpPgyenbvBK+gc6400FHVskr3 Y4HAlBTqSSoyfOUHlhnEAs63nsjDGdFM =ihYg -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed * This user insured by the Smith, Wesson, & Zimmermann insurance company * PS: my failure to lament violations of ITAR should not be confused with actual involvment in criminal activity. Heh heh heh. Catchyalater

2 1

NIST attendee list
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

The dangers of public attendee lists. Some Cypherpunk might match the list against east cost lawyers and break Black Unicorn's nym. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

2 1

Re: anyone know what this "top secret" code does?
by Tim Magee 17 Dec '03

17 Dec '03

In your message dated Saturday 2, September 1995 : > Does anyone remember the scenario someone suggested awhile back that > hypothesized a scheme by the NSA or other TLAs to encourage the use > of WEAK crypto? It involved spreading a lot of F.U.D. about PGP and > other strong crypto methods, followed by the discovery/leak of a > supposedly "strong" crypto algorithm to replace it. If the YFTLA could diffuse actual source of a method *supposedly* stronger than IDEA and get away with it, could they not equally qell get away with planting their man Zimmermann and having him publish PGP with a cunning trapdoor? Let's see, to lend cred to that though they'd probably have to have him arrested on trumped-up charges and generally harassed ... Many people only THINK they know what cynicism means. Seriously: I've not been round long enough to have a good idea how likely my proposed scenario is. You can all probably tell me things about Z's provenance which blow my little theory sky-high. cheers, tim M. -- "Man is born free, and everywhere he is very reasonable." -- Rousseau (roughly) Tim Magee, e-mail: Tim(a)alia1.demon.co.uk, tel: +44-1225-316785

1 0

A bold ssl idea ?
by lyalc＠ozemail.com.au 17 Dec '03

17 Dec '03

Having watched the discussions of recent of the SSL bruting, it occured to me that a variation could also be useful. I understand that setting up RC4 keys is slower that testing for the correct key (I may have misuderstood this bit). As a company using SSL can ahve all it's SSL traffic sniffed, from multiple people accessing, a log can easily be built of message/keys. Is it considered practical to modify the brutessl code to have multiple message data, and test each against a key from allocated key space ? If so, this may mean that perhaps 3 message can be tested against a single in the time two single keys could be tested against one message. An an attack scenario, this is a hell of a lot more "efficient" than current trials have been. I realise this could also be considered a bit of target for the main purpose of demonstrating weaknesses, and improving techiquess. My thoughts, anyway - i hope they make sense. lyal

3 2

LR/SHS src (386 ASM)
by Deranged Mutant 17 Dec '03

17 Dec '03

I have uploaded a copy of lrsha14.zip to the cypherpunks ftp site. It contains source code for a 32-bit implementation of the Secure Hash Algorithm as well as a Luby-Rackoff/SHA cipher in CFB mode, and a sample Turbo Pascal interface for debugging it, etc. -Rob

1 0

Joel's RSA-t's
by WOOD＠VAX2.ROCKHURST.EDU 17 Dec '03

17 Dec '03

> > On Josh Osborne's RSA-perl T-shirt venture, > > I don't know about the rest of you, but I didn't realise from Joel's > last post to the list that he was taking orders for then. I guess > that's as close to an announcement as he's going to make. I just > checked his netstuff web page, and he's taking orders now! > > Check out: > > http://www.danger.com/ad-perl.html > > (this is referenced from Joel's netstuff page under currently > available items: > > http://www.danger.com/netstuff.html > ) > > From the Joel's web page: > > > DEADLINE TO ORDER: All orders for these shirts must be postmarked by > > June 1, 1995. > > Also my page on perl-rsa is: > > http://dcs.ex.ac.uk/~aba/perl-rsa.html > > I'll be away from my mail for the rest of this week, so maybe someone > can post this info to all the crypto groups... > > Adam > -- > > HAVE *YOU* EXPORTED A CRYPTO SYSTEM TODAY? --> http://dcs.ex.ac.uk/~aba/x.html > --rsa--------------------------------8<------------------------------------- > #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL > ($k,$n)=(a)ARGV;$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2% > Sa2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*' > ,$_)while read(STDIN,$m,($w=2*$d-1+length($n||die"$0 [-d] k n\n")&~1)/2) > -------------------------------------8<------------------------------------- > TRY: echo squeamish ossifrage | rsa -e 3 7537d365 | rsa -d 4e243e33 7537d365 > Has anyone received a shirt from Joel? Or is he ripping people off? Many thanks, ------------------------------------------- | "Computers are boring and slow." | | | | David Wood | | Information Systems Specialist? | | wood(a)vax2.rockhurst.edu | -------------------------------------------

4 3

Re: Find Info You Never Thought Possible..ONLINE!!
by Feanor 17 Dec '03

17 Dec '03

On Aug 21, 7:56, INFOREVOLUTION wrote: } Subject: Find Info You Never Thought Possible..ONLINE!! > <HTML><PRE><BODY BGCOLOR="#000000"><FONT COLOR="#00FFFF" SIZE=3> > Find The Dirt On The Internet!! > > You will not receive any more correspondence from us!!!!! > ----------------------------------------------------------------------------- > > We have done the research for you!!! With this power tool you can access > information all over the World Wide Web about your employees, friends and > rivals. We give you the access to hundreds of sites that will supply you > with information about DMV records, credit profiles, medical and criminal > records, most anything you would want to know. Wow. Pseudolibertarian spam. Anyone wanna bite, fork the money and report back to us?

1 0

SSL search attacks
by don＠cs.byu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Scott Brickner <sjb(a)austin.ibm.com> >We've identified several forms of "real-world retaliation:" > >1) "Result hoarding" - failure to report a found key >2) "Segment hoarding" - requesting more segments than one can hope to search >3) Denial of service - preventing access to the server >The "random search" method eliminates all three of these at about 37% >higher cost in search time, on the average. I submit that if we >*really* were trying to break something important, we could design a >system which eliminated the first two and adequately limited the third, >but at *much* less cost. > >The problems in the current system were to be expected of a first >attempt. In the future: Only the server assigns segments, only the >assignee may report the status of a segment, and after all segments are >NAKed we know condition 1 has occurred, at which time we start over, >but never assign the same segment to the same searcher. Limit the >number of segments which may be outstanding with one searcher at one >time as a function of work rate. Deploy redundant servers. BEAAAT STATE! Push 'em back.. WAAAAAAY BAAAACK. (relevant comments follow) From: tcmay(a)got.net (Timothy C. May) >An interesting question: Is it a valid approach for J. Random User to >"claim" some chunk of keyspace to search? > >If the "reward" of finding the gold buried in the keyspace (a key that >meets the challenge) is high and the cost of claiming the keyspace is low >(or nil), then game theory tells us that some folks will be tempted to >claim a bigger chunk of keyspace than they can possibly process. > >What can be done to reduce this effect? In regard to both messages, I think that with sequentially allocated keyspace an attacker who knows the real key would have trouble getting the right segment unless s/he grabbed a big enough piece. If the search is restarted, we know something's up. Ensuring that nobody gets to search keyspace they searched before would be one improvement. A random (instead of sequential) allocation _by the keyserver_ (out of unallocated piecemeal segments) would also take some work to implement. >On the negative side, ostracize or punish those who bite off more than they >can chew. This approach is fraught with dangers. If the search wraps around to catch the UNACK'ed pieces, this type of oversight will only slow down the actual discovery of the key. Failure to report a found key, though, is a bit different. I would not be opposed to having my program report possible hits, with the server being what discovers if I've found it or not. >On the positive side, let everyone simply attack the keyspace as they see >fit, picking random parts to attack. This should not be "worse" than a >factor of several from a "perfectly coordinated" attack. (I haven't spent >time calculating this, but my intuition is that a random attack, with >overlapping keyspace, is not a lot less efficiently attacked than >attempting to arrange for no overlaps...just based on my mental picture of >dropping line segments randomly on some interval and figuring coverage of >the line segment.) Why not have a random backup-mode, in case someone does mount a denial of service attack. Or imploy a combination of the two modes. The machines running brloop can search sequentially (out of the middle 50%?) and the machines not connected search randomly (out of the outside 50%?). Or, venturing further into the I-wonder-who's-gonna-code-this world, log the random searches for possible conversion to an exhaustive search later. It would be nice to be able to hit the emergency button and switch to random mode, but currently I don't think there's a need to actually use it. Don -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMEN/U8La+QKZS485AQHNcgL+ItlNLYcsIjjlQPQJBxgts66GXPMs3ijb QIcqiAbrg4cq7F9xWNRvZa9LTvw75UUM1+PmItGkSUuqOqvJ9VkzaUp8/Sf5zuDs 5XTlJLVhYa7qQzY4Ov4a3k0ora0SPvKh =wyzo -----END PGP SIGNATURE----- <don(a)cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://bert.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Death threats ALWAYS pgp signed * This user insured by the Smith, Wesson, & Zimmermann insurance company *

3 4

Re: Socio-Economic Cults (Re: CypherPunk Cults)
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

William H. Geiger III wrote: > Somthing is seriously wrong when a home owner is more afraid of the > consequences of defending his home than his is from the criminals > attacking it. Policeman: "Sir, I'm calling to notify you that a criminal has broken into your house." Citizen: "Damn. I hope he didn't hurt himself. I forgot to pay my insurance bill this month." Tell me about it...

1 0