December 2003 - cypherpunks-legacy

How much entropy in a key press?
by Nobody＠eniac.ac.siue.edu 17 Dec '03

17 Dec '03

Can anyone tell me how many bits of entropy there are per 7-bit ASCII character. More specifically, a program wishes to generate a session key by prompting the user to type N random key presses. The characters entered are hashed down to 128 bits by MD5 for subsequent use as a key. What should the value of N be, such that the entropy of the user's string does not unnecessarily exceed the entropy of the hash?

3 2

Video encryption & QTC
by paul＠poboy.b17c.ingr.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ for cypherpunks: Apple's now beta testing a video conferencing product called QuickTime Conferencing, or QTC. The Mac crypto interface list (mcip(a)feeley.cc.utexas.edu) started a discussion on video encryption, hence this crosspost. Feel free to chime in. ] Here are a couple of additional things to consider. This is a pretty classic application for stream ciphers. Since QTC is transport-independent (and I'd bet it's using OpenTransport calls, too), I'm assuming that QTC is using streams for video data, and that any packetization happens at the transport layer. Just before you call UDPSend(), ATPSend(), or whatever, just whack that outgoing block through the crypto function and off you go. As mentioned, RC4 might be a good choice. It's fast, plus Apple's already licensed it. It probably provides adequate tactical security, but as Adam pointed out, it has not been well analyzed in the open literature. However, there are many other stream ciphers out there: Diamond, Blowfish, RC5, etc. My gut feel is that RC4 is probably adequately secure with a 128-bit key; then Apple can dumb down to 40 bits for export approval. After all, they're not likely to build a product which they can't export. What about using a PCMCIA card like the National Semi Persona 100? It includes RSA signatures & verification, Diffie-Hellman key exchange (I think) and single DES; future versions will include 3DES and IDEA. Hardware encryption is fast, fast, fast. Don't forget AT&T's recent announcement of a similar product which does 3DES. One MCIP reader proposed just using PGP: RSA the session key and send it along. IMHO Diffie-Hellman is a better way to do this. Rather than using the PGP metaphor, where RSAing the session key allows you to send the session key as part of the message, DH allows you to establish the session key over an insecure channel, then start sending messages. - -Paul - -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich(a)ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ### -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzEFkKfb4pLe9tolAQEtEAP/bxEHw+fwPaJJPyHaRRtuZqlxmzvEyD+w 5cmB9c75gzkY9SpSSLkbtawwUjCCiKynMAX76uSRaDRkVeTILelJ3gvdguRMS3Id MYQI162mPvCN+lTvsMoXVJAdZzC14WE9JE0t9FC+ovYE8M+/yZ16EGEnvtWbnNYQ pO8GkvNpR+g= =n3fX -----END PGP SIGNATURE-----

1 0

A simple idea
by Jon Lasser 17 Dec '03

17 Dec '03

Maybe this has been discussed before, but if so I wasn't around for it and would like to know: What if: (assuming trusted remailers, but still worried about traffic analysis of those remailers): One mailed a message to one remailer. This remailer held onto all messages until some predestined hour or kilobyte size or whatever, and then forwarded ALL its messages to this other remailer, in one packet (.TARred and PGPed separately, say), but NOT IN THE ORDER RECIEVED? While this wouldn't solve all the problems (to some extent, the sizes of files might be correlated, but this could probably be foiled by other means), wouldn't it at least foil the easy to/from traffic analysis that is (I believe) the greatest threat? Jon ============================================================================== Jon Lasser <jlasser(a)goucher.edu> This is an advanced .signature virus -- please attach to your .signature and add your last initial to the list: l ------------------------------------------------------------------------------

1 0

Adding padding to PGP files
by Hal 17 Dec '03

17 Dec '03

Here are a couple of perl scripts I wrote last year to add padding to PGP encrypted files. The usage would be: perl pgppadt.pl filename bytestoadd The output file is filename.pad. It only works on binary ".pgp" public-key encrypted files (not ascii armored files). So there would be some work needed to make it a really useful tool. It would also be better to use a strong source of random numbers. I think Carl Ellison recently posted some tools that could help with this. The two files are pgppad.pl, which does the work, and pgppadt.pl, a very simple test driver to show how to use it. They are in a shar archive. Hal ---------------cut here---------------- #!/bin/sh # to extract, remove the header and type "sh filename" if `test ! -s ./pgppad.pl` then echo "writing ./pgppad.pl" cat > ./pgppad.pl << '\End\Of\Shar\' # Perl module to allow padding and some other manipulation of PGP # files. # # Include this with the statement: # require 'pgppad.pl' # # 10/16/93 # Hal Finney # Read a PGP Cipher Type Byte and the following length. # One argument: file to read from # Returns several things, in this order: # CTB, with the length information removed, as a number. # Length of following packet. # Name of this kind of packet, made up, see list below. # Packed CTB/length packet, suitable for writing out. # Returns an empty string on error. sub read_ctb { local($file) = @_; local($ctb, $length, $name, $rctb, $rlength, $lengthlength); if (read ($file, $rctb, 1) != 1) { # Raw ctb return ""; } $ctb = unpack ("C", $rctb); if ($ctb < 128) { return ""; # Must have high bit set } $lengthlength = $ctb % 4; $ctb -= $lengthlength; if ($lengthlength == 0) { $lengthlength = 1; } elsif ($lengthlength == 1) { $lengthlength = 2; } elsif ($lengthlength == 2) { $lengthlength = 4; } else { $lengthlength = 0; $length = -1; # Unknown length } if (read ($file, $rlength, $lengthlength) != $lengthlength) { return ""; } if ($lengthlength==1) { $length = unpack("C", $rlength); } elsif ($lengthlength==2) { $length = unpack("n", $rlength); } elsif ($lengthlength==4) { $length = unpack("N", $rlength); } $rctb = pack ("C a".$lengthlength, $rctb, $rlength); # Packed data if ($ctb==0x84) { $name = "pubkey header"; } elsif ($ctb==0x88) { $name = "signature"; } elsif ($ctb==0x8c) { $name = "message digest"; } elsif ($ctb==0x94) { $name = "secret key"; } elsif ($ctb==0x98) { $name = "public key"; } elsif ($ctb==0xa0) { $name = "compressed"; } elsif ($ctb==0xa4) { $name = "conventional encrypted"; } elsif ($ctb==0xa8) { $name = "plaintext"; } elsif ($ctb==0xb0) { $name = "trust"; } elsif ($ctb==0xb4) { $name = "user id"; } elsif ($ctb==0xb8) { $name = "comment"; } else { return ""; } return ($ctb, $length, $name, $rctb); } # Write a CTB and length field out. # 3 arguments: file handle, ctb value, and length in bytes. # No return value. # Length gets output as 1, 2, or 4 bytes, the smallest in which it # will fit. # If length is negative we output no length field, but an "indefinite # length" code is added to ctb. sub write_ctb { local($file, $ctb, $length) = @_; local($rctb); $ctb = $ctb - ($ctb % 4); # Be sure 2 low bits are clear if ($length < 0) { $rctb = pack ("C", $ctb+3); # Packed data } elsif ($length > 65535) { $rctb = pack ("C N", $ctb+2, $length); # Packed data } elsif ($length > 255) { $rctb = pack ("C n", $ctb+1, $length); # Packed data } else { $rctb = pack ("C C", $ctb+0, $length); # Packed data } print $file $rctb; } # This entry point always outputs a 4-byte count. Length must be > 0. # Otherwise like write_ctb. sub write_ctb_4 { local($file, $ctb, $length) = @_; local($rctb); $ctb = $ctb - ($ctb % 4); # Be sure 2 low bits are clear if ($length < 0) { die ("write_ctb_4 called with negative length\n"); } $rctb = pack ("C N", $ctb+2, $length); # Packed data print $file $rctb; } # Pad a PGP public-key-encrypted file to the specified length. # Arguments: input file handle; output file handle; new size. # Returns negative value on error. See the code for what the # different values mean. # Returns 0 on success. sub pgppad { local($infile, $outfile, $size) = @_; local($ctb, $length, $name, $rctb, $insize, $buf); # Read ctb & length of pubkey header ($ctb, $len, $name, $rctb) = &read_ctb($infile); if ($ctb == 0) { return -1; # Error } if ($name ne "pubkey header") { return -2; # Error } if ($len < 0) { return -3; # Error } $insize = length($rctb) + $len; # Read packet of pubkey header if (read ($infile, $data, $len) != $len) { return -3; } # Write out pubkey header, unchanged &write_ctb($outfile, $ctb, $len); print $outfile $data; # Read ctb and length of conventional packet ($ctb, $len, $name, $rctb) = &read_ctb($infile); if ($ctb == 0) { return -4; # Error } if ($name ne "conventional encrypted") { return -5; # Error } # Calculate size of outgoing conventional packet. # Assume rctb won't change size; it may grow by 1 or 2 in some # rather rare cases, in which case we'll be a byte or two too big. $size -= $insize + length($rctb); if ($size < $len) { return -6; # Error } # Output CTB with new length &write_ctb_4($outfile, $ctb, $size); # Copy remainder of input file while (read ($infile, $buf, 32768)) { print $outfile $buf; } # Note that this random number generator is probably not # cryptographically strong. srand (time|$$); while ($len < $size) { print $outfile pack ("C", int(rand(256))); ++$len; } return 0; # Success } 1; # Non-zero return for 'require' \End\Of\Shar\ else echo "will not over write ./pgppad.pl" fi if `test ! -s ./pgppadt.pl` then echo "writing ./pgppadt.pl" cat > ./pgppadt.pl << '\End\Of\Shar\' # Test program for pgppad.pl, showing how to use it. require 'pgppad.pl'; open (IN, $ARGV[0]) || die ("Couldn't open $ARGV[0]\n"); open (OUT, ">$ARGV[0].pad") || die ("Couldn't create $ARGV[0].pad\n"); $padding = $ARGV[1]; @stat = stat(IN); $size = $stat[7]; print "Input file $ARGV[0] has size $size bytes\n"; print "Output file $ARGV[0].pad will have size ".$size+$padding." bytes\n"; if (($code = &pgppad (IN, OUT, $size+$padding)) < 0) { die ("pgppad returns code $code\n"); } close (IN); close (OUT); print ("Done\n"); \End\Of\Shar\ else echo "will not over write ./pgppadt.pl" fi echo "Finished archive 1 of 1" exit

3 2

Re: Frothing remailers, the advertising and pinging problems
by xpat%vm1.spcs.uma.thurman.edu＠vm1.spcs.umn.edu 17 Dec '03

17 Dec '03

jrochkin(a)cs.oberlin.edu (Jonathan Rochkind) wrote: > ++Mail ping. Non-IP, simple, slow. ++ > A mail ping simply consists of sending a message to a remailer with a > Request-Resending-To: yourself. When you get it back, you know the > remailer is alive. > This has the advantage that it's hard for the remailer > to trick you, even if it is an evil NSA remailer that wants you > to believe it is alive, even though it really throws messages in > in the trash. It can't differentuate between your "ping" > (to be returned) and a normal message (to be thrown in the trash). Sure it can. if (message_origin==request-resending-to) forward_message; To get around this you would have to chain, thereby relying on an additional remailer. Of course your origin and resend addresses could become are different through net.sorcery, but to rely on existing (and most likely transient) security loopholes are unsound foundations to construct a persistent reliable remailer net. Of course, clever Evil Remailer (tm) operatives might have their machines work *most* of the time, and have more than one, so that the entire network of remailers *seems* unreliable, or subtlely mangle encrypted messages so that the ball drops somewhere else. ---------------------------------------------------------------------- P M Dierking | "Emptiness is consistent with everything" --Nagarjuna

1 0

Re: Remailer encryption module
by Hal 17 Dec '03

17 Dec '03

From: "Perry E. Metzger" <perry(a)imsi.com> > Eric Hughes says: > > > > Once we get a data format, implementations will follow. > > > > The obvious data format is MIME's "Security Multiparts". > > Perry For those wishing to follow this debate, here is a URL for this document: <URL:http://info.internet.isi.edu/in-drafts/files/draft-ietf-pem-sigenc-03.t…> I had trouble finding it since the filename does not contain "mime" or "security". Hal

1 0

info
by Luis Agustin Perez 17 Dec '03

17 Dec '03

I recently read an atricle in HT magazine called cyberbucks. I was wondering if you could send me some information on the topic of the article. thanx

1 0

MX'ing and jpunix.com
by John A. Perry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- JPUNIX.COM (soon to be alias.net) offers a MX service for individuals that want to run an anonymous remailer but don't want the domain they are operating from to be immediately apparent. By making application to perry(a)jpunix.com, a remailer operator will be granted a DNS MX record pointing to the domain address of the requestor's choice and will appear to reside in the jpunix.com (alias.net) domain. Additional masking can be provided by having the MX record point to myriad.pc.cc.cmu.edu. What good does this do? I have an agreement with myriad.pc.cc.cmu.edu (Matt Ghio) where myriad will take the MX-pointed record and additionally alias it through the smail daemon on myriad. This function adds the unique benefit where determining the actual location of the remailer in question will be foiled when using nslookup. Since an additional alias is performed the result of an nslookup will always point to myriad. The actual location of the remailer remains hidden inside the alias on myriad. Lastly, Matt has the EXPN function of his sendmail daemon disabled so the identity of the remailer can't be determined by alias expansion. Future modifications to this scheme include adding an addition step whereby the MX-alias process will cause a version of Raph Levien's premail to post-process the message to add one or more random remailer paths the the overall path that the message travels. This step in still in the planning stages and has not been implemented yet. If you have and questions, or want to set up an MX record, send email to: perry(a)jpunix.com or ghio(a)myriad.pc.cc.cmu.edu John Perry < perry(a)jpunix.com> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzFN6lOTpEThrthvAQHfAAQAkzoGHz7iaJKHMzB5GEQr8OvEwhDY0F9s lCZUJhTw3KV2hVWDoUtZNPwiSf4vcsDhGx0CDQrDUon2vXC0mOHj4zBbDhhuUD5l /NCPOmtWKFSnWiny2JbD0esNIuxIaWfa/tVTkDoDq/zPtsG0awmHTpGMSeIkkxvy II1mDwnZ9n0= =2jQD -----END PGP SIGNATURE-----

2 1

Remailer Unreliability
by nobody＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

What if it was possible to specify an alternate remailer? In the case that a remailer went down, you could specify an alternate. For example: :: Anon-To: remailer(a)foo.com Alternate-To: remailer(a)bar.com :: Encrypted: PGP ---pgp msg--- If foo.com was down, the message would be delivered to bar.com instead. The PGP message would have to be readable to both of them, so it would decrease security, but reliability would be better, especially for reply blocks. Comments?

3 2

The FIREWALL CHIP. U're phone always offhook?
by Gary Jeffers 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- THE FIREWALL CHIP! U'RE PHONE ALWAYS OFFHOOK? We have potential bugging devices in all our houses - The telephone! Of course, when it is onhook, the microphone does not transmit... or does it? Would the phone have to be rewired to render it always "offhook" or would it be an operation at the central phone company? If the present models would have to be rewired, then how about future models? Much function is done thru chips & so could many of the models on the current market be remote programmable? See the latest issue of Mondo 2000. This problem demands a hardware solution. How about an adapter module between microphone & the rest of phone? THE FIREWALL CHIP The Clipper chip architecture was secret! Cypherpunks demand source code with their security software! How about a demand for the "visable" chip. That is - a chip with a known architecture - that can be tested for integrity & is a general computer chip for doing software operations & for doing i/o with electronic devices? With our property being loaded up with sophisticated "trust me" electronics, it may be necessary to have a general electronic "FIREWALL CHIP". The FIREWALL CHIP could have its applications software supplied by various companies which would specialize in fields for detecting electronic intrusion. Some specializing in phone audio, others in vision telephones, cell phone tracking, & many others to be considered. The FIREWALL CHIP will be a future necessity. It & its software suppliers will probably constitute an outlaw industry. PUSH EM BACK! PUSH EM BACK! WWWAAAYYY BBBAAACCCK! BBBEEEAAATTTT STATE! Gary Jeffers - --- [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 iQBFAwUBLzFxYCoZzwIn1bdtAQG0ewF/RUMJZU1qXc+31XVQLfetSZst4j+S55/i tq6j/JN5t3rjXa873mY5lT4cHCFBukfv =NSeZ -----END PGP SIGNATURE-----

3 2