December 2003 - cypherpunks-legacy

DEATH TO THE
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

re: Hal's suggestion I don't think that banning multiple recipients solves the whole problem which is the spamming of the remailer network by cybervandals like Detweiler. What needs to be done is to create some system that "charges" remailer requests to the sender which then limits the size or frequency of their messages based on their ability to pay. For a play money system, the issue is, how do you distribute the play money accounts without letting spammers open up as many accounts as they like? (e.g. if Detweiler spends his one account dry with his cyberterrorism, how do we prevent him from opening up an unlimited number of accounts without trying to attach accounts to a user's e-mail address?) By making remailers charge users, and even other remailers on the network, we can also prevent rogue remailers from allowing Detweiler attacks through the network (since they'd have to pay for his traffic) Here's a nutty idea I had one night which would accomplish these goals and also encourage more people to run remailers: o each remailer upon being setup distributes a large but finite amount of digicash certificates. These certificates are one use only. The initial distribution and price system can be altered to tailor the usage of the remailer to the owner's wishes. o after the initial distribution, the remailer distributes a somewhat smaller amount of digicash each renewal period (probably once a week) This smaller amount is sufficient for casual use, but not abuse o if you want more than what a remailer is willing to give you, you must trade service for it. That is, you must set up your own remailer and issue some cash to the other remailer which can be redeemed for chaining service. Example: Bob was unsatisified with his $10 of Ann's remailer coupons, so he set up his own remailer and issued $100 worth of service to Ann, in return, she gave him $50 of service for her remailer. (obviously, her remailer is more popular and is more in demand so his is only worth 1/2 of hers. Ann could use bob's coupons to either chain requests through him, or she could sell them off to other remailer operators.) The hard part is making sure that Bob doesn't cheat, offer to run a remailer, issue $X worth of credit to Ann, and then just file her remail requests to /dev/null I'm hopeful that a "consumer reports" like organization will pop up which periodically tests remailers to make sure they aren't cheating. (besides, the remailer network itself should do such testing with fake traffic) Call it "the free market of remailers" Other issues: How to distribute coupons/stamps/dollars? First come first serve? Popularity/Reputation? Reputation market? We want to prevent people from collecting digicash certificates multiple times during distributions, but at the same time, we don't want to use their real e-mail address. So in a system where users can create as many identities as they wish, how can we achieve a fair distribution? The only thing I can think of is to distribute cash to users based on their reputation or trust level. If a Detweiler is found abusing remailers, operators simply stop giving him cash for their remailers. Remailers which sanction Detweilers end up paying for them in the long run. (either because he runs up the costs for the remailer to use other remailers on the network, or because the operator gets too many complaints from systems which it directly delivered Detweiler mail to) Anyway, limiting multiple recipients will stop geometric growth, but it won't prevent Detweiler from hacking up a script to send a hundred thousand remail requests posting to every newsgroup and mailing list out there. Remailers would also have to limit the amount of remailer requests allowed per day, but this would still allow Detweiler to spam up the system by preventing anyone else from using it (by running out the global quota) Some sort of authentication is needly, IMHO. -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

1 0

Code Obfuscation
by garet.jax＠nitelog.com 17 Dec '03

17 Dec '03

>ÿTimothy C. May adds: >Hal Finney writes: >> The other issue, which I know less about, is the possibility of cryptograph- >> ically strong obfuscated code. Mike Duvos first mentioned this. You could >> have an algorithm running on your own computer and have it be impossible to >> determine what it is doing, or (presumably) to effectively alter the >internals >> of the algorithm. >.....stuff detiled.. >> discussing here (self-decrypting code and such tricks), but rather some >> mathematically strong transformation has been done on the structure of the >> code to hide it in a cryptographically strong way. >> >Brad Cox, of Objective-C notoriety, and now at George Mason >University, has also been interested in this area of "complexifying" >code so that reverse engineering is difficult or impossible. Okay if you want to obfuscate your code on a much more secure level albeit with some execution penalty, build public key encryption into the CPU. One would simply compile the program and encrypt it using the public key of the chipset (680xx, 80x86, &c), then the CPU would decrypt and execute the code on the fly using its private key.

1 0

Hi... :)
by lile＠netcom.com 17 Dec '03

17 Dec '03

I would like to join this alias/list. Please direct mee to the list server or wjhoever I need to talk to about getting added. thanks, -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile(a)netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Web of Trust?
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 9:17 3/30/94 -0800, Hal wrote: ... >In other words, if I want to communicate with joe(a)abc.com, I can only do so >if one of the signators of his key is a person I know. If not, I have no way >of judging the validity of his key. > >This belies simple interpretations of the "web of trust". I may have signed >A's key, A has signed B's, B has signed C's, C has signed D's, and D has signed >Joe's, but this is of no value unless I know D. Only then can I trust Joe's >key. Ideally, perhaps in cyberspace, one's public key is spread along with X's reputation, i.e. thru the same channels. When a reputation for X reaches you so does X's public key. You say that you want Henry Kissinger's public key. I respond that by whatever means you know that there exists such a person, you will (in cyberspace) already know his public key. The logical limit of this idea is that the public key becomes the name and the key authentication issue dissolves into the mist. We trust reputations because they reach us thru diverse paths. Public keys arriving thru diverse paths should likewise carry extra weight. As crypto becomes more common reputations will eventually belong more to public keys than to names. The question will then be not "What is Henry's public key?" but "What is the name of the person who knows the secret key that corresponds to this public key?". I suppose that Detwiler feared being unable to answer that question in specific cases. I don't. In the meantime, redundant webs that parallel the normal information webs thru which reputations propagate should provide public keys at least as reliable as the reputations themselves. One particular case is of interest. If you contract with me to process some of your secrets, I will agree not to divulge those secrets except under the protection of a one of a set of public keys that you give me. In such a case the web of trust model can be usefully employed and is not intrinsically limited in the number of levels.

1 0

PGP remailers
by Mikolaj Habryn 17 Dec '03

17 Dec '03

Are there any remailers which provide you with an anonymous account to which other people may send messages, which are then forwarded to you in a PGP-encrypted form? MJH * * Mikolaj J. Habryn dichro(a)tartarus.uwa.edu.au * "Life begins at '040." PGP Public key available by finger * "Spaghetti code means job security!"

2 1

VISA's digital cash
by Pat Farrell 17 Dec '03

17 Dec '03

Today's (April 3) Washington Post business section has an article on a consortium of VISA and banks working on a digital cash card. Did I sleep thru the messages, or has the list been scooped? Basic story is that the card is a smartcard, designed to be reused, and suitable for small quantities. Nothing in the article about what would prevent it from storing large amounts. No serious technical discussion either, but I infer that it is an online cash card. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

REMAIL: standardized remailer syntax
by Ian Smith 17 Dec '03

17 Dec '03

In reply to messsage <9404031518.AA06509(a)ah.com> of Sun, 3 Apr 94 08:18:37 -0700 regarding REMAIL: standardized remailer syntax Ok, I've been following this discussion with keen interest as someone who writes mail software and has written a "fairly clean" GUI interface to anonymous remailers, both encrypted and non-encrypted (although the differences to the user are not visible). All this talk of a standard syntax is great, but let me inject some notes from someone in the trenches doing this stuff: 1) Mail software authors would MUCH rather have the commands be in the header lines. If you are writing your own software, modifying header lines is easy. I understand that some people can't modify their headers due to their mail software, but ultimately this will be a chicken and egg problem if the simple header lines are proposed. If you make it easy for the mail software implementor, more software will be available with the capability (or at least patches to existing software). As for deleting subject lines, I think this reasonable to keep people doing potentially dumb things, but someway must be provided to allow people (and mailers) who understand what is going on to retain or insert new subject (header) lines. For example, my software presents a default subject line of "NONE" on anoymous mail (which I think is an ok substitute for ripping off the subject line), but if the user goes to the trouble of actually typing in a subject line it should be preserved in the resulting message. 2) MIME is a must. I just two days ago had my first user complaint that his MIME mail was "damaged" by the remailer. My user interface doesn't show people the details of MIME and he "just expected it to work". I've been considering hacks to use the :: to get the "Mime-Version" header back into the mail, but I have no idea what other shenanigans are going on with the remailer, and MIME parsers tend to be picky. An especially important area is the use of line feeds and carriage returns. I don't know how careful current remailers are to preserve the original message text at the line level, but that's going to be a big deal. Aside: I've been trying to figure out how to get a MIME message part to be a PGP signature in some reasonable way. It *should* work if the PGP sig is removed completely and the rest of the message stays intact. You should be able to concatenate them at the end and then use PGP to check it. Has anyone actually gotten this to work yet? PGP encrypted messages are a lot easier as they are self contained and fit nicely into the MIME paradigm. Also, does anyone out there know what the IANA registered types are for PGP? I heard that they were already registered, but I don't know the types. 3) I support Sameer's efforts as well as others for a standard syntax for all the commands of a remailer, but some of sort of simple syntax(es) are needed to allow users to "get their feet wet." My mailer allows you to just send anonymous mail (via hfinney, good job hal) without understanding/using PGP (or even knowing what it is). If you want to use the PGPed version of the remailers, I require (obviously) that you have my PGP interface set up. I went to a lot of trouble to create as simple a drag-n-drop interface to PGP as I could, but some people just don't want to learn it, so I had to "deal with it." This also allows people an "upgrade path" as they get more confident and interested in the use of remailers. I would very much like to present a GUI interface to a lot of other capabilities of remailers (such as chaining, the use of encrypted reply-to blocks, etc), but these are hard to implement in "clean" ways. Part of my philosophy in this is that sending anonymous mail MUST be just as easy as sending normal mail... it should look the same and work (basically) the same from the users point of view. Any new remailer syntax should consider how the mail program can implement/use the syntax is reasonable ways w.r.t. to a user who probably doesn't care about "the how" but just wants it to work. After saying all this, let me make some suggestions to make life easier for mail program authors: 1) All commands must be available without modifying the message body. This is especially important with respect to MIME mail messages whose body parts must be particularly formatted. I support E. Hughes suggestion about what the header lines should be for anon-remail, anon-post, etc. although this is not a big issue as long as there is a standard way to acess functionality. 2) When automated programs respond to mail messages, they should be formatted in ways to make it easy (preferably trivial) for programs to detect the message and its contents. Good example of this type of thing: Sameer's double blind server. It sends various kinds of control messages back to you.... it should be easy for a mail program author to detect these and take automated actions. Another example: Matt Ghio's anonymous ID allocator. Ideally these should be MIME messages with particular parts that indicate the results. I can assist people who would like to create MIME formats for their control messages. 3) Schemes and syntaxes which require multiple steps (stages) of user control should be avoided when possible (I realize this is not always possible). If a user can hit "compose" and type a mail message and then hit "send" to mail it, a very similar sequence should be preserved when using remailers. From a user interface point of view, forcing the user into some "sequenced steps" is irritating, especially in a GUI which has a very "unsequenced" way of doing things. hope this helps the discussion, ian --------------------------------------------------------------------------- "How soon is now?" ian smith, multimedia computing group, georgia tech, iansmith(a)cc.gatech.edu

1 0

Applied Cryptography Errata - Version 1.5.7
by schneier＠chinet.com 17 Dec '03

17 Dec '03

APPLIED CRYPTOGRAPHY ERRATA Version 1.5.7 - April 2, 1994 This errata includes all errors I have found in the book, including minor spelling and grammatical errors. Please distribute this errata sheet to anyone else who owns a copy of the book. Page xvii: Third paragraph, first line: "Part IV" should be "Part III". Page 1: First paragraph, fourth line: "receiver cannot intercept" should be "intermediary cannot intercept". Page 6: Sixth and seventh lines: "against symmetric" should be "against a symmetric". Page 8: Second paragraph, first line: "q code" should be "a code". Page 10: Second paragraph, fifth line: Reference "[744]" should be "[774]". Page 11: Second paragraph: "The rotations of the rotors are a Caesar Cipher" should be "Each rotor is an arbitrary permutation of the alphabet". Page 13: Third paragraph: Delete parenthetical remark. Fifth paragraph, first line: "Shift the key" should be "shift the ciphertext". Page 15: Section 1.3, first line: "Throughout the book use" should be "Throughout the book I use". Page 25: "Attacks Against Protocols," first paragraph: "the protocol iself" should be "the protocol itself". Page 27: "One-Way Functions," fourth paragraph: "For example, x^2" should be "For example, in a finite field x^2." Page 28: Third paragraph, third and fourth sentences should be "How to put mail in a mailbox is public knowledge. How to open the mailbox is not public knowledge." Page 30: Fourth line: "symmetric cryptosystems: by distributing the key" should be "symmetric cryptosystems: distributing the key". Page 30: "Attacks Against Public Key Cryptography," second paragraph: "The database also has to be protected from access by anyone" should be "The database also has to be protected from write access by anyone". Also: "substitute a key of his choosing for Alice's" should be "substitute a key of his own choosing for Bob's". Page 30: Last line: "substitute that key for his own public key" should be "substitute his own key for that public key". Page 32: Ninth line: Delete the word "encrypted". Page 34" "Signing Documents with..." First sentence: "too inefficient to encrypt long documents" should be "too inefficient to sign long documents". Page 36: Second line: "document encrypted with" should be "document signed with". "Multiple Signatures," step (4): "Alice or Bob sends" should be "Alice sends". Page 38: Fifth paragraph: "V_X = E_X and that S_X = D_X" should be "V_X = E_X and S_X = D_X". Page 40: Third line: "computer can exist" should be "computer can be". Second paragraph: Delete "should be runs of zeros and the other half should be runs of ones; half the runs". Page 44: Ninth line: "for Alice's" should be "for Bob's". Page 50: First step (3): "With Alice's public key" should be "with "Alice's" public key." Page 51: Step 5: "with what he received from Bob" should be "with what he received from Alice". Page 55: First step (2): At the end of the step, add: "He sends both encrypted messages to Alice." Page 58: Last line: "Alice, Bob, and Carol" should be "Alice, Bob, Carol, and Dave". Page 59: First line: "Alice, Bob, and Carol" should be "Alice, Bob, Carol, and Dave". Page 69: Last line: "tried to recover her private key" should be "tries to recover Alice's private key". Page 73: "Bit Commitment Using One-Way Functions," last paragraph: Second and third sentences should be "Alice cannot cheat and find another message (R_1,R_2',b'), such that H(R_1,R_2',b') = H(R_1,R_2,b). If Alice didn't send Bob R_1, then she could change the value of both R_1 and R_2 and then the value of the bit." Page 77: "Flipping Coins into a Well," first line: "neither party learns the result" should be "Alice and Bob don't learn the result". Third line: parenthetical remark should be: "Alice in all three protocols". Page 78: Step (1): "Alice, Bob, and Carol all generate" should be "Alice, Bob, and Carol each generate". Page 80: Second paragraph, second sentence. It should read: "A general n-player poker protocol that eliminates the problem of information leakage was developed in [228]." Page 90: Last paragraph: "step (3)" should be "step (4)". Page 91: Second line: "step (3)" should be "step (4)". Page 93: "Blind Signatures," first line: "An essential in all" should be "An essential feature of all". Page 98: First paragraph after protocol, fourth line: "to determine the DES key with the other encrypted message" should be "to determine the DES key that the other encrypted message was encrypted in." Page 115: "Protocol #2," third paragraph: "together determine if f(a,b)" should be "together determine f(a,b)". Page 121: Second paragraph: Delete the colon in the third line. Page 131: Fifth paragraph: "each capable of checking 265 million keys" should be "each capable of checking 256 million keys". Page 133: Table 7.2: Third number in third column, "1.2308" should be "0.2308". Page 134: Table 7.3: "1027" should be "10^27". Page 139: Indented paragraph: "could break the system" should be "could break the system within one year". Page 141: "Reduced Keyspaces," last sentence: "don't expect your keys to stand up" should be "don't expect short keys to stand up". Page 148: Eighth line: "2^24" should be "2^32". Page 156: Second paragraph: "blocks 5 through 10" should be "blocks 5 through 12". Page 157: Figure 8.2: "IO" should be "IV". Page 159: Figure 8.3: "IO" should be "IV". Page 161: Figure 8.5: "Decrypt" should be "Encrypt". Page 162: Figure 8.6: "Encipherment" diagram: Input should be "p_i" instead of "b_i", and output should be "c_i" instead of "p_i". "Decipherment" diagram: "Decrypt" should be "Encrypt". Page 164: Figure 8.7: "IO" should be "IV". Page 165: Last equation: There should be a "(P)" at the end of that equation. Page 167: Second paragraph, last line: "2^(2n-4)" should be "2^(2n-14)". Page 168: Figure 8.8: This figure is wrong. The encryption blocks in the second row should be off-centered from the encryption blocks in the first and third row by half a block length. The pads are half a block length. Page 174: Middle of page: Equations should be: k_2 = c'_2 XOR p', and then p_2 = c_2 XOR k_2 k_3 = c'_3 XOR p_2, and then p_3 = c_3 XOR k_3 k_4 = c'_4 XOR p_3, and then p_4 = c_4 XOR k_4 Page 175: Last paragraph, second line: "acting as the output function" should be "acting as the next-state function". Page 177: Diffie's quote, second to last line: "proposal to built" should be "proposal to build". Page 178: Figure 8.20: In "Node 2", the subscripts should be "D_2" and "E_3". Page 190: Fourth paragraph, last line: "to determine M" should be "to determine P". Page 191: First paragraph: "3.5" should be "6.8" in fourth line. "0.56" should be "0.15". "EBCDIC (Extended Binary-Coded Decimal Interchange Code)" should be "BAUDOT". "0.30" should be "0.76". "0.70" should be "0.24". Page 193: Second sentence: "Unicity distance guarantees insecurity if it's too small, but does guarantee security if it's high" should be "Unicity distance guarantees insecurity if it's too small, but does not guarantee security if it's high." Page 197: Third paragraph, fifth sentence: "Thus SATISFIABILITY is the hardest problem in NP" should be "Thus, there is no problem harder than SATISFIABILITY in NP". Page 198: Fourth paragraph from bottom, second sentence: "If a and b are positive and a is less than n, you can think of a as the remainder of b when divided by n" should be "If a and b are positive and b is less than n, you can think of b as the remainder of a when divided by n". Page 199: Middle of the page: In the sentence "Calculating the power of a number modulo a number", a should not be italicized. Page 201: First line of code: Remove "assuming x and y are > 0". Page 202: Middle of the page: In the sentence "Now, how do you go about finding the inverse of a modulo n?" "a" should be italicized. Page 206: Third line from bottom: "L(a,p) = -1 if a is a nonresidue mod p" should be "L(a,p) = -1 if a is a quadratic nonresidue mod p". Page 207: "Jacobi Symbol," formula: Variable "h" should be "a". Also, J(0,n) = 0. Page 209: Fourth paragraph: "If that value does not equal q" should be "If that value does not equal 1". Page 214: Last line: "n" should be "p". Lines 29, 30, and 31: "r" should be "a", and "gcd(p,r)" should be gcd(a,p)". Page 215: Lehman test, step 5: All three "(n-1)/2" should be exponents. Page 217: There should be an open parenthesis in front of the second "ln" in both exponents. Sixth paragraph: "Guassian" should be "Gaussian". Page 222: "Validation and Certification of DES Equipment," first line: "As part of the standard, the DES NIST" should be "As part of DES, NIST". Page 223: Second to last paragraph, last line. Reference "[472]" should be "[473]". Page 225: Figure 10.2: L_i is taken from R_(i-1) before the expansion permutation, not after. And "L_(i)-1" should be "L_(i-1)". Page 226: Third sentence: "bit 1 to bit 58, bit 2 to bit 50, bit 3 to bit 42, etc." should be "bit 58 to bit 1, bit 50 to bit 2, bit 42 to bit 3, etc." Page 227: Fourth line from bottom: "output positions that correspond" should be "output positions correspond". Page 228: Fourth paragraph, last line: "0 to 16" should be 0 to 15". Page 228: Fifth paragraph should read: "For example, assume that the input to the sixth S-box (that is, bits 31 through 36 of the XOR function) are 110010. The first and last bits combine to form 10, which corresponds to row 2 of the sixth S-box. The middle four bits combine to form 1001, which corresponds to column 9 of the same S-box. The entry under row 2, column 9 of S-box 6 is 0. (Remember, we count rows and columns from 0, and not from 1.) The value 0000 is substituted for 110010. Page 230: Fifth sentence: "bit 4 moves to bit 21, while bit 23 moves to bit 4" should be "bit 21 moves to bit 4, while bit 4 moves to bit 31". Second to last line: delete "The key shift is a right shift". Page 231: Table 10.9, sixth line: "80286" should be "80386". Page 233: The second two weak keys should be: 1F1F 1F1F 0E0E 0E0E 00000000 FFFFFFFF E0E0 E0E0 F1F1 F1F1 FFFFFFFF 00000000 Page 238: Next to last line before "Additional Results": "NSA's" should be "IBM's". Page 238: "Differential Cryptanalysis," third paragraph: "(1/16)^2" should be "(14/64)^2". Page 239: Figure 10.4: "14/16" should be "14/64". Page 242: Table 10.14: In "XORs by additions" line, "2^39,2^3" should be "2^39,2^31". In "Random" line, "2^21" should be"2^18- 2^20". In "Random permutations" line, "2^44-2^48" should be"2^33-2^41". Page 245: Line 11" "8 bits is" should be "8 bits was". Page 247: Section heading, "Cryptanalysis of the Madryga" should be "Cryptanalysis of Madryga". Page 250: The two functions should be: S_0(a,b) = rotate left 2 bits ((a+b) mod 256) S_1(a,b) = rotate left 2 bits ((a+b+1) mod 256) Note the difference in parentheses. Page 250: Figure 11.4: Note that a is broken up into four 8-bit substrings, a_0, a_1, a_2, and a_3. Page 251: Figure 11.6: The definitions for S_0 and S_1 are incorrect ("Y = S_0" and "Y = S_1"). See corrections from previous page. Also, "S1" should be "S_1". Page 254: "REDOC III," second sentence: "64-bit" should be "80- bit". "Security of REDOC III," second sentence: Delete clause after comma: "even though it looks fairly weak." Page 262: Figure 11.9: There is a line missing. It should run from the symbol where Z_5 is multiplied with the intermediate result to the addition symbol directly to the right. Page 263: Table 11.1: The decryption key sub-blocks that are Z_n^(m)-1 should be Z_n^((m)-1). Also, the second and third column of decryption key sub-blocks in rounds 2 through 8 should be switched. Page 264: First line: "107.8 mm on a side" shouldbe "107.8 square mm". Page 265: Figure 11.10: There is a line missing. It should run from the symbol where Z_5 is multiplied with the intermediate result to the addition symbol directly to the right. Pages 266-7: Since the publication of this book, MMB has been broken. Do not use this algorithm. Page 267: Sixth line from bottom: Reference should be "[256]". Page 269: "Skipjack." First paragraph. Reference should be "[654]". Page 270: "Karn." Third paragraph. Last sentence: "append C_r to C to produce" should be "append C_r to C_l to produce". Page 271: Middle of the page: "(for example, MD2, MD5, Snefru" should be "(for example, MD2, MD4, Snefru". Page 272: Second to last line: "But it is be analyzed" should be "but it is being analyzed". Page 275: Second to last paragraph: "Using 1028 bits" should be "using 1024 bits". Page 277: First lines: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 281: Third paragraph: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 283: Table 12.2: "PRIVATE KEY: d e^(-1)" should be "PRIVATE KEY: d = e^(-1)". Page 286: Third paragraph: "Eve gets Alice to sign y," "y" should be italicized. Second to last line: "Eve wants to Alice to" should be "Eve wants Alice to". Page 287: Last line: Wiener's attack is misstated. If d is less than one-quarter the length of the modulus, then the attack can use e and n to find d quickly. Page 288: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 289: The correct street address is "310 N Mary Avenue" and the correct telephone number is "(408) 735-5893". Page 292: Fifth line: "sqrt(x/v)" should be "sqrt(1/v)". Page 294: Second and third lines: "Bob" should be "Victor." Page 295: First line: "t random integers fewer than n" should be "t random numbers less than n". Page 297: Last line: "when" should be "where". Page 301: Middle of the page: Delete the sentence "Since the math is all correct, they do this step." Page 302: Fourth line from bottom: "a" should be in italics. Page 303: "Authentication Protocol," step (1): Add "She sends x to Victor." Page 305: Third paragraph, parenthetical remark: "NIST claimed that having DES meant that both that both the algorithm and the standard were too confusing" should be "NIST claimed that having DES mean both the algorithm and the standard was too confusing". Page 306: Eighth line: "cryptographers' paranoia" should be "paranoia". Page 307: "Description of the Algorithm": "p = a prime number 2^L bits long" should be "p = a prime number L bits long". "g = h^((p-1)/q)" should be "g = h^((p-1)/q) mod p". Page 309: Third line: "random k values and then precompute r values" should be "random k-values and then precompute r-values". Page 314: Protocol, step (1): "when" should be "where". Page 319: There should be a blank line before "discrete logarithm:" and another before "factoring:". Fourth line from the bottom: "depends more on the" should be "depends on more than the". Page 321: Third line: "when h" should be "where h". Page 322: Second paragraph: "over 500 pairs of people" should be "253 pairs of people". Page 326: In the definition of h_i, "H_(i-1)" should be "h_(i- 1)". Page 330: Definitions of FF, GG, HH, and II are wrong. These are correct: FF: "a = b + ((a + F(b,c,d) + M_j + t_i) <<< s)" GG: "a = b + ((a + G(b,c,d) + M_j + t_i) <<< s)" HH: "a = b + ((a + H(b,c,d) + M_j + t_i) <<< s)" II: "a = b + ((a + I(b,c,d) + M_j + t_i) <<< s)" Page 336: "HAVAL," sixth line: "160, 92, 224" should be "160, 192, 224". Page 339: "LOKI Single Block": In computation of Hi, drop final "XOR M_i". Page 340: "Modified Davies-Meyer": In computation of H_i, "M_i" should be subscripted. Page 342: "Tandem Davies-Meyer": In computation of W_i, "M_i" should be subscripted. Page 345: "Stream Cipher Mac", first line:" "A truly elegant MDC" should be "A truly elegant MAC". Page 347: Formula: "aX_(n1)" should be "aX_(n-1)". Second paragraph: "(For example, m should be chosen to be a prime number.)" should be "(For example, b and m should be relatively prime.)" Page 351: Second line of text: "they hold current" should be "they hold the current". Page 353: Third line: ">> 7" should be ">> 31". Fourth line: ">> 5" should be ">> 6". Fifth line: ">> 3" should be ">> 4". Eighth line: "(ShiftRegister)" should be "(ShiftRegister))". Tenth line: "< 31" should be "<< 31". Second paragraph: "are often used from stream-cipher" should be "are often used for stream-cipher". Page 356: Source code: "ShiftRegister = (ShiftRegister ^ (mask >> 1))" should be "ShiftRegister = ((ShiftRegister ^ mask) >> 1)". Page 360: Equation should not be "l(2^1-1)^(n-1)", but "l(2^l- 1)^(n-1)". Page 362: Figure 15.10: "LFSR-B" should be "LFSR-A" and vice versa. The second "a(t+n-1)" should be "a(t+n-2)", and the second "b(t+n-1)" should be "b(t+n-2)". Page 363: Fourth paragraph: "cellular automaton, such as an CSPRNG" should be "cellular automaton as a CSPRNG". Page 365: "Blum-Micali Generator": In the equation, "x_i" should be an exponent of a, not a subscript. Page 367: Sixth paragraph: "Ingmar" should be "Ingemar". Page 370: "Using "Random Noise," first paragraph, last line: "output 2 as the event" should be "output 0 as the event". Page 371: Sixth line: "access/modify times of/dev/tty" should be "access/modify times of /dev/tty". Page 371: "Biases and Correlations," third line: "but there many types" should be "but there are many types". Page 376: Seventh line: "send a message, M" should be "send a message, P". Page 391: Second protocol, step (1): "in his implementation of DES" should be "in his implementation of DSS". Next sentence: "such that r is either q quadratic" should be "such that r is either a quadratic". Page 402: First line: "when" should be "where". Line 18: "2^t" should be "2^(-t)". Page 406: Step (5): "i<j" should be i>j". Page 417: Last paragraph: "Kerberos is a service Kerberos on the network" should be "Kerberos is a service on the network". Page 421: Figure 17.2: In the top message "C" should be lower case. Page 435: "RIPEM": "Mark Riorden" should be "Mark Riordan". Page 436: "Pretty Good Privacy," third paragraph: Delete fourth sentence: "After verifying the signature...." Page 436: Pretty Good Privacy is not in the public domain. It is copyrighted by Philip Zimmermann and available for free under the "Copyleft" General Public License from the Free Software Foundation. Page 437: Fifth line: Delete "assess your own trust level". "Clipper," second paragraph: reference should be "[473]". Fourth paragraph: references should be "[473,654,876,271,57]". Page 438: Middle of page: reference should be "[654]". "Capstone," first paragraph: reference should be "[655]". Page 445: The IACR is not the "International Association of Cryptographic Research," but the "International Association for Cryptologic Research." This is also wrong in the table of contents. Source Code: The decrement operator, "--", was inadvertently typesetted as an m-dash, "-". This error is on pages 496, 510, 511, 523, 527, 528, 540, and 541. There may be other places as well. Page 472: Third line: "2, 18, 11" should be "22, 18, 11". Eighteenth line: "for( i = 0; i<<16; i++ )" should be "for( i = 0; i<16; i++ )". Page 473: Function "cpkey(into)". "while (from endp)" should be "while (from < endp)". Page 478: Fourth line: "leftt > 4" should be "leftt >> 4". Seventh line: "leftt > 16" should be "leftt >> 16". Twentieth line: "leftt > 31" should be "leftt >> 31". Page 508: Line 8: "union U_INTseed" should be "union U_INT seed". Page 531: "for( i = 0; i<; i++ )" should be "for( i = 0; i<2; i++ )". Page 558: "#defineBOOLEAN int" should be "#define BOOLEAN int", "#defineFALSE0" should be "#define FALSE 0", and "#defineTRUE(1==1)" should be "#define TRUE (1==1)". Page 564: "#define BOOLEANint" should be "#define BOOLEAN int", "#define FALSE0" should be "#define FALSE 0", and "#defineTRUE(1==1)" should be "#define TRUE (1==1)". Page 569: "rand() > 11" should be "rand() >> 11". Page 569: In "G13.H", "#define G13int" should be "#define G13 int". Page 572: Reference [45]: "Haglen" should be "Hagelin". Page 576: References [136] and [137]: "Branstead" should be "Branstad." Page 578: Reference [184] "Proof that DES Is Not a Group" should be "DES Is Not a Group." The correct page numbers are 512-520. Page 589: Reference [475]: The publisher should be E.S. Mittler und Sohn, and the publication date should be 1863. Page 601: References [835] and [836]: "Branstead" should be "Branstad." Page 602: Reference [842]: "Solvay" should be "Solovay". Page 603: Reference [878]: "Weiner" should be "Wiener." This errata is updated periodically. For a current errata sheet, send a self-addressed stamped envelope to: Bruce Schneier, Counterpane Systems, 730 Fair Oaks Ave., Oak Park, IL 60302; or send electronic mail to: schneier(a)chinet.com.

1 0

Re: Politics do not belong here
by Julietta 17 Dec '03

17 Dec '03

Jer- I'm sorry, but I feel so strongly about your message "Politics do not belong on this list" that I was compelled to reply... Where else should the poltical implications of encryption be discussed, if not amongst those who are most involved in its creation and proliferation? The political use and misuse of power is central to the issues regarding encryption, and these ramifications should be discussed as the technology is in its infancy. Encryption technology can be used as a tool to empower the individual, or it can be used as a means to lend a false security to the individual in his communications. If in fact the Clipper Chip with its easily obtainable (by government agencies) escrow keys is allowed to be implimented, we may in fact be assisting the government to effect a survelliance state of a maginitude never before seen in society. As American homes become host to "interactive" technologies, we need to realize the increased ability this brings for surveillance by both government and capitalistic enterprises. Encryption is one viable solution to re-instate the privacy equlibrium in the face of such a condition- this is where its power lies. Encryption, then, is not merely a mathematical tool, but also a sociological one; to discuss merely the technological and not the social and moral implications of this techology would be to not realize its full potential as a mediator to the coming state of "Big Brother is watching You". Politics, then, is not periferal but central to the discussion of encryption technology. Julie __________________________________________________________________________ Julie M. Albright Ph.D Student Department of Sociology University of Southern California albright(a)netcom.com

2 2

Cyberspace, Crypto Anarchy, and Pushing Limits
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Cyberspace, Crypto Anarchy, and Pushing Limits This messages touches on two topics of recent interest (to some) here: 1. Setting up payment systems for message transmission, to handle the issues of "mailbombing" and "flooding" in a more natural way (locality of reference, user of a service pays, avoidance of the "Morris Worm" explosion effects which could've happened with Detweiler bombed us, as Hal noted). 2. The general issue of "Cyberspace." This lies at the root of some recent disagreements here, and is worthy of more discussion. Crypto will make this a very real cusp issue in the next several years. Why debate it now? What could possibly come out of such a debate? It happens that I'm reading a wonderful new book by Kip Thorne, entitled "Black Holes and Space Warps." This is widely available in bookstores, in hardback only at this time. ($30, but it's a whopping big book, and I got it at Barnes and Noble for $24. Speaking of Barnes and Noble, the Santa Clara store is selling Li and Vitanyi's "Intro. to Kolmogorov Complexity" book for $44, before the 20% hardback discount, which may be a mispricingm, as I paid $60 for mine. Check it out if you're interested....I think there were two copies.) Thorne has spent 30 years studying gravitational collapse and black holes, and was a coauthor of the famed 1973 book on "Gravitation," which I got to use in a Xeroxed form for my general relativity class in 1973. The point? Thorne describes his involvement with Carl Sagan in working out the physics of time travel via wormholes. Thorne had an epiphany: however unlikely the engineering or financing of something is, there is something valuable to be gained in examining the absolute limits of what is possible without regard for engineering practicalities. Thus, he and his students looked into the implications of an extremely advanced civilization able to somehow hold open the mouth of a wormhole. The conclusions are fascinating and led to a new line of thinking about the structure of space-time. Pushing limits and seeing "ideal" behavior is invigorating. The connection to crypto is this: Perhaps we should be thinking more about the implicaitons and effects of strong crypto, digital money, ideal remailers, etc., assuming that certain practical problems that bedevil us today are, or soon will be, solved. To some extent we already do this, as when we discuss Chaum's ideal mixes in the same way engineer's discuss ideal op amps--a useful abstraction of behavior in the limit that lesser, real world implementations can then be contrasted with. And of course many of us have found Vernor Vinge's "True Names" to be an excellent (and quickly readable) treatment of how things could work in a world of fast, cheap, and secure communication. Other writers have seen things differently (e.g., "Shockwave Rider," "1984," "Snow Crash"). Here, to cut to the chase, are some brief statements of what I see as the "behavior in the limits." I won't elaborate on them right now. * "Pay as you go" is the natural way to handle most economic transactions. There are exceptions, of course, such as insurance, contracts for future perfomance, etc., but for the most part money is used to mediate immediate exchanges. For a timely example, why can your enemies not "junk mail bomb" you with truly large (tons) of junk mail? Junk mail, as we call it, is in relatively small volumes (at most a mailbox full, except for celebrities perhaps) because of one simple thing: someone has to pay for the delivery! There is no possibility of a "free" way to "Make 19 copies of this ton of garbabe and mail them to your enemies." That there is with software--the remailer bombing by Detweiler, the 1988 Morris Worm, the "Dave Rhodes" chain letters--is due to some flaws in the current Net model: - costs of message trasnmission are not directly borne by senders (encourage overuse by some of scarce resources, a la the "tragedy of the commons'). - sites and remailers will respond to "instructions" to send the message on, to make copies of it, etc. * I thus consider it imperative that we develop as quickly as we can the following: - payment systems for message transmission (I've argued for "digital postage" as a first and comparatively easy application of digital money, others have as well, and Ray Cromwell just today issued his own proposal....time we get going on this. And lest you think I'm calling for altruism here, I think some fortunes will be made in this area.) - anonymous or identity-obscuring protocols, a la Chaum. - a general move away from "commons"-oriented systems, which breed the notions of "fair access" and such. If the "problem" is that poor people cannot--it is alleged--afford a $17 a month Net connection (what Netcom charges, in about 25 cities and growing), then my solution would be to simply _subsidize_ their bill. (I'm not advocating this, nor do I think it wise to subsidize anyone's phone, Net, or dinner bills, but better this than "nationalizing" networks and thus creating more confusion and less efficiency for all.) * Connectivity will be altered dramatically, The "distance" in cyberspace is already uncorrelated to physical distance. (Hardly surprising, as this was apparent with the telephone. But a useful way of looking at cyberspace, as being a space of radically altered connectivities and distances.) * Local access to service, the phone or cable lines that reach the home or office, is a potential bottleneck. But once a connection is made to a local node where multiple competitors exist (that is, once beyond the local government-granted monopoly), the possibility of "censorship" decreases rapidly, for several reasons. - thus, push for "encrypted access" lines from a terminal node (home, office) to a point with unlimited connectivity. - this is the situation I now have with my PacBell line and Netcom: PacBell doesn't "care" what I use the local line for, and once outside, I can dial a less-censorious Netcom rather than a Big Brotherish AOL or Prodigy. * Cyberspace is infinitely colonizable. No limits to growth. (Assumption: realization of cyberspace is on various machines and networks, which are not free, nor infinite. But the "no limits" comes from ease with which those near a "boundary" can simply push out that boundary with more CPU resource, more networks, etc.). * Crypto means access to "regions" can be controlled by "owners": - "my house, my rules" enforced locally, without central State authority - esseentially unbreakable security (in crypto sense) * By the way, strong crypto is the "building material" of cyberspace...the mortar, the bricks, the support beams, the walls. Nothing else can provide the "permanence"...without crypto, the walls are subject to collapse at the first touch by a malicious person or agency. With crypto, not even a 100 megaton H-bomb can breach the walls. (If you think I'm exaggerating, do some calculations on the energy to break a 1000-decimal-digit modulus.) * No "zoning laws" will be needed, or possible, in cyberspace. (Neil Stephenson's "Snow Crash," while a wonderful and thought-provoking read, got it wrong here: cyberspace is too extensible and locally controllable.) * Physical location of cyberspace locations will be increasingly hard to pin down. A vast "labyrinth of rooms and corridors" might be physically instantiated on a computer in Malaysia, while a "virtual gambling hall" is being run via cryptographic cutouts (remailers) from someone's bedroom in Provo, Utah. * The talk about "access rules" is thus shown to be meaningless, unless the governments crack down on networks, crypto, and private systems in a way far beyond anything now being talked about. This is the "crypto anarchy" I have been writing about since 1988. Cyberspace will turn out to be a far vaster frontier than _anything_ we have seen so far. With "only" 10^70 or so particles in the entire universe, there's vastly more "space" (address space, key space, etc.) in even a relatively small set of digits. Cyberspace is mathematical space, and its spaciousness is truly unlimited. And we'll be moving our trade, our entertainment, and much of our lives into cyberspace a whole lot faster than we'll be slowly moving into low Earth orbit and beyond. In fact, I consider that I'm already half-way in. In a few years, with Mosaic-like one-touch connectivity, with a plethora of network choices, with secure remailers and similar tools to anonymize my transactions, I'll be so far in there'll be turning back. Enough for these remarks rigth now. I think it makes sense to take a slightly longer-range view of the inevitable trends, to see where we're going, to see what issues need more work. I hope some of you agree with me. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

3 2