- cypherpunks-legacy - lists.cpunks.org

Re: University logging mail to anon.penet
by kadie＠eff.org 17 Dec '03

17 Dec '03

stewarts(a)ix.netcom.com (Bill Stewart) writes: [...] >There may be ECPA issues involved, especially if CalPolySLO is a government- >run university; the sysadmins certainly need to learn some ethics... [...] I think the ECPA should apply to private universities, too. The FERPA also applies to virutally all U.S. private universities. - Carl =============== ftp://ftp.eff.org/pub/CAF/faq/email.privacy =============== q: Can (should) my university monitor my email? a: Ethically (and perhaps legally) email communications should have the same privacy protection as telephone calls. It would be unwise for any university employee to tap email communications without authorization from the university president, university legal counsel, and the academic freedom committee. According to Mike Godwin, legal services counsel for the Electronic Frontier Foundation (EFF), the U.S.'s Electronic Communications Privacy Act (ECPA) could be reasonably construed to protect university email. This is also the reported opinion of the U. of Michigan's lawers. Also, the U.S.'s Family Educational Rights and Privacy Act gives students at all public and most private schools some privacy rights. A U.S. government task force says that "[Email] monitoring [of government employees] of actual communications and communicators may impinge on the Constitutional rights of freedom of speech (1st Amendment), against unreasonable search and seizure (4th Amendment), and against self-incrimination (5th amendment), as well as on the right to privacy, specifically as set forth in both the Privacy Act and the ECPA." In the context of libraries, the American Library Association's Policy on Confidentiality of Library Records suggests this procedure to deal with an official or police request for information about users: 'When drafting local policies, libraries should consult with their legal counsel to insure these policies are based upon and consistent with applicable federal, state, and local law concerning the confidentiality of library records, the disclosure of public records, and the protection of individual privacy. Suggested procedures include the following: 1. The library staff member receiving the request to examine or obtain information relating to circulation or other records identifying the names of library users, will immediately refer the person making the request to the responsible officer of the institution, who shall explain the confidentiality policy. 2. The director, upon receipt of such process, order, or subpoena, shall consult with the appropriate legal officer assigned to the institution to determine if such process, order, or subpoena is in good form and if there is a showing of good cause for its issuance. 3. If the process, order, or subpoena is not in proper form or if good cause has not been shown, insistence shall be made that such defects be cured before any records are released. (The legal process requiring the production of circulation or other library records shall ordinarily be in the form of subpoena "duces tecum" [bring your records] requiring the responsible officer to attend court or the taking of his/her deposition and may require him/her to bring along certain designated circulation or other specified records.) 4. Any threats or unauthorized demands (i.e., those not supported by a process, order, or subpoena) concerning circulation and other records identifying the names of library users shall be reported to the appropriate legal officer of the institution. 5. Any problems relating to the privacy of circulation and other records identifying the names of library users which are not provided for above shall be referred to the responsible officer.' - Carl M. Kadie ANNOTATED REFERENCES (All these documents are available on-line. Access information follows.) =================<a href="ftp://ftp.eff.org/pub/CAF/law/ecpa.1986.godwin"> law/ecpa.1986.godwin =================</a> * Privacy -- E-mail -- ECPA - University Site Mike Godwin, legal services counsel for the Electronic Frontier Foundation (EFF), says that the Electronic Communications Privacy Act (ECPA) could be reasonably construed to protect university email. =================<a href="ftp://ftp.eff.org/pub/CAF/law/ferpa.text"> law/ferpa.text =================</a> * Privacy -- Students -- FERPA (Buckley Ammendment) The full text of the Family Educational Right to Privacy Act (Buckley Amendment). =================<a href="http://www.eff.org/CAF/faq/email.policies.html"> faq/email.policies =================</a> * Email -- Policies q: Do any universities treat email and computer files as private? a: Yes, many universities treat email and computer files as private. ... =================<a href="ftp://ftp.eff.org/pub/CAF/library/confidentiality.1.ala"> library/confidentiality.1.ala =================</a> * Confidentiality -- 1 (ALA) The American Library Association's "Policy on Confidentiality of Library Records" Suggests how to handle police or official requests for information about a user. =================<a href="ftp://ftp.eff.org/pub/CAF/library/computer.draft.ala"> library/computer.draft.ala =================</a> * DRAFT: Access to Electronic ... Services and Networks ... (ALA) A draft interpretation by the American Library Association of the "Library Bill of Rights" Says in part: "Libraries and librarians exist to facilitate [freedom of speech and freedom to read] by providing access to, identifying, retrieving, organizing, and preserving recorded expression regardless of the formats or technologies in which that expression is recorded." =================<a href="ftp://ftp.eff.org/pub/CAF/statements/bill-of-rights.aahe"> statements/bill-of-rights.aahe =================</a> * Bill of Rights ... for Electronic ... Learners This is the "Bill of Rights and Responsibilities for the Electronic Community of Learners". It could become the first widely endorsed statement directly related to computers and academic freedom. =================<a href="ftp://ftp.eff.org/pub/CAF/statements/caf-statement"> statements/caf-statement =================</a> * Computer and Academic Freedom Statement -- Draft This is an attempt to codify the application of academic freedom to academic computers. It reflects our seven months of on-line discussion about computers and academic freedom. It covers free expression, due process, privacy, and user participation. Comments and suggestions are very welcome (especially when posted to CAF-talk). All the documents referenced are available on-line. (Critiqued). =================<a href="ftp://ftp.eff.org/pub/CAF/statements/caf-statement.critique"> statements/caf-statement.critique =================</a> * Computer and Academic Freedom Statement -- Draft -- Critique This is a critique of an attempt to codify the application of academic freedom to academic computers. It reflects our seven months of on-line discussion about computers and academic freedom. It covers free expression, due process, privacy, and user participation. Additional comments and suggestions are very welcome (especially when posted to CAF-talk). All the documents referenced are available on-line. =================<a href="ftp://ftp.eff.org/pub/CAF/academic/student.freedoms.aaup"> academic/student.freedoms.aaup =================</a> * Student Freedoms (AAUP) Joint Statement on Rights and Freedoms of Students -- This is the main U.S. statement on student academic freedom. =================<a href="ftp://ftp.eff.org/pub/CAF/academic/speech-codes.aaup"> academic/speech-codes.aaup =================</a> * Speech Codes (AAUP) On Freedom of Expression and Campus Speech Codes Expression - An official statement of the American Association of University Professors (AAUP) It says in part: "On a campus that is free and open, no idea can be banned or forbidden. No viewpoint or message may be deemed so hateful or disturbing that it may not be expressed." =================<a href="ftp://ftp.eff.org/pub/CAF/law/uwm-post-v-u-of-wisconsin"> law/uwm-post-v-u-of-wisconsin =================</a> * Expression -- Hate Speech -- UWM Post v. U Of Wisconsin The full text of UWM POST v. U. of Wisconsin. This recent district court ruling goes into detail about the difference between protected offensive expression and illegal harassment. It even mentions email. It concludes: "The founding fathers of this nation produced a remarkable document in the Constitution but it was ratified only with the promise of the Bill of Rights. The First Amendment is central to our concept of freedom. The God-given "unalienable rights" that the infant nation rallied to in the Declaration of Independence can be preserved only if their application is rigorously analyzed. The problems of bigotry and discrimination sought to be addressed here are real and truly corrosive of the educational environment. But freedom of speech is almost absolute in our land and the only restriction the fighting words doctrine can abide is that based on the fear of violent reaction. Content-based prohibitions such as that in the UW Rule, however well intended, simply cannot survive the screening which our Constitution demands." =================<a href="ftp://ftp.eff.org/pub/CAF/law/gillard-v-schmidt"> law/gillard-v-schmidt =================</a> * Privacy -- School -- Staff Desk -- Gillard v. Schmidt Description of an appellate court ruling that the school board could not search the desk of a school counselor without a warrant. =================<a href="ftp://ftp.eff.org/pub/CAF/law/email.gov-employee"> law/email.gov-employee =================</a> * Privacy -- E-mail -- Government Employees A U.S. government task force: "[Email] monitoring [of government employees] of actual communications and communicators may impinge on the Constitutional rights of freedom of speech (1st Amendment), against unreasonable search and seizure (4th Amendment), and against self-incrimination (5th amendment), as well as on the right to privacy, specifically as set forth in both the Privacy Act and the ECPA." Enclosed are guidelines for legitimate monitoring of government employee email. =================<a href="ftp://ftp.eff.org/pub/CAF/law/mass-student-searches"> law/mass-student-searches =================</a> * Privacy -- Mass Students Searches An excerpt from The ACLU Handbook: _The Rights of Students_, stating that "there must a reasonable suspicion directed specifically at each student before a school official can search students." =================<a href="ftp://ftp.eff.org/pub/CAF/law/constraints.constitutional"> law/constraints.constitutional =================</a> * Constitution -- Public University -- Constraints Comments from _A Practical Guide to Legal Issues Affecting College Teachers_ by Partrica A. Hollander, D. Parker Young, and Donald D. Gehring. (College Administration Publication, 1985). Discusses the constitutional constraints on public universities including the requires for freedom of expression, freedom against unreasonable searches and seizures, due process, specific rules. =================<a href="ftp://ftp.eff.org/pub/CAF/law/ecpa.umich"> law/ecpa.umich =================</a> * Privacy -- E-mail -- ECPA - University Site A summary of a newspaper report that the U. of Michigan's lawyers believe(d) that the institution is barred under the federal Electronic Communications Privacy Act from reading electronic mail. =================<a href="ftp://ftp.eff.org/pub/CAF/law/privacy.email"> law/privacy.email =================</a> * Privacy -- E-mail -- Law -- Hernandez "Computer Electronic Mail and Privacy", an edited version of a law school seminar paper by Ruel T. Hernandez. =================<a href="ftp://ftp.eff.org/pub/CAF/law/privacy.workplace"> law/privacy.workplace =================</a> * Privacy -- Workplace Comments from and about _The new hazards of the high technology workplace_ see (1991) 104 _Harvard Law Review_ 1898. Talks about email and other electronic monitoring. =================<a href="ftp://ftp.eff.org/pub/CAF/law/email.bib"> law/email.bib =================</a> * Privacy -- E-mail -- Bibliography I have been having an e-mail conversation with Stacy Veeder for several days on the topic of e-mail privacy. She mailed me this bibliography which she has compiled for two papers which she is currently writing. I post it here with permission. PS - She is interested in talking with anyone who has some views on the topic/information to share. Mark N. ================= ================= If you have gopher, you can browse the CAF archive with the command gopher gopher.eff.org These document(s) are also available by anonymous ftp (the preferred method) and by email. To get the file(s) via ftp, do an anonymous ftp to ftp.eff.org (192.77.172.4), and then: cd /pub/CAF/law get ecpa.1986.godwin cd /pub/CAF/law get ferpa.text cd /pub/CAF/faq get email.policies cd /pub/CAF/library get confidentiality.1.ala cd /pub/CAF/library get computer.draft.ala cd /pub/CAF/statements get bill-of-rights.aahe cd /pub/CAF/statements get caf-statement cd /pub/CAF/statements get caf-statement.critique cd /pub/CAF/academic get student.freedoms.aaup cd /pub/CAF/academic get speech-codes.aaup cd /pub/CAF/law get uwm-post-v-u-of-wisconsin cd /pub/CAF/law get gillard-v-schmidt cd /pub/CAF/law get email.gov-employee cd /pub/CAF/law get mass-student-searches cd /pub/CAF/law get constraints.constitutional cd /pub/CAF/law get ecpa.umich cd /pub/CAF/law get privacy.email cd /pub/CAF/law get privacy.workplace cd /pub/CAF/law get email.bib To get the file(s) by email, send email to ftpmail(a)decwrl.dec.com Include the line(s): connect ftp.eff.org cd /pub/CAF/law get ecpa.1986.godwin cd /pub/CAF/law get ferpa.text cd /pub/CAF/faq get email.policies cd /pub/CAF/library get confidentiality.1.ala cd /pub/CAF/library get computer.draft.ala cd /pub/CAF/statements get bill-of-rights.aahe cd /pub/CAF/statements get caf-statement cd /pub/CAF/statements get caf-statement.critique cd /pub/CAF/academic get student.freedoms.aaup cd /pub/CAF/academic get speech-codes.aaup cd /pub/CAF/law get uwm-post-v-u-of-wisconsin cd /pub/CAF/law get gillard-v-schmidt cd /pub/CAF/law get email.gov-employee cd /pub/CAF/law get mass-student-searches cd /pub/CAF/law get constraints.constitutional cd /pub/CAF/law get ecpa.umich cd /pub/CAF/law get privacy.email cd /pub/CAF/law get privacy.workplace cd /pub/CAF/law get email.bib -- Carl Kadie -- I do not represent EFF or my employer; this is just me. =Email: kadie(a)eff.org, kadie(a)cs.uiuc.edu = =URL: <http://www.eff.org/CAF/>, <ftp://ftp.cs.uiuc.edu/pub/kadie/> =

1 0

DUF_ibf
by John Young 17 Dec '03

17 Dec '03

Pal has provided a gopher-FBI paper: "Computer Crime Categories: How Techno-criminals Operate." By David L. Carter, a professor in the School of Criminal Justice, Michigan State University Types of Computer Crimes Computer As the Target Computer As the Instrumentality of the Crime Computer Is Incidental to Other Crimes Crimes Associated With the Prevalence of Computers Perspective on Legal Issues Special Problems with Computer-Related Crime Intellectual Property Malfeasance by Computer International Issues Conclusion Criminals have adapted the advancements of computer technology to further their own illegal activities. Unfortunately, their actions have far out-paced the ability of police to respond effectively. DUF_ibf (21 kb in two parts)

1 0

Re: Elliptic Curve Public Key Crypto available
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

Available anywhere outside the escrowed country ?

2 1

Netscape to patch shareware version
by Weld Pond 17 Dec '03

17 Dec '03

This is from the Sept 11, 1995 Inter@ctive Week: Netscape Communications Corp.'s freely distributed browser is getting commercial-grade encryption, making it safe to use in the U.S. The change comes two weeks after Inter@ctive Week disclosed that the free version contained reletively weak encryption that had been cracked by a European user. [...] Meanwhile, in an as yet unannouced move, the company said it would place its commercial browser online for free downloading. THat move apparently comes in direct response to an Inter@ctive Week article that highlighted the fact that all shareware versions of the browser contain the so-called 40-bit key encryption software which was recently proven insecure. THe commercial version, sold only in the U.S. contains an unbreakable 128-bit encryption scheme. Netscape said it received word last week that the State Department had cleared that version for release on the Net, but only within the U.S., owing to current export laws banning the export of encryption schemes stronger than 40 bits. THe company could provide no details by press time on how it would ensure that the 128-bit version wouldn't leak beyond U.S. borders. [end excerpts] I love how Inter@ctive Week pats themselves on the back for making people aware of the problem. I guess the cypherpunk media hacking is working. Doing things behind the scenes and making the press think they are the internet users salvation looks like a good tactic. The cypherpunks forced a situation where Net users now have better encryption available to them. I'd say this is a big win. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio

2 1

Re: DejaNews all over again
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Wed, 8 Nov 1995, Perry E. Metzger wrote: > anonymous-remailer(a)shell.portal.com writes: > > I wish that Detweiler could (seriously) go back to wherever he came from. > > What a fascinating statement to make, considering that you are > probably Detweiler. Fascinating. First, I'm accused of being noted computer viral expert, Dr. Frederick B. Cohen, (simply because he agrees with my assessment of the critical algorithm flaw in Netscape Navigator) and now I'm accused of perhaps being at the other end of the spectrum. Of being Detweiler, simply because he can take my signature and identity by signing an email, as Alice de 'nonymous or simply accusing me of posting in his "style". I see that the character assassination sport continues, and I am now a targetted. Hunter become hunted. I wonder why?? And why, by of all people, Perry? Is it perhaps because, I speak the truth, and the truth makes people very, very nervous. Is it because the flaw which is in the Navigator product is woven into the code fabric, and can't be *fixed*. Afterall, Netscape (and AT&T) have had, over THREE WEEKS to work on this problem or to make some form of public comment, and have done nothing, but put some of their programmers -- unofficially ... speaking for myself ... not speaking for the Company -- programmers on this list Meanwhile people are having their PGP keyrings collected, their passwords monitorred, and all of the information -- even information which they have NOT posted to Usenet, information that is simply on their personal hard drives, or on a private corporate network that is behind a firewall -- collected by anyone who actualy understands *how* to use Netscape Navigator's standard features to do it. And so the question is: Why am I having my character asassinated while this threat continues?? And while the loss and damage continues. Why are Netscape and AT&T not mitigating the damage? Is it because what I say is simple common sense stripped of the veneer of "technical language" and jargon?? And can't be *commented* on or *fixed*. Is this the fear which any truth teller faces, not only on the Internet, but in any forum where they try to challenge Goliath. Maybe, that's one reason to post anonymously. To clear the record definitively, I am neither Detweiler nor Dr. Frederick B. Cohen, and I am not the issue. I am simply myself, and I will _reveal_ my identity to the international public once the timing is appropriate. If anyone wants to know who I am, they can contact the PR department of AT&T or Netscape and ask. (Their address can be requested from either postmaster(a)att.com or postmaster(a)netscape.com, respectively.) Both companies have an email address for me, and would _likely_ *cough* forward any email enquiries to me without any editing. That way, everything is done clearly and out in the open. Nothing hidden, and nothing private, and none of my comments will become "their sole property to be used in their sole discretion". Neither company can accuse me of attacking them with daggers in the dark of night, from behind a shield of anonymity, when I advocate public open disclosure and commentary. Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

2 1

Elliptic Curve Public Key Crypto
by Brian D Williams 17 Dec '03

17 Dec '03

Mike Rosing writes: >in the cypherpunks ftp site /pub/cypherpunks/ciphers are 2 ascii >files. One contains code and the other contains documentation: >eliptic.src and elliptic.doc. The code portion is a cat'ed block >of files: headers, C sources and a set of prime numbers. The >documentation attempts to explain the math, but it does help if >you already know number theory. It hopefully isn't necessary. Thanks Mike for all your effort!! Now could someone remind me where the Cypherpunks FTP site is? Please? Brian D Williams Cypherpatriot " Zen? Well it beats sitting around on your ass all day doing nothing! "

3 2

Re: GAK/weak crypto rationale?
by Andrew.Spring＠ping.be 17 Dec '03

17 Dec '03

>intercepts requested and authorized in the past year. As I recall, the >number was quite small - around 12K [?]. Someone had found this out >through an FOIA request, perhaps, (my recollection of it is poor). It was I think it's about 1200. >not a large number, anyway. I must conclude that the actual number of >intercepts is much, much larger than they are saying, and that they must >be getting what they perceive to be good intel from all this snooping. > A more cautious conclusion would be would be that the importance (to the LEA's) of the busts made with crypto is much larger than the numbers suggest. You could interpret that a lot of ways: I suspect that high-profile career-enhancing cases are highly dependent on wiretaps.

4 4

Re: Elliptic Curve Public Key Crypto available
by Andrew Loewenstern 17 Dec '03

17 Dec '03

> Previous to the availabilty of 100 MHz processors this method of > public key crypto was ridculously slow. The only versions were > laboratory curiosities implemented in ASIC hardware. Code, if it > exists, is not in the public domain. What about NeXT's Fast Elliptic Encryption (FEE)? Their research guy, Richard Crandall, came up with major speedups to elliptic curve encryption. In fact, there was a simple cryptosystem that shipped as a demo with NeXTSTEP 2.0. What was most interesting about this system was that it didn't store any keys anywhere; your public/private key pair was generated _on the fly_ from your passphrase every time you encrypted or decrypted....on a 25mhz 68040 too... and it was fast! It wasn't that great of an implementation (you _really_ need a lot of bits of entropy in that passphrase, and you can't change your passphrase without changing your PK), but it shows how fast NeXT's speedups are. And this was in 1990... I'm not sure if the speedups are patented, but you could try a literature search. If it really is fast then it could mean good things for servers that need to do a lot of enrcyption/decrption for interaction with clients. andrew

2 1

Re: An opportunity not to be missed
by Bill Stewart 17 Dec '03

17 Dec '03

>On Wed, 13 Sep 1995, David C. Lambert wrote: > >> I propose that we get some likely candidate (actually, a similar candidate >> to the one above) to advocate the benefits of anonymity on the net. Is Wavy Gravy running his "Nobody for President" campaign again this time? After all, Nobody's going to balance the budget, and Nobody's going to get the government out of your bedroom, and on the internet, Nobody can tell if you're a dog or not :-) #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

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