December 2003 - cypherpunks-legacy

Re: textbooks
by koontz＠MasPar.COM 17 Dec '03

17 Dec '03

IP/FP and PC1 describe how to get from input bytes to L, R, C and D Blocks: The Initial Permutation The Initial Permuation (IP) is a description of how a byte wide interface is connected to a 64 bit block comprised of two 32 bit blocks (L and R). Consider a byte wide interface with the bits numbered 1-8. The event numbered bits go to the L Block and the odd numbered bits go to the R block. Note that the bit order is big endian, where bit 1 is most significant and bit 8 is least least significant. The input block is typically loaded as 8 successive byte loads: Port MSB7 Input (LR) Left Bit Bit Block (64 bits) Block (32 bits) 2------6-------58 50 42 34 26 18 10 2 1 2 3 4 5 6 7 8 4------4-------60 52 44 36 28 20 12 4 9 10 11 12 13 14 15 16 6------2-------62 54 46 38 30 22 14 6 17 18 19 20 21 22 23 24 8------0-------64 56 48 40 32 24 16 8 25 26 27 28 29 30 31 32 Right Block (32 bits) 1------7-------57 49 41 33 25 17 9 1 1 2 3 4 5 6 7 8 3------5-------59 51 43 35 27 19 11 3 9 10 11 12 13 14 15 16 5------3-------61 53 45 37 29 21 13 5 17 18 19 20 21 22 23 24 7------1-------63 55 47 39 31 23 15 7 25 26 27 28 29 30 31 32 Input Byte 8 7 6 5 4 3 2 1 The Final Permutation The Final Permutation (IP-1) provides the inverse, it standarizes the output of the R16L16 output block to a byte wide interface. The Output block is ordered Right then Left to allow complementary operation for subsequent decryption. Were one to perform an IP followed by IP-1 without any intervening round iteration operations, one would end up with odd and even bits swapped: Right Output (R16L16) Standard Port Block (32 bits) Block (64 bits) Bit Bit 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8---------6--------2 9 10 11 12 13 14 15 16 9 10 11 12 13 14 15 16---------4--------4 17 18 19 20 21 22 23 24 17 18 19 20 21 22 23 24---------2--------6 25 26 27 28 29 30 31 32 25 26 27 28 29 30 31 32---------0--------8 Left Block (32 bits) 1 2 3 4 5 6 7 8 33 34 35 36 37 38 39 40---------7--------1 9 10 11 12 13 14 15 16 41 42 43 44 45 46 47 48---------5--------3 17 18 19 20 21 22 23 24 49 50 51 52 53 54 55 56---------3--------5 25 26 27 28 29 30 31 32 57 58 59 60 61 62 63 64---------1--------7 Output Byte 8 7 6 5 4 3 2 1 >From FIPS Pub 46-2: Final Permuation IP-1: Output Byte 40 8 48 16 56 24 64 32 1 39 7 47 15 55 23 63 31 2 38 6 46 14 54 22 62 30 3 37 5 45 13 53 21 61 29 4 36 4 44 12 52 20 60 28 5 35 3 43 11 51 19 59 27 6 34 2 42 10 50 18 58 26 7 33 1 41 9 49 17 57 25 8 1 2 3 4 5 6 7 8 Port Bit 7 6 5 4 3 2 1 0 MSB7 Bits In the simplest hardware implementation of DES, the Left and Right blocks are comprised in hardware of four 8 bit register each. Each 8 bit register can be serially loaded (IP), serially unloaded (IP-1), or parallel output and parallel loaded (round interation). DES is an encryption algorithm originally required to be implemented in hardware, specified in 1977 - predating 16 or 32 bit microprocessor peripherals. Permuted Choice 1 PC1 performs a similar function loading the C and D 28 bit registers (comprised of three 8 bit bidirectional shift register and 1 4 bit bidirectional shift register, all with parallel outputs). The C and D registers can be serially loaded (shifting right), or serially shifted left or right in a closed ring for encryption or decryption. Port MSB7 Bits Bits Input (CD) C Block, 64 bits Block (28 bits) 1--------7------57 49 41 33 25 17 9 1 MS 1 2 3 4 5 6 7 8 2--------6------58 50 42 34 26 18 10 2 9 10 11 12 13 14 15 16 3--------5------59 51 43 35 27 19 11 3 17 18 19 20 21 22 23 24 4--------4------60 52 44 36 ----------- (C(28)) 25 26 27 28 D Block (28 bits) 7--------1------63 55 47 39 31 23 15 7 1 2 3 4 5 6 7 8 6--------2------62 54 46 38 30 22 14 6 9 10 11 12 13 14 15 16 5--------3------61 53 45 37 29 21 33 5 17 18 19 20 21 22 23 24 4-------(D(25)--------------28 20 12 4 25 26 27 28 8--------0------64 56 48 40 32 24 16 8 LS (parity) Input Byte 8 7 6 5 4 3 2 1 Note that bit 4 is used as input for both C and D. This implies that C(28) output is used as the serial input to D(25). The least significant bit is used for odd parity.

1 0

crypto and law enforcement
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

In June, four people were arrested for allegedly producing the illegal newspaper "radikal" in Rheinland-Pfalz, Germany. One of the main reasons for imprisonment was that they refused to decrypt the disks found with them. The Attorney at the Federal Supreme Court now claims that three disks have been partially decrypted, but does not reveal the texts to the defense counsel because that could be "a danger to the investigations". The fact that the accused did not help in decryption is seen as an indicator for danger of collusion, so they will remain imprisonned on remand. It seems that these four people will face several years of imprisonment mainly because one of them chose a weak passphrase.

1 0

Re: Quick commercial package question
by leonardr＠aladdinsys.com 17 Dec '03

17 Dec '03

At 10:57 PM 10/24/95, Marshall Clow wrote: >> http://www.uccs.edu/~abusby/mac_u-g/RemoveIt.sit.bin >> I also just checked this out, and I as the engineer currently responsible for StuffIt (and having worked on it for a number of years), I can tell you that the thing simply won't work as documented. I'll even explain why... StuffIt actually encrypts data (it doesn't just password protect it), but it does so using a COMPLETELY RANDOM key and then that random key is encrypted using the password that the user entered (user key) and then stored in the MKey resource. We do this so that the same file encrypted with the same "user key" doesn't generate the same data (and therefore aid in easier breaking). So by replacing an archive's MKey resource, only means that you can manipulate an encrypted archive (delete things, etc.) BUT it still won't decrypt your data, since the original encryption key is not present. If you know the person who wrote or posted the information, please feel free to forward my message along to him. Thanks, Leonard Rosenthol ----------------------------------------------------------------------------- Leonard Rosenthol Internet: leonardr(a)aladdinsys.com Director of Advanced Technology AppleLink: MACgician Aladdin Systems, Inc. America Online: MACgician

1 0

arg
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Frissell: "The average seasoned citizen pays a higher percentage of his income for medical expenses today than he did in 1964 before the passage of Medicaid." Do you set aside a quiet hour every day to think up this crap?

2 1

Re: Quick commercial package question
by tbyfield＠panix.com 17 Dec '03

17 Dec '03

At 11:05 AM 10/25/95, Leonard Rosenthol wrote: >At 10:57 PM 10/24/95, Marshall Clow wrote: >>> http://www.uccs.edu/~abusby/mac_u-g/RemoveIt.sit.bin <...> > If you know the person who wrote or posted the information, please >feel free to forward my message along to him. I don't know the person, but I posted your note--and, BTW, thanks for responding--to alt.hackintosh, where the above web page proffering this pseudo-crack is regularly mentioned; I know that "abusby" monitors the group (and maintains a big hacking BBS), so hopefully he'll pull the crack from circulation. Cheers. And thanks, also, for all of your very excellent work. Ted

1 0

Re: Hack DigiCash: Payee Anonymity
by David E. Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >This is for a "WorldCurrency Access Interest Account", which I don't >think is what is used for ecash. For ecash the account opening fee is >$11 and the per-month fee is $5. I don't see any reference to required >account minimums. Aha. That's where I got the $11 figure from. I suppose I should try actually _reading_ all the fine print :) IANAL, but then I never claimed to be. I'll be writing to Mark Twain's contact ("ftrotter(a)marktwain.com") and try to figure out just what the deal is. Dave - ----- David E. Smith, "dsmith(a)midwest.net", PGP ID 0c92732139 http://www.midwest.net/scribers/dsmith/ Sorry, the full signature is being interrogated by news.admin.net-abuse.misc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMI5y7AwyfvCScyE5AQEn7wQAoUT/6fBZcUSM5eT7HYnY0Tx5Q35Q4aeB a2lTJWnMRta5i16qCtKF/0OiK/9bfs0i3FQqUMpireXp7YZn5n0D83mr+AWuJZBc +0170zWpsVZElAoZU8ZPV06PDQwuraH2pmdBMt9Kfabi4w4BGbqJ3E4rYvhx95dj hWnAp+6RzJg= =IM+h -----END PGP SIGNATURE-----

2 1

Re: Mark Twain Bank (was: Anonymity: A Modest Proposal)
by Duncan Frissell 17 Dec '03

17 Dec '03

For those interested in the first bank to back Ecash: Mark Twain Bank opened to serve the wealthy suburbs of Saint Louis (Ladue and Town & Country) a few years ago. It was meant to be a public "private bank" for sophisticated customers. A few years ago when the rules were eased, it started offering accounts and CDs denominated in 25 foreign currencies. These accounts were meant for international investors and business types in the area. They were discovered by "hard money" newsletters and became popular with that crowd. They have been the cheapest place to get foreign currency accounts in the US. Initially, the bank didn't realize that this sort of "hedge" market existed but have since exploited it fairly well. These accounts are FDIC insured up to $100,000.00 in $US equivalents. Obviously, exchange losses are not covered by FDIC insurance. The Ecash trial involves opening a World Currency Access Account which *is* FDIC insured and using it to fund your Ecash account which is *not* insured. They are treating the Ecash Mint part of their operations and the various customer Ecash accounts as investment accounts (hence the investor sophistication disclosure questions on the application form). Unanswered questions --- What will the SEC say? Mark Twain seems to be carrying on the fine old tradition of Saint Louis banks being a bit independent and out in front of the crowd. Other examples include Southwest Bank always leading the nation on Prime Rate changes and the Saint Louis Federal Reserve Bank (the only FRB to publish a hard money newsletter). I may wait for the Swedish Postal Bank to start offering its Ecash accounts just cause I like foreign climes. DCF "The Revolution will *not* be FDIC insured BTW."

1 0

HTTP Request-Header & Server Environment Echoes
by Richard.Johnson＠Colorado.EDU 17 Dec '03

17 Dec '03

<HTML> <HEAD> <TITLE>What Your Browser Says Behind Your Back</TITLE> </HEAD> <BODY> <PRE><TT> The what your browser told me about you when you weren't looking echo CGI at UIUC mentioned on cypherpunks (http://www.hks.net/cpunks/ cpunks-9/0095.html) in Nov. 1994 seems to be down for the count (it was http://www.uiuc.edu/cgi-bin/printenv )). It would provide you with a page showing the information your browser had given to the server in the HTTP Request-Header. However, others exist to take up the slack. Here's a directory I compiled today (thanks to WWWW, Lycos, etc.) of current, working HTTP Request-Header and resulting server environment variable echoes. I'm sure I've missed some, if not many. Follow up with additions, if you want. Better yet, add these and the additions to your favorite privacy and security pages. HTTP Request-Header Echoes Machine Information at MIT (http://www.mit.edu:8001/machine) Feeds back your machine name, IP address, and finger info. Not really a request-header echo at all, but useful. Echo at TU-Berlin (http://www.cs.tu-berlin.de/sui/eserte/cgi-rcs/home/ eserte/.public_html/index.html Raw text echo of your HTTP request-header info. Echo by Pierre Omidyar at best.com (http://www.best.com/~pierre/printenv. cgi) and at ebay.com (http://www.ebay.com/printenv.cgi) Two paths for reaching the same CGI script. Produces nicely formatted HTML output showing your HTTP request-header info. Simple perl source for the script is available from Pierre's Web Tips (http://www.best. com/~pierre/web-authoring.html) page. Echo by mjd at cis.upenn.edu (http://www.cis.upenn.edu/cgi-bin/mjd/ printenv) Produces formatted HTML echo of your HTTP request-header info. Echo at hyperreal.com (http://www.hyperreal.com/cgi-bin/printenv) Produces plaintext HTML echo of your HTTP request-header info. Echo at Whithead Institute--MIT (http://www-genome.wi.mit.edu/WWW/ examples/Ch9/printenv.pl Produces formatted HTML echo of your HTTP request-header info. Simple perl source for this script is available in the Chapter 9 script examples (http://www-genome.wi.mit.edu/WWW/examples/Ch9/) from Lincoln Stein (http://www-genome.wi.mit.edu/~lstein/)'s book, How to Set Up And Maintain a World Wide Web Site (http://www-genome.wi.mit. edu/WWW/). Echo by cloos at io.com (http://www.io.com/cgi-user/cloos/environment) Raw text echo of your HTTP request-header info. Also provides a whole bunch more, including the script's runtime environment. And now, again in the original HTML: </TT></PRE> The <CENTER>what your browser told me about you when you weren't looking</CENTER> echo CGI at UIUC <A HREF="http://www.hks.net/cpunks/cpunks-9/0095.html">mentioned on cypherpunks</A> in Nov. 1994 seems to be down for the count (it was http://www.uiuc.edu/cgi-bin/printenv) It would provide you with a page showing the information your browser had given to the server in the HTTP Request-Header. However, others exist to take up the slack. Here's a directory I compiled today (thanks to WWWW, Lycos, etc.) of current, working HTTP Request-Header and resulting server environment variable echoes. I'm sure I've missed some, if not many. Follow up with additions, if you want. Better yet, add these and the additions to your favorite privacy and security pages. <H3>HTTP Request-Header Echoes</H3> <DL> <DT>Machine Information at MIT <DD>Feeds back your machine name, IP address, and finger info. Not really a request-header echo at all, but useful. <DT><A HREF="http://www.cs.tu-berlin.de/sui/eserte/cgi-rcs/home/eserte/.public_html/inde…">Echo at TU-Berlin</A> <DD>Raw text echo of your HTTP request-header info. <DT><A HREF="http://www.best.com/~pierre/printenv.cgi">Echo by Pierre Omidyar at best.com</A> and at ebay.com <DD>Two paths for reaching the same CGI script. Produces nicely formatted HTML output showing your HTTP request-header info. Simple perl source for the script is available from <A HREF="http://www.best.com/~pierre/web-authoring.html">Pierre's Web Tips</A> page. <DT><A HREF="http://www.cis.upenn.edu/cgi-bin/mjd/printenv">Echo by mjd at cis.upenn.edu</A> <DD>Produces formatted HTML echo of your HTTP request-header info. <DT>Echo at hyperreal.com <DD>Produces plaintext HTML echo of your HTTP request-header info. <DT><A HREF="http://www-genome.wi.mit.edu/WWW/examples/Ch9/printenv.pl">Echo at Whithead Institute--MIT</A> <DD>Produces formatted HTML echo of your HTTP request-header info. Simple perl source for this script is available in the <A HREF="http://www-genome.wi.mit.edu/WWW/examples/Ch9/">Chapter 9 script examples</A> from <A HREF="http://www-genome.wi.mit.edu/~lstein/">Lincoln Stein</A>'s book, <CITE><A HREF="http://www-genome.wi.mit.edu/WWW/">How to Set Up And Maintain a World Wide Web Site</A></CITE>. <DT><A HREF="http://www.io.com/cgi-user/cloos/environment">Echo by cloos at io.com</A> <DD>Raw text echo of your HTTP request-header info. Also provides a whole bunch more, including the script's runtime environment. </DL> </BODY> </HTML>

3 2

Re: CJR returned to sender
by Frank Stuart 17 Dec '03

17 Dec '03

Even if the T-shirts are a joke, it seems like applying for an export license is a win-win proposition. If the government denies the license, they end up looking extremely silly and it's easier to point out to Joe Sixpack (or a judge) how silly ITAR is w.r.t. cryptography. If they grant the license or say one isn't necessary, it might open up the way for "cypherpunk party-streamers" which also happens to be your favorite crypto program on colored paper tape or perhaps even limited edition, hand painted, collectable cypherpunk CDs containing mostly music but with a data track or two. The only bad response would be none at all, so I think pushing for one is worthwhile even if the answer is "that's a frivolous request". | (Douglas) Hofstadter's Law: Frank Stuart | It always takes longer than you expect, even fstuart(a)vetmed.auburn.edu | when you take into account Hofstadter's Law.

1 0

Re: CJR returned to sender
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:35 AM 10/25/95, Timothy C. May wrote: > >(* Hal Abelson of MIT says there are possible export problems with the MIT >Press book on PGP, and MIT dropped plans for a version in a special OCR >font. So, I agree that _some_ books cross the line and look like pure >software. However, I continue to maintain that a badly-printed barcode is >just a joke, nothing more.) Brian LaMacchia sent me e-mail saying the MIT book _was_ published with the OCR font as originally planned. No response to their CJR request, submitted in Jan or Feb. (I spoke to Hal Abelson at the CFP Conference in Feb, and that's when I got the impression the OCR font had been dropped. Apparently not.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1