December 2003 - cypherpunks-legacy

Why encrypt intra-remailernet.
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Suppose Alice sends Bob a message e(M) through Chaum. Eve, a stong opponent, wants to trace the message. She keeps track of all outgoing mail from Alice, an MD5 hash of all incoming messages to Bob, and outgoing from Bob. Eve then sends Chaum e(M), and waits for a matching MD5 to Bob that doesn't correlate to an outgoing MD5 from Bob. (Eve knows that Bob is a remailer.) (Thanks to whoever came up with Eve. I'm embarassed that I didn't think of that trick.) Clearly, this generalizes. Gentlemen, I believe that I have just stumbled upon a strong proof of the necessity of remailer auto-encryption of all messages. Since the session key is PRG, MD5 will change (a lot;). Furthermore, remailer auto- encryption allows the mailers to number their messages to each other. A low number means a re-transmit from the remailer, which is not possible, unless some sort of ACK system is in place, and even then, would still flag. Of course, if the remailers _sign_ their messages (on the way out) as well, you could compare the timestamps of the signatures with the message itself. - --- I also believe that the spammed remailer attack reveals another important weakness: if 50% of all mail leaving Alice during one tick goes to Bob, then Eve can gain probablistic information about the messages that Alice recieved, when attempting to trace a message through the net. This "attack" suggests a rational use of garbage: 1) A remailer always sends at least as many messages as it recieves, _including junk_. This means that you don't have a system "mysteriously" recieving 200 messages, and sending eight. 2) A remailer always sends at least n messages per tick. (n may vary between remailers.) If a remailer has very low traffic, that traffic is still protected. 3) On a given tick, a remailer always sends the same number of messages to each other remailer. This eliminates the effectiveness of a spam hit on a remailer of an old message. 4) Designated users of the net receive the same number of messages from each remailer each tick. (Such users probably _send_ the same number of messages each tick, as well. Note also that if some remailer is untrusted, that will be reflected by its always being sent garbage.) This puts the users "inside" the net. No, these axioms do not blow up the amount of garbage. New messages to the net displace garbage, unless they raise the maximum for the number going to a particular remailer. This system also has the advantage of _immediately_ fully integrating any new remailers. New remailers don't have to build up their users in order to be secure. - --- By combining these two, I believe we can turn the remailer net into a black box, including designated users. A communication should be safe if either end is in the black box. I believe that "PGP only" is the only way that remailers will be able to fulfill their potential. It should also increase the base of PGP users. - --- I nominate the phrases "Execute plan X.", "I have the soveineers.", "Your fried chicken is ready.", and "The NSA is a bunch of idiots." for garbage. If they ever attempt to prosecute, the have to reveal that they broke IDEA or RSA to X digits. ___ Note that the maintainence of an MD5 log of all messages by recipient by the remailers can be used to kill primitive spam/bombs. "PGP?" "ITAR!" "Oh, RKBA!" |--------------------------------------------------+ ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> ) |44B3D866 3D551E2E --------------------------------------------------- |F89222A6 338CDE24/ | ----------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLyrUVnmgMs8UcStNAQH18wf/a4SSoew9TJeaLsGWg+rL6wqm2RStrdFI XOULDD7e1yaYLBaovSz8BeNgHgW1UUAiKWWsl4rmVQ+QI1u2Oprgzo/mGy5qa1Bv i2GK9yjRleypn06fOf9kS7lr8ACO71m+1L/HPz+NBlPCgg6hCaWSJfoJkSQ1cHYi 5SHCvn/s/zLypgxcbDNqDF3eBMgpYokhFFyoTeD8LfNEtqQB/EGOwMlsik9YaKGg 5djDfDBucRsWy1a7H9G/BPejacA7PsIBKIIjbsQbxqCIczjzPR75j69ypM1IAtow kCwq6KH4d9dyKPaB5Q564LsDiEkrift+84/rADro6L5ppi4GG4PFmQ== =NgpM -----END PGP SIGNATURE-----

2 1

PRNG conditioning
by Carl Ellison 17 Dec '03

17 Dec '03

I just posted: From: cme(a)clark.net (Carl Ellison) Newsgroups: sci.math,sci.math.num-analysis,sci.stat,sci.stat.math,comp.simulation,sci.crypt,sci.crypt.research Subject: Pseudo-random number conditioning toolkit Date: 28 Jan 1995 17:41:58 -0500 a pointer to my PRNG conditioning tools as UNIX processes, to be found under: ftp://ftp.clark.net/pub/cme These include: 1. ranG a PRNG (either MD5 or SWB [subtract-with-borrow]), seeded by stdin and writing stdout; 2. ranH an MD5 conditioner (takes w bytes from stdin, writes 15 or 16 bytes to stdout); 3. ranM algorithm M -- (cf., Knuth vol.2) -- fed by either an internal SWB generator or a [pipe|file|device] whose name is given as a parameter. ---------------------------------------- 4. ranD using DES to condition stdin to stdout isn't there, thanks to the ITAR. I've sent a copy to Mark at ripem.msu.edu. ---------------------------------------- - Carl

1 0

NNTP archives
by Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- If anybody ever actually uses the cypherpunks archives via NNTP on hks.net, please let me know immediately (we don't log). I'm probably going to be putting a reasonable expire time on the group and archive the articles at expire time: if people use it, I can set up a "cypherpunks archive group" for NNTP access. This won't affect folks who use the NNTP access to read cypherpunks normally: I'll probably set the expire time to something like a month. -- Todd - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLyrP8ioZzwIn1bdtAQF0VQF9HSyCQDkeUMiso29z3TOJY4cuj6EQdjq1 JpRBSoM35ZOfKcTQ2qSIvn6WvLk56pZD =RAyu -----END PGP SIGNATURE-----

2 1

Re: Encrypted Magazine Subscriptions Via E-Mail?
by Michael Sattler 17 Dec '03

17 Dec '03

>>>why Wired ... don't [use PGP] to make subscribing easier? >> >> Because if you saw the low-tech state of the Wired office... > >Yup, too busy to automate. After all, if they took orders by email, >they wouldn't need manual intervention. It all makes perfect >sense. Why spend effort to lower the amount of time their staff need >to spend on manual tasks? Makes more sense just to remain buried. That a bunch of their staff is the minimum-wage "gee, look at my Mac" crowd might have something to do with it. I was amazed to find out that there really are two sides to Wired: the professional computer geeks (eg. Negroponte) and the professional get-a-magazine-out geeks, and the twain never seem to meet. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | And so these men of Indostan/ disputed long and loud/ each in his own | opinion/ exceeding stiff and strong/ though each was partly right/ and | all were in the wrong! - John Godfrey Saxe |

1 0

No Subject
by norm＠netcom.com 17 Dec '03

17 Dec '03

Protocols for a Data Bank The purpose of a data bank is to store large bodies of information for long periods of time. I suggest here some protocols and contracts for a data bank and its customers. We then discuss risks, incentives and stratification of the data storage industry. These ideas implicitly rely on several types of cryptography-- public key, secure hash, symmetric ciphers and blind signatures. To explain these technologies here would substantially obscure the presentation for those who know of such things and help very little for those who don't. Here are several transactions that a data bank engages in. Acquire data: A client anonymously sends a collection of data along with funds sufficient to warrant the bank's holding the data for a few days and computing its secure hash. The bank knows the data only by its secure hash. Selling Hat Checks: The bank will sell a hat check to anyone who will pay a negotiated price. The hat check specifies the secure hash of the data, the penalty to be paid upon failure to produce the data, and the cost of redeeming the data. The hat check is signed blindly by the bank and is a bearer instrument. Any holder of a hat check can present the check along with the redemption fee and demand the data. The data bank must then either produce the data or pay the penalty to the holder of the hat check. A particular hat check is canceled whenever the bank pays the penalty like a spent Chaum DigiCash note. The bank can sell multiple hat checks for the same data. Different hat checks for the same data may specify different penalties. Sell a copy of an acquisition: Any one can request a piece of data identified only by its secure hash. The bank is free to sell a copy of the data to anyone with the secure hash. The bank sets the price. Publish index: The bank can publish its list of hashes. (This makes data hunters possible.) Cancel a hat check: A holder of a hat check may sell it back to the bank at a negotiated price thus releasing the bank from the threat of paying a penalty in the future. This also allows the bank to retrieve the physical storage where the data is stored if it is sure that it has not sold other hat checks for the data. The hat check may specify expiration dates, cancellation terms etc. The bank is explicitly permitted to disseminate the data and may well do so to lay-off risks. In this sense a data bank is like in insurance company that spreads and shares risks. A hat check may be viewed as a life insurance policy for the data. Risks Dividing trust may be done by agreeing on a notary. Upon redemption, for instance, a trusted notary might examine the hat check, accept the payment specified therein from the client, pass over the data on its way from the bank to the client while computing the secure hash, and if the secure hash matches that in the hat check, deliver the payment to the bank. The notary need not have long term financial stability as must the bank. Brokers may have an interface similar to a bank. They return baskets of hat checks. This reduces the risk to the client that one of the data banks will fail financially and be unable to pay the penalty. The broker need not be financially stable. Data Hunters can engage in knowing who has what data. Given a hash they can tell you what banks have the data. This would presumably require a new protocol with the bank. This might be the ultimate URL or URI server. Inflation can damage incentives. Hat checks might be denominated in gold or currency baskets or what ever. RSA modulus size is critical for long term contacts. 2K bits of modulus or more may be warranted. Example I can imagine the Getty Museum digitizing its Rembrandts and storing the results in a data bank. The data might be insured for $100,000,000. The bank would disseminate the data to increase security and lower its risk. The museum would probably encrypt the data and share the key and hash ala Shamir for safe keeping. The museum would not share the hat check because it wants to be the one paid upon default. Incentives A data bank, or any other player, may find that keeping data profitable beyond the point of any outstanding hat checks. It can make money by supplying copies of the data in return for a fee plus secure hash. Indeed new hat checks may be sold after the last had expired. Data banks thus have an incentive to disseminate their list of holdings in the form of hashes, as input to bounty hunters. Design Considerations It may seem strange that the data bank does is willing to sell data to who ever will pay. I suggest that because it is so easy to encipher the data and not have to trust the bank. You can distribute the key thru what ever channels you transmit the secure hash of the data. Note that bank clients are always anonymous. Data is never held for some known person. Data may be held solely for speculation. The purpose of the penalty is to motivate the bank to keep data for which there is no reason to forecast sales revenue. The Bank's State Logically the bank can perform all of these transactions by merely keeping the unordered set of acquisitions. It is practically necessary to index these by their secure hash but this can be rebuilt on demand. It must keep canceled hat checks lest it become liable to extra penalties. The bank need not keep records of hat checks that it has sold unless it wants to know when it can delete acquisitions. It may want to keep marketing information to know when acquisitions are worth keeping merely to sell copies of.

3 2

Re: Remailer Specs
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >ftp myriad.pc.cc.cmu.edu /pub/remailer >ftp cs.cmu.edu /afs/andrew.cmu.edu/usr12/mg5n/public/remailer Thanks for the sites, but after looking at them, I can say they will NOT build in THINK C. But, They might help me figure out what to do with Remailer (the Mac version I'm building). Also, I'm not writing mine in C, I'm doing it in Pascal, because 1) I have the TCP libraries for it and 2) I don't now C very well at all. -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLyrN9UiLvmPjc4XdAQHeuAP/djk9XYKP3YmfdluJN8hMkNajetRAjKVK i0AvDyMUjN0fs5MXfez6v8tBx65qeWY0WIi8O53O5UzS7JOtiKNF4uLbDfJZiYRW okgdCutn6l4nHxz7MiNNCo1TXvMvPyYffy+cdPuRwX7IzfxdfaVHqD14e/x+S3Cs cy9zpuCnho0= =cDiR -----END PGP SIGNATURE----- aka: (-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's February 8th! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-) PGP block.

1 0

Re: Encrypted Magazine Subscriptions Via E-Mail?
by Michael Sattler 17 Dec '03

17 Dec '03

>I posed this question in alt.wired. Am I missing something obvious as to >why Wired (or magazines in general) don't do this to make subscribing >easier? Because if you saw the low-tech state of the Wired office you'd understand; they're at capacity just opening envelopes and manually entering names and addresses off the checques. Visit them whenever you're in downtown San Francisco. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | And so these men of Indostan/ disputed long and loud/ each in his own | opinion/ exceeding stiff and strong/ though each was partly right/ and | all were in the wrong! - John Godfrey Saxe |

2 1

Again, where to upload code?
by Robert Rothenberg 17 Dec '03

17 Dec '03

I posted this query recently with no replies, then again it's not been "duped" back to my account either, so I'm not sure if it went through. I've written some fingerprinting code for MD4, MD5, SHA, RIPE-MD and HAVAL in assembly language for 386 machiens and would like to make it available, not sure of an ftp-site... pref. ITAR-safe or are those algorithms not covered under it?

3 4

Re: Protocols for a Data Bank
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 4:39 PM 1/28/95, jpp(a)markv.com wrote: >> Date: Sat, 28 Jan 1995 15:49:13 -0800 >> From: norm(a)netcom.com (Norman Hardy) >> [...] >> Selling Hat Checks: The bank will sell a hat check to anyone who will pay a >> negotiated price. The hat check specifies the secure hash of the data, the >> penalty to be paid upon failure to produce the data, and the cost of >> redeeming the data. The hat check is signed blindly by the bank and is a > ^^^^^^^ >> bearer instrument. Any holder of a hat check can present the check along >> with the redemption fee and demand the data. > > Why in the world would the bank want to sign blindly? The bank >would be undertaking an obligation of an unknown nature. Would you >sign a blank check? A blank contract? I wouldn't. .... You are right. I forgot that the blind signer knows nothing of what we signs. The protocol requirements seem clear but I lack a protocol. I think I have a fix but I will be more careful before I post.

1 0

Re: MS Office NT
by Chris Claborne 17 Dec '03

17 Dec '03

Re: Office for NT, kahuna(a)fc.net writes: >I installed it yesterday, and played with it for about 5 minutes. ... I >wasn't able to save more than 8.3 in powerpoint, but Word did recognize this >feature, and I saved a file as 13456789012345.doc without a porblem. ...yay? This is one of the major features in NT, why the hell would they bother shipping it if it didn't support 255 char names??? ... __o .. `\<, Chris.Claborne@SanDiegoCA.ATTGIS.COM...(_)/(_). CI$: 76340.2422 --------------------------------------------------------------------------- PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Available on any Pub Key server. PGP encrypted mail welcome.

1 0