December 2003 - cypherpunks-legacy

RC5-56 and 2048 Bit Keys
by cvhd＠indyweb.net 17 Dec '03

17 Dec '03

With the RC5-56 having been busted, I was wondering what the going estimated crack time was for a 2048 bit RC5 key like the one available with SecureWIN? TIA

1 0

Re: how's it going?
by nimark＠mailexcite.com 17 Dec '03

17 Dec '03

Would you be interested in... <*> Sending out a FREE Bulk Email Advertisement for your business or web page to over 250,000 PEOPLE PER DAY? <*> Receiving 35,000,000 Email Addresses which can be used in your Bulk Emailings, FREE of charge? You may shudder at the thought of Bulk Email.. but the simple truth is.. BULK EMAIL WORKS! If Bulk Email didn't work, THEN YOU WOULDN'T BE READING THIS! YOUR COMPETITION is sending out Bulk Email Advertisements to over 50,000,000 People on the Internet! Why aren't YOU? THOUSANDS of companies are sending out Bulk Email to dramatically increase their profits and so should you! Even Fortune 500 companies send out Bulk Email to MILLIONS of people! With Bulk Email, you are reaching up to 250,000 people per day for FREE! Your business will DRAMATICALLY IMPROVE! To Learn how YOU can send out Bulk Email to over 50,000,000 People on the Internet for FREE, visit our web site at: http://204.50.168.161 To be removed from our Mailing List, send an email to: newport(a)lostvegas.com with the word "REMOVE" in the subject line.

1 0

Re: Pasting in From:
by Anonymous 17 Dec '03

17 Dec '03

gburnore(a)netcom.com (Gary L. Burnore) wrote: > : Presently, cracker (and some other remailers) do not allow pasting in a > : From: header. As I have stated before, the purpose of an anonymous > : remailer is to be anonymous, so pasting in a From: seems contradictory. > : However, as has been pointed out, a lot of people like to do it to avoid > : sending through nymservers, or at least psuedo-identify themselves. > : > : So, I propose a compromise: What if I enable pasting of From:, but if a > : From: header is pasted in, a short disclaimer is added to the beginning of > : the body of the message. Would that mess anyone up? I think this would be > : sufficient to avoid most problems with "forging". > > Not a good thing. If you allow a valid address to be in the from line, the > results (regardless of the inside of the message) will be UCE baiting. > Posting a message to an mlm type group with someone elses' name in the from > line. The address cullers would not read the post to know the address was > false. > > A better comprimise would be to allow the From line to be altered but not to > form a valid email address. Like name <at> site <dot> com. > > At least make sure it doesn't allow the from line to be modified to a name in > your blocked list. Maybe when other ISPs, like Netcom where Mr. Burnore is posting from, impose similar restrictions it might make sense to implement them at the remailers as well. (Remailers might well be considered the ISP of last resort for those who consider the risks of posting controversial ideas from a traceable address to be an intolerable risk.) Remailer users should not be considered second class citizens, nor have their capabilities (such as header pasting) crippled to appease anyone who makes a demand. Right now, Netcom users can and do have the capability to put just about anything in the From: line (or other header lines) of their usenet posts. Presumably if that capability were such an open invitation to "forgery", Netcom would either have disabled it or Mr. Burnore would have cancelled his Netcom account in protest. Why single out the remailers? Andy Dustman's suggestions seem quite reasonable. When something is loaded with disclaimers that the identity of the author has not been authenticated, then it's not "forgery" -- not anymore than when celebrity impersonators on Saturday Night Live are engaging in "fraud" for pretending to be President Clinton, etc. If Gary Burnore is so concerned about "forgery", maybe he ought to start using that PGP key he keeps advertising in his .sig to actually sign his posts. Unless he does, he's still vulnerable to forgery from his fellow Netcom users who are still allowed to insert arbitrary From: lines in their Usenet posts. Actually, forging a post with Gary Burnore's name and address in the From: line can be much more convincingly (no disclaimers) done from a throwaway Netcruiser account, and with less effort than learning the proper protocol to do it through a remailer. Munging of addresses is better left to the discretion of the poster. Let those who perceive a need for this "capability" use it. At least one of the mail2news gateways implements that as an option for those desiring it. I'm in favor of leaving that choice with the poster. Mr. Burnore made a similar "forgery" complaint here several months ago and was advised to PGP sign his posts and request source-level blocking if he perceived forgery to be a problem. He has evidently not taken the trouble to implement the first suggestion and, assuming he took the second suggestion, he's posted no evidence to suggest that it's not been effective.

1 0

Re: Death Penalty Expanded
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Lucky Green wrote: >On a completely unrelated note, is there some interest in starting up >a "Cypherpunks Nuclear Physics Study Group"? I recently finished >reading "The Curve of Binding Energy". Fascinating book. How dare you inquire into the nature of physical reality! Officer, please arrest that man. ;-) Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.htm Subject: Re: Death Penalty Expanded To: cypherpunks(a)algebra.com 16A5942B6EED349ECF4594C784DFD177 [Cantsin Protocol No. 1] AF823675BFB992A1CD9CD2EEBC5CDAE4041E6F06 F45932C19F0C526DBE7297FF5D74417561086272 -203 203 61EFE7321F010D1FB0E40F084C2AAE3CAF33F43413B0B8EBAABFDB17B7AC7428C4B83E1127F6C8AD0D9ED2FF09005F97BE79F1B13BB000DAA1FC9F08CA01312396316DC659D7FC8776120EA201FC38D4A164029F82CD70781AA8C37CFE4A2031E1973660E3B4ED9B2306E3BD23FEF523AEE52B26D857C93A64106A47DD482488806CDF0C301533F4B26BACDEFF626A35C8B168288586B97DA505DC35B1FE3693750EE0E22FC321B5968687E7F267145AC8225805636A5AF13E5B1112A7453487F912C34977F4C273D2CD3D24FB0522ADCDCDB354AC3918A8C3FD9B11A3C9F403585ADA07EBDAD06668BD90445788E135219F9AA4BA4294FF7189D089E4426398 3A340484BE030BAABFCC34DC1F45E57DCFBE8F031586A9E376E5D1080FCFA0AACDE50B860762D415EE877FDF9ACE10AAB465322FC00BA46F55099B0EBCACB2BEFF07D26B74903B08ACB2D9F0339AE6FAC0C35B42D4DA8E1E94FE15669FC3511545E51A3313EAB01C0FC3902C6DBFAE0E6D706603AD43207F54BF57E05E7DA4F16A68D3FB186540F9E793BD4A69938521F95F3CFDBB8BD88A75B8CC9FCB05F3F2AD2CCCC438E9AA662D3DE38BD7B46375D771167CCB9AA6F96D5280FB3A3517CFCE10FCA44C73E11E9665A2176C4502E175ACB131470863444E03F0EB83A3501C7D4597902F88CE67E00E3357AC529325A59FA0189C1D2154BF0B8E99651A3B8E

1 0

Re: Quoting Portions of a Signed Document
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Thanks to everybody for their interesting contributions to the partial signature problem. Anonymous <anon(a)anon.efga.org> writes: >A more general approach calculates the document hash in a line >oriented way. Normally we start at the top and work down through the >document to get the hash, which is signed. Instead, we would >calculate a hash for each line of the document separately, and then >combine them using a tree. This approach looks like the best to me. It's a bit cumbersome for the person doing the quoting, but that's as it should be. Brian B. Riley writes: > I haven't been follwing this thread that closely, but skimming mch >of it and then rereading this whole post, I must concur that the >context issue renders much of the discussion moot unless you can not >only relate individual sub-blocks to the whole message it came from >in the proper order ... it seems to me we are right back where we >started, quoting referenced message(s) in entirety. > > It occurrs to me that if an issue is important enough that the >veracity and autheticity of a given passage is that critical, >including entire messages is of trivial concern. Now it could be >handled by the discussion participant quoting out of context and >'footnoting' his quote with a message ID. The message corresponding >to that ID has its entire text is signed and publicly stored and >accessible. If it needs to be checked then go check it, if not take >it on faith and read on. It's easy to see why we would want other people to sign with signatures which enable partial quoting, but it's less clear why we would sign our own messages this way. For instance, somebody might want to quote my private e-mail out of context where I say "Yes, I'm real glad I got rid of that guy. He was really a pest." But they might not want to quote the part of the message where I say "Thanks for the latest shipment of plastic explosives." In order to authenticate their claim they have to reveal the entire message. If they must quote the entire message for authentication, it will discourage tacky behavior such as relaying private messages. So, this is sort of a solution looking for an application. It seems like an interesting problem and I have a strong intuitive sense that a use for it will present itself at some point. Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.htm Subject: Re: Quoting Portions of a Signed Document To: cypherpunks(a)algebra.com 16A5942B6EED349ECF4594C784DFD177 [Cantsin Protocol No. 1] AF823675BFB992A1CD9CD2EEBC5CDAE4041E6F06 98C5FC8D9791145578E4A26E9EE86E1419E6194F -9DD 9DD AF2CABB26AC13B80E2478807996B75B45CD6F1B118C66160DF4131C51A1FCB49D0FA8DE189CDF59F179E45698693471D06BC4A906D66B775FC31B5881F67BBA318F6A96703E585CCD77C0F9D556736E22BB1CAE4ED7F81C2051C0FCA6BDECC7503206EFAEFE88198E4E48D9A0D8EA56A2F3082DE8BB7371DC98AAC103DE179E56CF3DE953EF15FC35FE1D1B8336A58DC6A8E7839281CB13F49AB2D2257ED53B9053E99D951C6B624816D8A7945F8B37CD7F90AB545CB6F0D71E76337252C9483391AEADCE4E3EB526B36DCE57C8CABFBEC6093E323699FA537CD34BCEF99B023A058BE2E113CBD4317700760F2359D80306280A7D0AAD7850A3E6036A36DEBA 81D5102677C9FB0520BA053862F6EBA5F98E772A2F28EB371AE66F576FC4AA3DF94FADBD83BEE10F638002FD89A8F8E70F1D47EC4441BC1DE02244BE97B9DEB14FDB443DCF8EE4BF6586E006F01E4F0231D588918E5177027514F234EA9DE069AF832768C340B7851E7FE21BFB43132E38FDE9DF2EA5D77B3A115181AC1BBD8BEF8E3C54F17A3D098E749301D5C42A9868F586F6918002AE9BAC805DF28453381BE80C6418F18E09CC7E6C94DA7A5A1590EDD83047E259AA1F23B1384221D1A7E83FD0C18BE2A03E19A61D723401044F333D1423D638D6792473BA14A2762E3AFC7ADDACA9ED457DF0A81A223A394BE704E7DEED3D57567D91FD152F897BCAF9

1 0

Re: Happy Thanksgiving and the Impending Murder of Usenet
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Russ Allbery <rra(a)stanford.edu> writes: > > So why doesn't he? For the same reason I often eat out even though I'm a > > pretty good cook - I know how to do it, but my time can be better spent > > doing something creative. Re-coding exploits for well-known holes, for > > which a dozen explots already exists, is not creative. > > Amen. Russ hees and haws; just a couple of days ago he was whining how we shouldn't publish exploits because users should be forced to write their own exploits. > > Russ clearly believes in "security by obscurity", so heinvents bogus > > arguments to waste everyone's time. > > Russ does? There are some forms of "security via obscurity" that actually > work or which have some benefit (hell, password systems are just security > via obscurity at their core), but no, I don't believe in it as a general > principle. That's from the same bootlixcking Cabal lackey who was whining and begging me not to release my cancelbot. [rfc 1036 rewrite] > > (The main purpose of the rewrite, by the way, is to incorporate some > > "anti-spam" language, and to remove the embarassing prohibition against > > forged cancels.) > > Actually, the main purpose looks more to be to roll in a bunch of headers > that had been in informal use, clarify a bunch of the language, resolve > differences between the mail and news formats, and so forth. Brad's > pushing hard for a variety of authentication measures, including an > authenticated Path header, and X-Auth will likely be rolled in in some > form. Bullshit. I'm on the list, I see the traffic, and all the whining about "spam" coming from the wannabe content censors. > > One Good Thing that might come out of masive attacks is the switch to > > IPv6. > > Maybe. That'll be a really hard one to get going. But it would actually make the net better in many ways. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

1 0

Re: Pasting in From:
by Anonymous 17 Dec '03

17 Dec '03

no(a)no.spam (®Old Crab®) wrote: > >Andy Dustman wrote on Sun, 30 Nov 1997 14:03:39 -0500: > > > >>So, I propose a compromise: What if I enable pasting of From:, but if a > >>From: header is pasted in, a short disclaimer is added to the beginning of > >>the body of the message. Would that mess anyone up? I think this would be > >>sufficient to avoid most problems with "forging". > > > >Can't put the disclaimer in a Comments: header? > > Why make a test ??? > Put the disclaimer *every_time*. > People who want to authenticate their nym account have the thing > signed by the nym-server... > That if you consider that it is not *obvious* to everybody > that the "From:" from a remailer might be fake... > That BTW *any* "From:", from remailer or from anywhere; > might be fake... > Only PGP or such allows to be easily sure of the sender..... That's absolutely correct. That disclaimer should be implicit with EVERY post. Attaching it to anonymous posts, while technically correct, gives the false implication that posts without such disclaimers should be presumed to be genuine. That's a dangerous assumption. Anyone who wants to post an article with a phony From: address can do it far easier with a throwaway ISP account and news posting software that can be configured with an arbitrary From: address than going to the trouble of doing it through a remailer. Could it be that the enemies of privacy and freedom, if they can't ban anonymous posting altogether (at least not right now), would like to make sure that anonymous posts are stigmatized with the cyber equivalent of a yellow star? If some control freaks are to be believed, the only people who post anonymously are either "abusers", "cowards", or otherwise have sinister motives for not promiscuously broadcasting their names and addresses worldwide with every post. My theory is that what really galls them is that the precursor to the U.S. Constitution which guarantees freedom of speech (including anonymous speech) was the ANONYMOUSLY PUBLISHED "Federalist Papers", and they want to make sure it doesn't happen again. <g> > That *everybody* knows that should be controlled > when one getting a Usenet licenceá :-)) Don't give the Usenet control freaks any ideas! <g>

1 0

Re: Digital Signatures
by Anonymous 17 Dec '03

17 Dec '03

Monty Cantsin writes: > You can't see it up here, but this is a signed message using a > protocol which is modestly titled "Cantsin Protocol No. 1". > Suggestions for improvement are most welcome. A very interesting idea! Please consider the following suggestions if you like, or feel free to ignore them. One problem with signatures which have no indication at the top is that two passes over the data are necessary: the first to scan and find the start-of-signature indicator, and another to go back and calculate the hash. Signatures such as S/MIME and PGP have enough information at the top of the signed message to allow one pass processing. > The first line is "16A5942B6EED349ECF4594C784DFD177 [Cantsin Protocol > No. 1]". The hexadecimal number was chosen randomly and is the > indicator that this is a Cantsin Protocol No. 1 signature. The number > was chosen randomly and it is somewhat unlikely that anybody else will > accidently choose it. You might want to think about what happens if the document itself contains (maliciously, or perhaps because it is talking about your signatures) the string in question (as yours does and this one does as well). This could throw off an automated signature checker. > The second line in the signature is an SHA1 hash of the public key. > The hash is computed on the concatenation of the hexadecimal ASCII > forms of p, g, and y respectively. There should be no leading zeros. > (Remember to leave off the newline!) Presumably you could use the key hash to look up the key to use for verifying the message. This has a mild denial of service attack. Someone else could create a key with different boundaries between p, g, and y but which would create the same string as this concatenation, and therefore the same hash. If you left the "p: ", "g: ", and "y: " in place it would prevent this. PGP's key fingerprints have had the same problem. > The fourth line contains an offset and a length to specify the area of > the text which is signed. The offset is relative to the signature > itself. That is, the first character of the Cantsin Protocol No. 1 > code is at position 0. As signatures are usually appended, the offset > will usually be the additive inverse of the length. It is intriguing that this can be used to sign a subset of the text. Presumably there could be multiple signature blocks each of which signed different subsets, possibly with different keys. One problem is that it is not obvious to the human reader what part of the text is signed. A nice effect with PGP and S/MIME signatures is that even readers who don't have the tools can have some slight confidence in signatures, because other readers will often report it when signatures don't verify. With a signature that only covers a portion of the text, people might assume that if there are no reports of failure, more of the text is signed than is the case. This is not a technical problem but is a social phenomenon which may not interact well with this signature format. You need to specify a canonical line ending format. Based on the count values in your document, it appears that you are counting line terminators as being one character long. Your count value of 1CB9 corresponds to decimal 7353, there are exactly 7353 characters from the first character of your message body to the beginning of your signature magic number, if line ends are one character. The specific characters for line endings need to be specified as well for the hash to be calculated consistently. Your hash appears to be calculated with LF as the line ending (although the hash program is broken, see below). Probably CR/LF would be preferable for the line endings as that is a widely used internet standard as well as being common on windows. > You also need to be able to compute SHA1 hashes. I've been using > something called "sha1file" which, I believe, originated at Adam > Back's web site. That program has a bug. The routine SHA1_update in the file sha1.c is missing a line: while ( ctx->mlen == 64 ) { convert_to_bigendian( (word32*)ctx->M, 64 ); SHA1_transform( ctx ); use = min( 64, data_len ); memcpy( ctx->M, data, use ); ctx->mlen = use; data_len -= use; *** data += use; *** MISSING *** } Correcting this will make your hashes be correct. > El Gamal is simple enough that the signature on this message can be > checked using standard Unix tools such as dc version 1.1. Let's say M > is the SHA1 hash of the message. It is checked by verifying the truth > of this equation: (y^a * a^b) mod p = g^M mod p. El Gamal is a rather lengthy signature, although the verification equation is relatively simple. DSS has a shorter signature. If you report not r,s, but rather r,w where w is the inverse of s mod q, then the verification is: r = g^(M*w) * y^(r*w) mod p mod q. It's not really much more complicated. There are some subtleties to choosing El Gamal keys, but with the 2048 bit values you have chosen you are pretty safe. You want to make sure that the generator g doesn't generate a small subgroup; to do this you need to look at the factors of p-1. Your p-1 has several small prime factors: 0x2^3, 0x3, 0x6b, 0x16f, 0x1f79b, 0x3533a1eb3. Beyond that is a 1978 bit composite which I can't factor. Chances are very high that a random g will generate a group of size which is a multiple of a large prime factor of this large composite value, so it is strong, although not quite 2048 bits strong. Also, you can't really justify using 2048 bit keys when your hash is only 160 bits. The hash becomes the weak link for keys beyond about 1024 bits, and unless you use a stronger hash your key strength is misleading. This is why DSS is only specified up to 1024 bits. -- A hasher to be named later --

2 1

Re: Pasting in From:
by Bill Stewart 17 Dec '03

17 Dec '03

>> : So, I propose a compromise: What if I enable pasting of From:, >> : but if a From: header is pasted in, a short disclaimer is a >> : added to the beginning of the body of the message. >> : Would that mess anyone up? I think this would be >> : sufficient to avoid most problems with "forging". News and email are two separate cases. For news, there's almost no reason for a poster who wants his real name and address in a message to use an anonymous remailer; maybe something like posting with your Juno email on the message rather than your work email. But you can put your real email address in the message body if you want to do that, so not having that feature in a remailer is no restriction on the legitimate user. There are lots of reasons to forge someone else's name :-) So if the remailers don't support From: pasting, it's no loss. Similarly, for Reply-To: and Sender: and Path: and Received: and maybe a few other occasionally-forged header fields. Adding a disclaimer to the beginning of the message is no problem; adding it to the headers is useless, since almost nobody reads them, especially the kind of shoot-from-the-hip flamers you want to avoid. For email, perhaps you don't want the address to be visible during the first few hops in an encrypted remailer path, but you do still want one of your addresses to be there for the recipient. Again, you can put it in the message body yourself. There's a little less risk of pasting in headers on mail to individuals, but forged mail to mailing lists and mail2news relays is still a problem, and you definitely can't expect remailers to recognize mailing lists. There are also minor problems, like forging the From: address on mail to president(a)whitehouse.gov, which are better avoided this way even if you do also add disclaimers. Thanks! Bill Bill Stewart, stewarts(a)ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639

3 2

Nuclear Physics Study Group
by Anonymous 17 Dec '03

17 Dec '03

Lucky Green <shamrock(a)cypherpunks.to>: > On a completely unrelated note, is there some interest in starting up a > "Cypherpunks Nuclear Physics Study Group"? I recently finished reading > "The Curve of Binding Energy". Fascinating book. Is this really unrelated or does it represent growing ambition by the cypherpunks shooting club ? Will you be asking for anonymous donations of SNM ? I could be interested, but not in the manner of the above 2 sentences. A Nym To Be Generated Later

2 1