December 2003 - cypherpunks-legacy

Phil Zimmermann/Amnesty International?
by gjeffers＠socketis.net 17 Dec '03

17 Dec '03

Phil Zimmermann/Amnesty International? I was wondering if the Zimmermann case would be a proper concern of Amnesty International. Phil is obviously a political dissident. His persecution is obviously political. If Phil got support from Amnesty Int'l, then his persecution could be a big embarrassment to the Federal gov't. He has a lot of supporters and taking up his cause could be a big promotional for Amnesty International. The Feds might feel forced to drop the matter early. Any ideas? Gary Jeffers

9 12

Re: Digital Fingerprinting
by Andrew Loewenstern 17 Dec '03

17 Dec '03

> I said I'd mention "state secrets" again. The usual example for > making subtle modifications to documents to see who leaked it is > the intelligence community, which gave us the term "barium" (because > the changes look like barium in an x-ray diagnostic). Such technology would be very useful in business, especially the high-tech industry. Think of how many non-disclosure agreements are signed every day relating to new products developed for the software industry alone. Many companies are very paranoid and already 'fingerprint' information by using unique code-names for projects, for instance. i.e. the spec sheet on their new GAK crypto product they give to Alice may be code-named 'project foobar' but the one they give to Bob may be code-named 'project burris'... Then, when the information leaks out they check which person they gave the document with that code-name and they know who to sue (or at least not give any more trade-secrets to). It's very simplistic but it has been know to work in the past. Most of the real technology for doing this is much better, of course... However, what stops you from printing out a fingerprinted document and scanning it back in, for instance? andrew

1 0

Re: Crypto and new computing strategies
by fnerd＠smds.com 17 Dec '03

17 Dec '03

> Jim Choate writes: > > > In the latest issue of Scientific American there is an article... On Seth Lloyd's grain-of-salt computer, actually. I didn't know he was going to build one. Anyway, his technique *may* be useful to make quantum computers, but it's more likely to be useful for making regular deterministic massive single-instruction-multiple-data computers out of fairly simple crystals--"maybe even a grain of salt." His technique would make every repeating unit of the 3D crystal into a computing unit. You lose a couple factors of 10 for addressing, making higher-level modules, and error-correction. Still, that's a lot of compute power. Tim May says- > No need to worry just yet. > > There is no convincing evidence that "quantum computers" can calculate > in any way differently from "ordinary" computers. Right. This is just a large power increase using deterministic stuff. It's based on electrons in the shells of atoms in crystals responding to different frequencies of photons depending on their own and neighboring atoms' shells' states. > Devices that are built on a size scale where quantum effects are > important, such as quantum-well devices, don't use QM as a > computational mechanism per se. The devices are just real small. But > not small enough to matter for large RSA moduli--the computations > required to factor a 1000-decimal-digit number swamp even a universe > _made_ of computers! Which is what a naive guess would have said about 129-digit numbers. I would love to see some sort of curve of factoring algorithm efficiencies over time. You could show the log of the difficulty for a selection of number sizes over the past hundred years, say. The experts say it's flattening out and will probably stay that way. A sudden jump in the high end of computer power would mean that we would need to use larger keys sooner than we thought. A key length requiring a little bit more work on the user's part means a lot more work on the cracker's part, but I don't know how many more bits of key compensate for a 10^9 increase in cracking power, say. -fnerd quote me - - - - - - - - - - - - - - - blue pill, Pharm. a pill of blue mass, used as an alterative... alterative, adj. tending to alter... -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

6 18

Famous Zen koan: what is the sound of two shoes dropping?
by Brian A. LaMacchia 17 Dec '03

17 Dec '03

You may recall that Dorothy Denning had a pro-Clipper article in _Technology Review_ back in July. The October issue of TR contains not only some critical letters to the editor, but also a reply from Denning. How things have changed over the last 18 months... --bal ------- Start of forwarded message ------- Date: Tue, 12 Sep 95 12:23:00 -0400 Return-Path: <hal(a)martigny.ai.mit.edu> From: Hal Abelson <hal(a)martigny.ai.mit.edu> To: bal(a)martigny.ai.mit.edu Subject: Famous Zen koan: what is the sound of two shoes dropping? What is the sound of two shoes dropping? **Part 1: March 10, 1994 (From the debate between Dorothy Denning and John Perry Barlow, moderated by Philip Elmer-DeWitt) Barlow: EFF is not asking the Government to drop Clipper, though we would vastly prefer they did. We're merely asking that no steps be taken to require it either by law or practice...as, for example, would be the case if you had to use a Clipper chip to file your tax return. DeWitt: Dr. Denning, do you think this is the "first step in a process to outlaw crypto"? Denning: No I do not. ***Part 2: October 10, 1995 (From Dorothy Denning's response to letters to the editor in _Technology Review_) Denning: But critics make an important point when they argue that criminals will not use Clipper or other forms of key escrow encryption. As long as there are no laws in the United States controlling the sale and distribution of encryption products, the U.S. market will be flooded with products that have no provisions for government access. This eventual threat to public safety and social order could be avoided by establishing a licensing program for encryption products that reasonably satisfy the government's decryption requirements and do not interoperate with unlicensed systems. While the manufacture and distribution of unlicensed encryption products would be illegal, no particular system would be mandatory and any licensed product could be used without restriction. Although such a licensing program would not prevent criminals from using unlicensed products, their availability would be limited to underground channels. ------- End of forwarded message ------- P.S. Denning's TR article is available at: http://web.mit.edu/afs/athena/org/t/techreview/www/articles/july95/Denning.…

1 0

Re: Here it is; bi-directional dining cryptographers
by Andrew Roos 17 Dec '03

17 Dec '03

Phil Fraering <pgf(a)tyrell.net> observes: > If Alice and Bob are members of a reasonably non-compromised and > free of colluders dining-cryptographers network, with a protocol for > reserving blocks for the transmission of data packets, then if they > both send a data packet in the same block, they can each read what > the other is saying but to the rest of the DC-net it is garbled. > > Since what is broadcast is the XOR of Alice's and Bob's data, Alice can > read Bob's data by XOR'ing the output of the DC-net with her attempted > input; Bob can recover her data the same way. > > Comments? I haven't been following the DC thread so forgive me if I've missed something... If the objective is to keep what Alice and Bob say SECRET then we have a problem if the entropy per bit of Alice's data plus the entropy per bit of Bob's data is less than one bit, because then there is only one likely decryption of the "ciphertext", which will reveal what both Alice and Bob are saying. The system is analegous to a variation on the old Vigenere/Beaufort cipher where instead of using a single repeated keyword to generate to encryption stream, you use another "plaintext" message such as a passage from a book which is known to both correspondents. (Here the addition is done mod 26 instead of mod 2). Since the entropy of natural language is 1-1.5 bits/char, the entropy of two natural language texts added together is 2-3 bits per char, while the no of ciphertext bits is about 5 bits per char, so there remains 2-3 bits per char of redundancy in the text, which can (quite easily) be used to break the system even on a ciphertext-only basis. One way to do this is to search for "probable words" of one side of the conversation, then see what the other text would have to have been to generate the known ciphertext, and if this other text makes sense then bingo, we have an initial break, and you can usually extend this quite easily by extending one text, then seing what this gives for the other, extending that, and so on. > (At the very least, it doubles the bandwidth for the two participants...) I have to agree here, though! Andrew ___________________________________________________________________________ #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL ($k,$n)=(a)ARGV;$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2% Sa2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*' ,$_)while read(STDIN,$m,($w=2*$d-1+length($n||die"$0 [-d] k n\n")&~1)/2) Andrew Roos Realtime PO Box 15170 Vlaeburg 8018 Phone: +27-21-244350 Cape Town Cape Town Fax: +27-21-221507 South Africa

2 2

remailer abuse
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Remailers exist (at least mine does) to make possible the dissemination of unpopular views. "Unpopular" depends on context; so does "abuse". The line between "unpopular" and "abuse" is difficult to draw. On the one hand, the recent "Mr. Pedophile" message seemed intended to make the recipient uncomfortable or offended probably because of illegitimate reasons (purportedly, pedophilia). Other messages which cause complaints seem to be responses to something that the "victim" has done or said somewhere else. It's tempting to say that a message which lays out in logical fashion coherent arguments explaining why the "victim's" original message is wrong is likely to cause discomfort or embarassment but is legitimate, while a message which says, to quote from a complaint message I received this weekend, "Fuck you asshole. I hope you choke on your son's sperm." isn't legitimate even though it may also cause discomfort or embarassment. So I guess it's not so much a message's effect upon its recipient (or its intended effect) which is legitimate or illegitimate as it is the message's means of doing so. And that seems really tough to judge, where a remailer operator doesn't know the context in which a message is sent. (I do think it's possible that the "Mr. Pedophile" message was sent by another child or teenager intending to torment the target, not by an actual pedophile. It's possible that the sender was the target himself. It's also possible that the sender was an actual pedophile or a child-hostile adult, but that's not the only plausible explanation. People do strange, strange stuff.) In a situation where person A uses system X to send messages to person B who uses system Y, I'm not sure what B can expect from the system operator of system X. (I'm thinking about net custom here, not law.) If A wants to send messages to B, but B doesn't want to receive them, should A be forced to stop sending? Does X have an obligation to make A stop? Does X have an obligation to modify his system such that messages from A to B are automagically suppressed? Does X have an obligation to refuse service to A (and forego payment for service from A) if A won't stop sending to B? Is the answer different if B doesn't want the messages because they (are likely to) contain profanity? or because they are from a person of the wrong religion? or because they're hostile or argumentative? As a first response I'm likely to say that if A knows (or should know, or can guess and be pretty certain of the result) that B doesn't want to get a particular message, A shouldn't send it. But then I realize that there are a number of exceptions - what about if A's message to B is in response to a spam or otherwise inappropriate message from B? what about where B owes A money? or if B has said something ridiculous or stupid and A is writing to correct B? I think that there wouldn't be many inappropriate posts sent to the C-punks list, for example, if everyone who thought a post was inappropriate (not just factually arguable, or uninteresting) sent a message to that effect; the impact of just a few hundred such messages in reply to a single message would likely be burdensome enough to make the sender think twice before sending again. But that inconvenience is anticipated by (and motivates) the senders of those hundreds of messages. I still don't think it's wrong to send the messages. I guess my point is that eliminating "abuse" is pretty much impossible because abuse is in the eye of the beholder. I don't think we need to rely on the mercy or good graces of the net at large, though - remailers will likely prove to be as difficult to eliminate as spammers have been. The net is too big to be centrally policed, and individual providers often have an incentive to tolerate behavior otherwise frowned upon because they're being paid to do so. (and if they begin content filtering they may lose any sort of quasi-common-carrier status they might enjoy now, viz _Cubby v. Compuserve_, etc.) Even if the United States adopts rules requiring messages be identified as to the sender, it won't be possible to eliminate overseas remailers - and I imagine that folks would just start up pseudonymous remailers. (I've worked on some prototype code and will deploy a pseudonymous remailer - where people get names like "fjones(a)pseudo.goldenbear.com <Frank Jones>" instead of "an12345(a)pseudo.goldenbear.com <Anonymous Sender>", in order to divert or confuse anti-anonymous policies or programs.) I think adopting a submissive or apologetic stance with respect to the operation of a remailer is a mistake. What we do is protected by the First amendment, supports a 200+ year tradition of anonymous political speech in America, provides a valuable service to a worldwide community, and can help avoid the very abuse they are accused of facilitating. The child who was the target of the "Mr. Pedophile" message(s) should have been taught how to use remailers and how to maintain his privacy on the net so that, if he really is the victim of some sort of random child stalker, it won't happen again. There's no reason why any child should post to the net under their real name, or why their messages should be traceable to their physical bodies. If we're concerned about protecting kids from bad people who might reach them via the net, we need to teach kids how to send untraceable and unreplyable messages; how to send messages and do business on the net without allowing hostile or unscrupulous people to track them down; and how to make good choices about revealing personal information only to people who have a good reason to know it. People who are the targets of abusive messages or are concerned about abusive messages are some of the people who need remailers and need pro-privacy network tools the most. Giving in to a knee-jerk anti-privacy reaction only reinforces the erroneous notion that security is created by an enforced lack of privacy. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMK/ZRn3YhjZY3fMNAQHQkQQAmLlRGcwEbJyhb9dYm3dx/BoRj0NBTUr3 MOmRkP2+AtdCKL8gcaWhnY9TeXHj7enezo5TF8ooqvcOLEha29mL9Q+G08t2pkoM SGHr79Yr38syc6Mf+1pXAN7T1Dn600xgnJsDmrFFoQI5H0ZSeA6oLT3ShzhWpsJ/ 3FuNvR7TyLg= =nsOZ -----END PGP SIGNATURE-----

2 1

Cypherpunk Certification Authority
by Aleph One 17 Dec '03

17 Dec '03

Since now Netscape allows for user defined certification authorities I would like to hear some ideas for a Cybpherpunk CA. Probably run by one of the respected member in the group such as Sammer, Perry or Tim. I would like to hear some discussion about creating the certificates based on the web of trust of your PGP key, etc. Any takers? Aleph One / aleph1(a)dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01

12 13

Re: Certificate Authorities?
by Jeff Weinstein 17 Dec '03

17 Dec '03

We are looking at adding the ability for enterprise security administrators to lock various parts of the Navigator configuration so that the user can not change them, including stuff relating to trust and certificates. This functionality will not be in 2.0, but we do consider it important for certain customers. --Jeff P. Rajaram wrote: > Yes. But... > I deal with the security infrastructure for a large corporation. > I want only security administrators to configure the list of acceptable CAs. > I specifically do not want our users to be able to add new CAs > to the list of trusted "approved" CAs. > > The concern is that some users who are not crypto enthusiasts may be > "social engineered" into adding a very liberal CA to their list. > Once this happens, the browser's signature verification capability > is totally compromised. > > This is one of the reasons why PGP has not been adopted by many large > companies. In response, Viacrypt now seems to have a product that > can restrict user modifications to the public keyring. > > -raj -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

2 3

Re: Returned mail: User unknown
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

[whoops mispelled cpunks on cc line 1st time, sorry for 2 copies] Perry Metzger <perry(a)piermont.com> wrote: > Gary Jeffers <gjeffers(a)socketis.net> writes: > > Well, I just used MIT's PGP 2.6.2 with 3 different users' public > > keys to encrypt 3 different files. In all 3 files, the first 3 > > characters were the same (an umlauted A, then an i with an up arrow > > over it, and then a heart). This beginning 3 character string is > > apparently the infamous PGP RSA signature. The signature that says > > to spooks' programmed encryption sniffers - "HEY! I'M PGP - GIVE ME > > A LOOK!." > > As if they couldn't figure it out anyway. It isn't an "RSA signature" > by the way. Read format.doc sometime. Yeah, that's what stealth does, removes the boiler plate stuff saying, various things, such as pgp version number, rsa encrypted message, conventional idea block, and as Perry says, it's all in pgformat.doc in the PGP docs directory. > > When are the PGP designers and coders going to get serious and de- > > velope STEALTH PGP inside PGP itself!? > > Never, I hope. It would dramatically lower the utility of the > system. Can you imagine how disgusting it would be to try decrypting > something if you have a dozen keys outstanding? Not to mention how > hard it would be to deal with figuring out that you should even try to > decrypt things in the first place. I reckon it would be a very nice utility, built into pgp as an *option*, some countries it isn't legal to use PGP, and it hasn't been ruled out that the US may not be the next to join the list, all this GAK stuff, son of Clipper, it is a distinct possibility that the law enforcement lot might outlaw other crypto wiht mandatory GAK. Then stealth features for PGP become important for incorporating into stego, of course you can argue that well stealth should be part of the stego app then. It shouldn't be a problem unless it was enforced, as an option I see no problem with it, and lots of possible future advantages even. I'm trying to work on stealth2.1, modifing Henry Hastur's stealth util to added Hal Finney's algorithm for improving the stealthiness (it's not enough to just strip the headers as stealth1.x does, the fact that the RSA encrypted header is always < N, the rsa modulus gives the game away with a few messages to analyse for statistical purposes, ie if you see a lot messages < N, where N is by definition not an even power of 2, and possibly even N is known, or suspected from keyservers). I've been delaying releasing it because I was worrying about ran no generators being good enough, but I think I might have convinced myself that it is not even necessary to use ran no generators, I'd appreciate it if some folks with a bit of crypto expertise could cast their eye over the description below. > > So what, -that "only a few companies" will be discovered to be using PGP > > through the RSA signature!? Those few companies are the seeds for the > > vast numbers of companies that would follow them in using PGP over the > > Internet. The RSA signature is the flag that allows the spooks to easily > > net the bold first companies. The RSA signature is greatly impeding the > > spread of PGP use over the Internet. PGP MUST BE STEALTHED!! > > It isn't an RSA signature. Its a bunch of magic numbers. > > Look, get real already. If someone sees a bunch of random numbers in > mail sent by me, its going to be pretty obvious what the hell is > inside anyway. Yeah, but you wouldn't do it that way. I reckon this is what you'd do: % pgp -es duress % pgp -es msg % stealth < msg.pgp > msg.stl % cat msg.stl >> duress.pgp % pgp +makerandom=1234 noise % cat noise >> duress.pgp % pgp -a duress.pgp % mail someone < duress.asc The pgp +makerandom=<size> <file> is an undocumented feature of pgp > 2.6 (not sure exactly when it got added, Colin Plumb pointed it out when I asked him about ran nos for stealth). So what this means is that you are using PGP it's self to hide a stegoed message. This would be good for the guy from FACTnet (forgotten his name) who just got hit by the CoS, he could hold out for a while, then give up his key, the duress message would appear, and the real message would be explained by having a script to do this on his HD, and having long since burned the disk with a script to do the above on it: % pgp -es msg % pgp +makerandom=4567 noise % cat noise >> msg.pgp % pgp -a msg.pgp % mail someone < msg.asc ie the idea is that you pad your message to a fixed size for the express purpose of hampering traffic analysis (of the type of my, Alice did have a lot to say to Bob that day). It would be even better cover if the thing had gotten sent through a remailer, as this kind of thing is expected of type I remailer traffic (before mixmaster which does the packetizing for you). So the duress message really looks like this: +---------+---------------------------+--------------------+--------+ | pgp hdr | IDEA encrypted duress msg | stealthed real msg | noise | +---------+---------------------------+--------------------+--------+ the IDEA block has a length field, but you can increase the length without damage to include the following stealthed stuff as the underlying stuff which is IDEA encrypted will know it's length on decryption, and the following junk will just be discarded. So, Alice and her secret key ring (encrypted) gets nabbed by the Charlie (CoS?), and coerced into divuling her passphrase. And if and when it is noticed that the message was longer than it ought to be (CoS that smart? substitute the NSA and they'd notice for sure), Alice explains away the junk on the end by pointing them to the fact that all of her messages where exactly (say) 16k long, and that she was using a the noise only script, and that the message really is this: +---------+---------------------------+-----------------------------+ | pgp hdr | IDEA encrypted duress msg | noise | +---------+---------------------------+-----------------------------+ Now we come to arguments about why you might want this built-in to PGP. Well it provides plausible deniablity as you have no extra software which might look incriminating unless you managed to dispose of it first, if it comes as stock. Also the 2nd reason for built-in at least for stealth is if it needs good random number source, but as I said, I'm not sure it needs a random no generator. So comments please, this has been around a few times already, but here's the algorithm for manipulating x which is the RSA encrypted component of the header of an RSA+IDEA encrytped PGP message: (this is a description of my implementation of Hal's algorithm as described on his www page: http://www.portal.com/~hfinney/) consider random no x, RSA modulus N 1 < x < N (that used to say 0 <= x < N, but 0, and 1 being RSA fixed points, 0, 1, and N won't be generated by PGP presumably? I think this shouldn't matter as the keyspace of N is so large that the probability of a 0 or a 1 specifically is nothing to worry about I think.) Hal's algorithm was to convert x to being in the range: 0 <= x' < lim where lim which is the next power of 2 above N * 2^surety, and surety is 64, 64 seems big enough? The recover operation is: x = x' mod N and the create operation is: 1) scale = int( (lim-1) / N ) + 1 2) scale2 = 2^int( log2( scale ) + 1) ie scale2 = next power of two over scale 3) r = MD5( 0, x ) ie MD5 digest of x, as x is an RSA encrypted random session key misc other info, and more random padding to bring up to be close to N in size. It strikes me that we already have a random number, and that provided MD5 can not be inverted (which it is not possible, as it is compressing, and looses info, and the brute force to find which of all the possible y's (0 < y < N) MD5 digests come out to be x. I would have thought it likely that this would be evenly distributed, and that the cost would be enormous? 4) r = MD5( r, rand() ) it will fail some of the time, so in this case repeat with another random number, Istirred it in first but perhaps you would only do it if it failed. Or perhaps it is enough to MD5( r, r ) ie stir r into itself to generate another ran no? So long as there are no rare cycles? Presumably either impossible or infinitessimally small probability. 5) r = r mod scale2 6) if (r > scale) goto 4) 4),5) & 6) are designed to generate an evenly distributed random number in the range: 0 <= r <= scale 7) x' = N * r + x 8) if (x' > lim) goto 4) an example, with small numbers, and surety set to 8, x = 7, and manufactoring the ran nos manually: lim = 2^( int( log2(N) + 1 ) + surety ) = 2^( 4 + 8 ) = 4096 1) scale = int( 4096 / 13 ) + 1 = 316 2) scale2 = 2^( int( log2( scale ) ) +1 ) = 2^(8 + 1) = 512 3) say MD5( x ) = 0x00000000000000000000000000001234 4) say MD5( x, rand ) = 0x00000000000000000000000000001235 = 4661 (base 10) 5) r = 4661 mod scale2 = 4661 % 512 = 53 6) if ( 53 > 315 ) - it's not 7) x' = N * r + x = 13 * 53 + 7 = 696 8) if (696 > 4096) - it's not) so x' = 696 reversing: x = x' mod N = 696 mod 13 = 7 when 6) is true, ie r > scale which will happen half the time on avg with the first ran no, and so on like a coin flip, the chances of many coins flipping the wrong way diminishes rapidly with number of flips. when 8) is true, ie x' > lim, x' can only be > than lim when x = N - 1, and given that x = N - 1, the probability is less of x being in N * scale <= x < lim but this will only occur with probability: 1 1 -------- < ----- 2^surety scale I think. So you'd have to collect one mess of messages to even catch one sample, let alone enough messages to have a statistical proof of steganography being present. Pls check the maths a bit, the above describes the software implementation of Hal's algorithm which he has on-line, on his page: http://www.portal.com/~hfinney/ But the main question I'd like to get verification on is if it is safe to use the MD5 of the RSA encrypted message to perform the operation. I'm essentially doing: x' = N * f(MD5(x)) + x where f(y) is a function which converts from range 0 <= y < 2^128 to a range 0 <= f(y) < scale. Is that safe? x is random, and will be different even for a repeat encryption of the same file, as PGP is using a random IDEA session key. So are there any brute force attacks on that which would be cheaper than attacking 128 bit IDEA? PGP's random number generator also makes extensive use of MD5, so I'm taking the use of MD5 as secure as a given. If it is thought to be dangerous for some reason (it is after all some kind of signature on it's self, presume that you know N, and x' but not x, the question is can the equation be brute force reversed in a less than 128 bit brute force attack. I'm neglecting to consider the rand() calls, which I'm not expecting to add security, but are just a mechanism to stir the value with to get more random nos, as occasionally the alogrithm needs more than one, if the first fails, etc. If people reckon it's insecure, then it would be ideal to include the stealth functionality into PGP, so that integral use of PGPs ran no routines can be made. I was previously using an MD5 digest of PGPs randseed.bin for this, but you can't stir it (well you could but that would considered a security risk diddling with PGPs files), and not stirring means you have no improvement over the above, in the event that that your system is captured with the known plaintext. If you stirred it there would be no proof of that being the message in the file. Even unstirred, if the N * f(MD5(x)) + x is no good, the inclusion of a digest of the randseed.bin would be a big improvement. It seems rather messy to have all of the keyboard sampling stuff, for PGP keys duplicated for this. Hope the x' = N * f(MD5(x)) + x construct is secure as this will avoid the issue. Adam

1 0

Re: "Got a subpoena?"
by Jeff Hupp 17 Dec '03

17 Dec '03

On 30 Nov 95 at 12:56, Jay Campbell wrote: : >> "finessing" laws will become more important. In short, they WILL have : >> a subpoena--then what? : > : > Then they'll find out that I don't have any information that : >could help them, anyway. : : What about a court order to (a) start comprehensive logging, and (b) not : tell anyone under penalty of ______ . And at that point, you shut down the remailer and log each and every bounce. Now, they could get an order forcing you to run a remailer ~ but that would open up a whole new can of worms i.e. can you be forced, under court order, to commit a crime? -- JHupp(a)gensys.com |For PGP Public Key: http://gensys.com |finger jhupp(a)gensys.com Autocracy is based on the assumption that one man is wiser than a million men. How's that again? I missed something.

2 1