December 2003 - cypherpunks-legacy

Re: UK wants to end right to silence
by Ian Turton 17 Dec '03

17 Dec '03

> > I just saw some very disturbing news in a programme (Reportage) on BBC > World Service TV. Apparently there are moves by the Government in Britain > to REPEAL THE RIGHT TO SILENCE. So far, as in the US (5th amend.) if arrested > in Britain you have the right to remain silent but if you wish to say anything > it may be used as evidence against you. Well close - note UK != Britain and even Britain doesn't have an all encompassing legal system. 1) The right to silence has already gone in Northern Ireland (part of the UK) along with jury trial (for terorist trails). The Govt plans to include this provision in the latest Criminal Justice Bill which is certainly for England and Wales but might not affect Scotland (I'm not sure, most of Scots law is different). 2) The right to silence at present means I don't have to say anything when arrested and the prosecution can not mention this to the court even if I come up with some plausible alibi when the case comes to trial. 3) The planned change is to allow the prosecution to mention this silence to the court and allow the jury to draw their own inferences, so the defence that I didn't trust the police not to frame me if I said anything may still be valid (more so if I have an Irish accent). It will still be impossible (well really hard) to convict someone simply because they stayed silent. > > The Government want to repeal the right to silence, obliging those arrested to > give an account AT THE 'SCENE OF CRIME'. A refusal to speak will be taken > as an indication of guilt. not quite - there is some doubt that any jury will believe that the questions where asked at the scene of the crime rather than in the police station infront of a double tape recorder. It is at present an arrestable offence to refuse to give police officers certain information when they ask this includes at least your name and address (there may be more but that was enough for them last time I didn't talk to the police). But in general I doubt that this will work. > > The defendent will also have to give witness in court, even if attorneys > believe that the witness or manner of giving it may be detrimental to the > defendents case. Even the judiciary are upset at this proposal and it is unlikely to make it through to law, especially considering the way the House of Lords have taken the Police and Magistrates Bill (a related bill) to pieces this month. The judges are upset since they will have to ask the defendant questions and are not at alll sure what they can do if he refuses to answer. > > Of course, libertarians are strongly against this, etc. But that it could > come about at all in Britain, is an indication of the powerful backlash of > the Right, whether with "Back to basics," "Family values," capital punishment > (in the US), or other reactions to crime that are nothing short of extremist, > however widespread "social decay" may be perceived to be by a generation that > can't understand the society to come. Ah well they say we must get tough on terrorists (and remember that unlike the US we have terrorists in the UK) and while we're at it we will catch more criminals, which is the best way to measure police efficiency, and any way if you're inoccent you've nothing to fear. > ----------------------------------------------------------------------- > Rishab Aiyer Ghosh "What is civilisation > rishab(a)doe.ernet.in, rishab(a)dxm.ernet.in but a ribonucleic > Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" > H-34C Saket New Delhi 110017 INDIA > ----------------------------------------------------------------------- > all in all its bad but the general public love the idea and they have the votes :-( Ian Turton - School of Geography, Leeds University 0532 -333309

1 0

Guardian Article on Clipper
by Dave Banisar 17 Dec '03

17 Dec '03

The Guardian (UK) March 3, 1994, Page 17 Are These Men A Threat To Free Speech? US law enforcement agencies want to decode 'secret' electronic mail, prompting a furious row about citizens' rights by Mike Holderness With modern communications systems you can send letters, orders and memos around the world in minutes. But you don't want your competitors, or their governments, siphoning the details of your bid for that dam contract in the Far East out of the Internet. So what do you do? And when you receive an electronic message announcing you've won the deal, how do you know it's genuine? It's possible to fake electronic mail: you must worry about the possibilities for creative industrial espionage this opens up. Then again, you might be a Cabinet minister, setting up a meeting with your boyfriend on the mobile phone. Wouldn't it be good to know that no one could tap the message? The answer to all these problems lies in encryption technology. The solution the US government proposed earlier this month, however, has generated a furious row in the on-line world about government interference in citizens' right to communicate in private. The disturbing implications for people outside the US have gone largely unremarked. Computer programs that can do practically unbreakable encryption are available to the public in the US and elsewhere. One, named PGP for Pretty Good Privacy, is increasingly used to authenticate electronic messages (Computer Guardian, November 25, 1993). It can encrypt the whole message, or send the main text "in clear", followed by an encrypted block containing a mathematical "fingerprint" of the message and the sender's name and address. The program can thus verify whether a signature belongs to the purported sender and whether the message arrives as it left. This worries law-enforcement agencies. What if drug dealers and terrorists start using unbreakable encryption? The US government's Key Escrow Encryption system - commonly known by its working title, Clipper - is its answer. Clipper uses an encryption chip suitable for building into a mobile phone or a modem. Its method of encryption, developed by the US National Security Agency (NSA), depends on "keys" - codes used mathematically to mangle the text or speech. The recipient can only get the original back if they have the key and can use it to un-mangle - decrypt - the message. PGP depends on a "public-key" system. Users sending signed messages encrypt the signature with keys known only to them. They also issue public keys, which are mathematically derived from the private key, and allow anyone to verify the signature. If someone sends them a message encrypted with their public key, only the private key will extract it. By contrast, each Clipper chip will have an encryption key built in. When the chip is manufactured, two parts of the key will be lodged with two separate US government agencies. (In legal jargon, this is like "holding the keys in escrow".) A secret "super-key" allows law enforcement agencies to retrieve the serial number of the chip used on the link they're tapping. Under US guidelines released last month, if a law enforcement agency wants to eavesdrop on encrypted communications it should send details of a search warrant to the agencies holding the key components. This is a red rag to the inhabitants of Internet discussion forums, the world's largest functioning anarchy. There, discussions of the right (under the First Amendment to the Constitution) to unrestricted free speech can and do slip effortlessly into the belief that, as one participant put it, "The people must be allowed to discuss anything, including revolution." According to Brian Yoder, president of California company Networxx, "The US Constitution doesn't grant the government the power to maintain this kind of surveillance capability over the population. Period. The assumption is that anything that enhances the ability of the police to catch criminals is OK, but that is not what the Constitution says, and that's not the kind of country I want to live in." Cryptology specialist Dr Dorothy Denning at Georgetown University was part of a team reviewing the NSA's design process. She points out that Clipper "will not make it any easier to tap phones, let alone computer networks. All it will do is make it possible to decrypt communications that are encrypted with the standard, assuming the communications are not super-encrypted with something else. Law enforcers still need to get a court order." But who trusts the NSA? The Clipper design is secret. Many assume the Agency has built in a "trap-door" allowing it to break encryption without the keys. No one has proposed making non-Clipper encryption illegal, but the US government clearly hopes to establish it as an industry standard. For example, while it's usually illegal to export any form of encryption technology from the US, it will be legal to export Clipper. However, non-US companies using it to protect their communications will have to live with the uneasy knowledge that the NSA could be listening in - and the NSA, like its UK sibling organisation GCHQ in Cheltenham, has a long history of intercepting foreign commercial messages for the benefit of home companies. (GCHQ declined to say whether it had been involved in any discussions over Clipper.) The protests have started. A petition organised by Computer Professionals for Social Responsibility against Clipper, and in favour of a Bill to permit export of competing encryption systems, gathered more than 20,000 electronic signatures in its first two weeks. Wired magazine has proclaimed, "This is a pivotal moment in history", accusing "the Clinton-Gore administration" of "attempting a stealth strike on our rights". It has asked readers to sign the CPSR petition and "call or write your Congressional representatives and let them know how you feel." Encryption and authentication are important for much more than the privacy of the frequently obscure or banal discussions on the Internet. Medical and financial records are now commonly held on computers, and a growing proportion of business transactions take place on-line. Cyberspace is where your money is. For private communications, Emma Nicholson MP takes a relaxed view: "In communicating, we should start from a belief that everyone listens to everything. Gossip is what makes the world go round. I have very few secrets. I would be deeply concerned if a device were marketed that could stop interception - I would support the FBI completely." Computer-law barrister Alistair Kelman, however, believes any attempt to enforce the Clipper chip as a worldwide standard would meet stiff opposition. The European Commission could be expected to object that it fell foul of Treaty of Rome provisions against misuse of a dominant position. "If you want to have a world standard for encryption, fine," Kelman said, but the EC could respond, "Let's get together and settle on something that meets our requirements as well."

1 0

reply-to feeds an anon pool, jpp=pr0duct=cypher
by jpp＠markv.com 17 Dec '03

17 Dec '03

I have built an 'easy anonymous reply' program. You can now use reply-to addresses of the form jpp=0x123456(a)markv.com, where 0x123456 is a public key id. The obvious advantages are 'easy' reply-to's, no stored return address of any kind, and automatic encryption. The obvious disadvantages are the need to scan through alt.test for messages, that I have a list of all the 'bad' folks out there who want anonymous addresses (though it is not clear how terible it is for me to have a list of their public keys), and that I keep logs of the mail messages. My logs will be kept until I am sure the stuff works, and then I will junk'em. So encrypt, and use remailers if you need to -- I won't try to stop a government search of my disk. As a 'prop' to Pr0duct Cypher, I have a special hack that will send mail addressed to jpp=pr0duct=cypher(a)markv.com to alt.test encrypted with that famous CypherPunk's public key. (And as a courtesy to you all, I allow you to spell the address in any case, and with the letter oh instead of the digit 0 if you want.) I might sell similar addresses for digicash -- send me mail with a bid if you are interested. Below is the help file you would get if you mailed to jpp=poolhelp(a)markv.com. Try it out... Jay Prime Positive's mail pool service. If you send mail to jpp=0x123456(a)markv.com, my program will look up the key matching 0x123456 on my 'pool' key ring. If it finds a matching key, it will encrypt the whole message (including headers) with that key. Then it will post the result to alt.test with a subject line matching 'Ignore 0x123456 blah blah blah' where blah blah blah is the key's 'identifier.' My mail program will be run for any address which begins jpp=0x, so you can only use PGP keyid's. As a result, my program won't let you use a key if the key id is already in use. See below. To add a key to the 'pool' key ring, send mail to jpp=poolnew, the body of the message should contain the public key in pgp format. If the key has a 0x123456 key id which is the same as a key already on the keyring, my program will send a message by reply mail, and post a message to alt.test, which has a subject 'Ignore jpp=poolnew key already in use', and a body mentioning the key clash. It will also post using the clashed with key, the same thing, encrypted for the 'legitamite' user of that key with all your mail information, so that they can talk to you about the problem. I will reward you if you can show me that you have managed to 'steal' a 0x123456 key id -- if you can get yours added to my 'pool' keyring, even though there is already one there. I will reward you more highly if you tell me how to fix the problem. To remove your key from the keyring, send a signed message (in simple english, spanish, or esperanto) asking me to remove your key. Send the mail to jpp=poolmaster(a)markv.com. For any other request, send mail to jpp=poolmaster(a)markv.com (in english, or very simple spanish or esperanto). If you want to improve this help message, send a copy to jpp=poolmaster(a)markv.com, and I will (probably) replace this message with yours. For now, and untill I am sure this code is debuged, I will keep comprehensive logs of the running of my code. Use remailers, and encryption as you think apropriate. All bets are off until I announce this service as operational -- all service you get before that date is accidental (on my part). j' -- O I am Jay Prime Positive jpp(a)markv.com 1250 bit fingerprint B06229 = B8 95 E0 AF 9A A2 CD A5 89 C9 F0 FE B4 3A 2C 3F 524 bit fingerprint 2A915D = 8A 7C B9 F2 D5 46 4D ED 66 23 F1 71 DE FF 51 48 Public keys via `finger jpp(a)markv.com', or via email to pgp-public-keys(a)io.com Your feedback is welcome directly or via my symbol JPP on hex(a)sea.east.sun.com Resist the Clipper Chip, write "I oppose Clipper" to Clipper.petition(a)cpsr.org

1 0

How to do encrypted telnet without being root (tutorial, includes src)
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

People have been talking about encrypted telnets for ages, but I still haven't seen one I can easily use. And most suggestions would actually require a sysadmin to install a special telnet daemon. Here's a suggestion for how to do encrypted telnet sessions *without* any system code. It's quite simple - there's a process called 'remote' which sits between your keyboard/screen and the actual machine you're using. Very much like the way the 'script' program works, or perhaps 'screen' (though the latter is much much more complex than script). 'remote' encrypts all screen output. Next, there's a program called 'local'; you run local on your directly- connected local host. Normally local is transparent, and works again pretty much like 'script' (except of course there's no logging :-) ); however when local sees a certain magic string has been printed, it then assumes the data following will be encrypted, and it decrypts everything that's sent to your screen. (This 'in band' data is a little unclean, but it's what makes the whole scheme possible in user-level code) Actually it's *slightly* more complicated than this; when local sees the magic string, it starts up a conversation with whatever it's running on top of, and does some sort of key exchange to use with the encryption. (This conversation works by looking at the data that would otherwise be sent to the screen, and replying by simulating data as if it had been typed) I took two hours last night to actually hack up a version of these programs - the hack uses rot13 as its encryption method, and the key exchange is completely bogus. But it does show the method in action, and it wouldn't take much to adapt this to use a real encryption function. Left as the proverbial exercise for the reader. So, in summary... % local % telnet remotehost # (one that lets you log in with a 1-time password?) % remote Here's an actual log of such a session. I run the remote program first just to show you that the encryption does something - the process is so transparent that you might not follow it otherwise :-) Anyway, the point of this mechanism is that - like pgp - it is *user* code that you can take with you anywhere; you don't need the co-operation of the sys admins at each pair of sites you use. If anyone wants to take this ball and run with it to produce something that's a little more secure than rot13, be my guest. The only copyright here is the Berkeley one attached to the original 'script' source. Once you've got the idea, you might consider rewriting that bit from scratch too. G Script started on Fri Mar 4 10:44:32 1994 suilven% cd src/utel suilven% ./remote | Start encrypted session REMOTE: Asking local to start an encrypted session | [%MAGIC-PGP-START-SESSION%] | Expects a typed actually this stuff doesnt matter | key-exchange [%I-REPLY%] | wibble-wobble/actually this stuff doesnt matter | - this is clearly [%WHAT-DO-YOU-SAY?%] | a dummy exchange nothing really | [%FAIR-ENOUGH-ANYTHING-ELSE?%] | this is a dummy key exchange | [%THANK-YOU%] | fhvyira% cjq | % pwd /hfe/ubzr/tgbny/fep/hgry | fhvyira% | ^D [%ZNTVP-CTC-RAQ-FRFFVBA%] | 'end of session' message suilven% suilven% ./local LOCAL: I'll switch to encrypted mode when someone talks to me! suilven% telnet localhost Trying 127.0.0.1... Connected to localhost.an-teallach.com. Escape character is '^]'. BSDI BSD/386 1.0 (suilven.an-teallach.com) (ttyp8) | We're now running | over a telnet link login: gtoal Password: BSDI BSD/386 1.0 Kernel #6: Wed Oct 6 11:42:35 GMT 1993 pgp password: suilven% cd src/utel suilven% ./remote | start encryptor, do REMOTE: Asking local to start an encrypted session | key exchange (hidden) [%MAGIC-PGP-START-SESSION%] | local notices this rune suilven% echo Not obvious, but this is an encrypted telnet... Not obvious, but this is an encrypted telnet... suilven% | ^D, end encryption [%MAGIC-PGP-END-SESSION%] | local spots this magic suilven% logout | string and stops decrypt Connection closed by foreign host. | now a ^D to end local suilven% LOCAL: Done. (I won't be looking for encrypted output any more...) suilven% Script done on Fri Mar 4 10:46:24 1994 And for your edification, here's the code. (bsd systems only - tested on BSDI and 386BSD) *BIG NOTE*... there are (ahem) one or two rather hacky bits in here. As I said, it was a two-hour hack just to prove the point that code like this can be written easily and it doesn't take a systems manager to install it. (Also, being code you compile yourself, you might trust it a little more). Noticably the rot13 encryption neatly allows me to avoid problems sending binary data. Doing this for real, your output to screen/read from output stream code should encode each encrypted byte as two hexascii bytes for portability; also a few newlines here and there to keep the buffers flushed wouldn't hurt. And there's a *filthy* piece of code to do keyboard stuffing in here. This is *not* how you'd do it in a production program. A security hole a mile wide. I couldn't be bothered learning how to do internal pipes for this quick proof-of-concept hack, so I used a file in /tmp to communicate through... *BIG NOTE #2* This only does screen output; keyboard input is also left as a trivial exercise to the reader... # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # Makefile # local.c # remote.c # echo x - Makefile sed 's/^X//' >Makefile << 'END-of-Makefile' Xall: remote local X echo All up to date X Xremote: remote.c X cc -o remote remote.c X Xlocal: local.c X cc -o local local.c END-of-Makefile echo x - local.c sed 's/^X//' >local.c << 'END-of-local.c' X/* X This is a trivial (2 hour) hack to the 'script' command X to show the general principle involved in hacking up a user-level X encrypted telnet equivalent. This particular hack uses 'rot13' X as its 'encryption'; feel free to make it (ahem) more robust. X */ X X/* X X X +---------+ +----------+ +-------------------+ Xkeyboard---->| |----->| |----->|-\ | X | local | | remote | | | remote process | X vdu<----| |<-----| |<-----|-/ | X +---------+ ^ +----------+ +-------------------+ X | X | X This line may include a telnet session... X X*/ X X/* X * Copyright (c) 1980 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#ifndef lint Xchar copyright[] = X"@(#) Copyright (c) 1980 Regents of the University of California.\n\ X All rights reserved.\n"; X#endif /* not lint */ X X#ifndef lint Xstatic char sccsid[] = "@(#)script.c 5.13 (Berkeley) 3/5/91"; X#endif /* not lint */ X X/* X * script X */ X#include <unistd.h> X#include <sys/types.h> X#include <sys/stat.h> X#include <termios.h> X#include <sys/ioctl.h> X#include <sys/time.h> X#include <sys/file.h> X#include <sys/signal.h> X#include <stdlib.h> X#include <stdio.h> X#include <string.h> X#include <errno.h> X#include <stdarg.h> X#include <paths.h> X Xchar *shell; Xint master; Xint slave; Xint child; Xint subchild; Xchar *fname; X Xstruct termios tt; Xstruct winsize win; Xint lb; Xint l; Xchar line[] = "/dev/ptyXX"; Xint aflg; X X Xstatic int debug = 0; X X#define NULLFILE "/dev/null" X#define LOGFILE "utel.log" X Xstatic int suppress_debug = (0!=0); X Xstatic void debugf(char *s, ...) { Xstatic int checked = 0; Xint string_length; XFILE *nullfile; XFILE *errfile; Xstatic char buff[256]; Xva_list ap; X if (checked == 0) { checked = 1; X /* Only want to log if logfile exists already... */ X errfile = fopen(LOGFILE, "r"); X suppress_debug = (errfile == NULL); X if (errfile != NULL) fclose(errfile); X } X X nullfile = fopen(NULLFILE, "w"); X if (nullfile == NULL) { X errfile = fopen(LOGFILE, "a"); X if (errfile != NULL) { X fprintf(errfile, "Major error - cannot open %s\n", NULLFILE); X fflush(errfile); X fclose(errfile); X } X exit(1); X } X X va_start(ap, s); X string_length = vfprintf(nullfile, s, ap); X if (string_length < 126) { X vsprintf(buff, s, ap); X } else { X sprintf(buff, "[%d char debugf string excised]\n", string_length); X } X va_end(ap); X X fclose(nullfile); X X if (suppress_debug) return; X errfile = fopen(LOGFILE, "a"); X if (errfile != NULL) { X fprintf(errfile, "%s", buff); X fflush(errfile); X fclose(errfile); X } X} X X X Xint session_started = (0!=0); X X#define STATE_SIZE 128 Xtypedef struct cypherstate { X char whatever[STATE_SIZE]; X long int byteno; X /* Add useful stuff here as need be... */ X} CYPHER_STATE; X Xvoid new_cypher(CYPHER_STATE *s) X{ X int i; X /* Random mockup code as a placeholder... */ X for (i = 0; i < STATE_SIZE; i++) { X s->whatever[i] = 0; X } X s->byteno = 0L; X} X X#define MAX_KEYLINELEN 4096 X/* Need to hack this to allow for errors... */ X Xstatic void getline(int masterfd, char *answer) X{ Xchar *s; Xint i; Xint rc; Xchar c; X i = 0; X s = answer; X for (;;) { X rc = read(masterfd, &c, 1); X if (rc != 1) continue; X if (c == '\r') continue; X if (c == '\n') break; X i += 1; X if (i == MAX_KEYLINELEN) { X fprintf(stderr, "Protocol failure - line too long\n"); X break; X } X *s++ = c; X } X *s = '\0'; X} X Xvoid expect(int masterfd, char *line) X{ Xstatic char answer[MAX_KEYLINELEN]; X answer[0] = '\0'; X getline(masterfd, answer); X debugf("Expect: Want '%s', Got '%s'\n", line, answer); X if (strcmp(line, answer) != 0) { X /*fprintf(stderr, "\r\nProtocol failure - wanted '%s' - got '%s'\r\n", X line, answer); X fflush(stderr);*/ X return; X } X /*fflush(stderr);*/ X} X Xvoid faketype(char *s) X{ X /* Ask out other half to send this text as if it had been typed. */ X FILE *hack; X debugf("faketype: sending '%s'\n", s); X hack = fopen("/tmp/typeme", "r"); X if (hack != NULL) { X char *ptr; X char tmp[128]; X fgets(tmp, 127, hack); X ptr = strchr(tmp, '\n'); X if (ptr != NULL) *ptr = '\n'; X fprintf(stderr, "Oops - last line (%s) not sent yet!\n", tmp); X fclose(hack); X return; X } X hack = fopen("/tmp/typeme.tmp", "w"); X if (hack == NULL) { X fprintf(stderr, "Can't faketype to /tmp/typeme\n"); X return; X } X fprintf(hack, "%s\n", s); X fclose(hack); X rename("/tmp/typeme.tmp", "/tmp/typeme"); X} X X/* This procedure is invoked at a random time in the middle X of a session of 'local' when the MAGIC-PGP-START-SESSION X string is recognised as just having been printed... */ Xvoid NEGOTIATE_SESSION_KEYS( X int masterfd, FILE *out, X CYPHER_STATE *outkey, CYPHER_STATE *inkey) X{ Xstatic char keyline[MAX_KEYLINELEN]; Xchar *ptr; X X new_cypher(outkey); X new_cypher(inkey); X /* Engage in a conversation with the program at the other X side to negotiate a session key. How you do this is X up to you. */ X faketype("Hello big boy!"); expect(masterfd, "Hello big boy!"); X /* At this point, the other half *must* poll the file and X send the data or we're in trouble */ X expect(masterfd, "[%I-REPLY%]"); X getline(masterfd, keyline); X expect(masterfd, "[%WHAT-DO-YOU-SAY?%]"); X faketype("Nice weather..."); expect(masterfd, "Nice weather..."); X expect(masterfd, "[%FAIR-ENOUGH-ANYTHING-ELSE?%]"); X faketype("Thank you for calling <beep>"); X expect(masterfd, "Thank you for calling <beep>"); X expect(masterfd, "[%THANK-YOU%]"); X session_started = (0==0); X} X XCYPHER_STATE outstate, instate; X Xchar rot13(char c) X{ Xreturn(isalpha(c) ? ((c > (islower(c) ? 'z' : 'Z')-13) ? c - 13 : c + 13) : c); X} X Xchar decrypt_stream_cypher(CYPHER_STATE *s, char byte) X{ X return(rot13(byte)); /* bwahahahaha! */ X} X Xvoid ENCRYPT_KEYBOARD_INPUT(char *buff, int count) X{ X /* First iteration - keyboard input in clear, X only screen output to be encrypted */ X} X Xvoid DECRYPT_SCREEN_OUTPUT(char *buff, int count) X{ X int i; X if (session_started) { X for (i = 0; i < count; i++) { X buff[i] = decrypt_stream_cypher(&outstate, buff[i]); X } X } X} X Xint scanfor_start(int masterfd, char c) X{ X#define MAGIC "[%MAGIC-PGP-START-SESSION%]" X#define MAGICLEN strlen(MAGIC) Xstatic char *buffer = NULL; Xstatic int nextfree = 0; X c &= 127; X if (c == 13) return(0!=0); X /* An expensive hack, but who cares... */ X if (buffer == NULL) { X buffer = malloc(MAGICLEN+1); X memset(buffer, ' ', MAGICLEN-1); X buffer[MAGICLEN] = '\0'; X } X if (c == '\n') { X if (memcmp(buffer, MAGIC, MAGICLEN) == 0) { X NEGOTIATE_SESSION_KEYS(masterfd, stdout, &outstate, &instate); X /*printf("LOCAL: starting session\r\n");*/ X return(0==0); X } X } X memmove(buffer, buffer+1, MAGICLEN-1); X buffer[MAGICLEN-1] = c; X#undef MAGIC X#undef MAGICLEN X return(0!=0); X} X Xvoid scanfor_end(int masterfd, char c) X{ X#define MAGIC "[%MAGIC-PGP-END-SESSION%]" X#define MAGICLEN strlen(MAGIC) Xstatic char *buffer = NULL; Xstatic int nextfree = 0; X c &= 127; X if (c == 13) return; X /* An expensive hack, but who cares... */ X if (buffer == NULL) { X buffer = malloc(MAGICLEN+1); X memset(buffer, ' ', MAGICLEN-1); X buffer[MAGICLEN] = '\0'; X } X if (c == '\n') { X if (memcmp(buffer, MAGIC, MAGICLEN) == 0) { X /*printf("LOCAL: starting session\r\n");*/ X session_started = (0!=0); X /* Go quiescent again. Maybe it would be better X to exit the local program entirely??? */ X } X } X memmove(buffer, buffer+1, MAGICLEN-1); X buffer[MAGICLEN-1] = c; X#undef MAGICLEN X#undef MAGIC X} X Xint filter_incoming_text(int masterfd, char *s, int len) X{ Xint i; Xint rc; X /* Watch the incoming stream for the magic string that X denotes the start of a key exchange; when it's detected, X do a key exchange, and enable decryption of the session */ X rc = (0!=0); X for (i = 0; i < len; i++) { X if (scanfor_start(masterfd, s[i])) { X rc = (0==0); X } X } X return(rc); X} Xvoid filter_outgoing_text(int masterfd, char *s, int len) X{ Xint i; X /* Watch the incoming stream for the magic string that X denotes the start of a key exchange; when it's detected, X do a key exchange, and enable decryption of the session */ X for (i = 0; i < len; i++) { X scanfor_end(masterfd, s[i]); X } X} X X X Xmain(argc, argv) X int argc; X char *argv[]; X{ X extern char *optarg; X extern int optind; X int ch; X void finish(); X char *getenv(); X X while ((ch = getopt(argc, argv, "a")) != EOF) X switch((char)ch) { X case 'a': X aflg++; X break; X case '?': X default: X fprintf(stderr, "usage: script [-a] [file]\n"); X exit(1); X } X argc -= optind; X argv += optind; X X shell = getenv("SHELL"); X if (shell == NULL) X shell = _PATH_BSHELL; X X getmaster(); X printf("LOCAL: I'll switch to encrypted mode when someone talks to me!\n"); X X fixtty(); X X (void) signal(SIGCHLD, finish); X child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child == 0) { X subchild = child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child) X dooutput(); X else X doshell(); X } X doinput(); X} X Xdoinput() X{ X register int cc; X char ibuf[BUFSIZ]; X X char fakeline[MAX_KEYLINELEN]; X FILE *hack; X char *ptr; X X fd_set fds; X struct timeval t; X X for (;;) { X timerclear(&t); X t.tv_sec = 1; /* No more than 1 sec without polling faketype */ X FD_ZERO(&fds); X FD_SET(0, &fds); X X cc = select(1, &fds, NULL, NULL, &t); X if (cc == -1) { X /* select error */ X } X if (cc == 0) { X /* timeout */ X } X if (cc > 0) { X cc = read(0, ibuf, BUFSIZ); X /* cc should be > 0 */ X if (cc > 0) { X ENCRYPT_KEYBOARD_INPUT(ibuf, cc); X (void) write(master, ibuf, cc); X } X } X hack = fopen("/tmp/typeme", "r"); X if (hack != NULL) { X ptr = fgets(fakeline, MAX_KEYLINELEN, hack); X (void)write(master, fakeline, strlen(fakeline)); X fclose(hack); X remove("/tmp/typeme"); X } X } X done(); X} X X#include <sys/wait.h> X Xvoid Xfinish() X{ X union wait status; X register int pid; X register int die = 0; X X while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0) X if (pid == child) X die = 1; X X if (die) X done(); X} X Xdooutput() X{ X time_t tvec, time(); X char obuf[BUFSIZ], *ctime(); X int cc; X int rc; X X (void) close(0); X tvec = time((time_t *)NULL); X X for (;;) { X cc = read(master, obuf, sizeof (obuf)); X if (cc <= 0) break; X rc = filter_incoming_text(master, obuf, cc); X if (!rc) DECRYPT_SCREEN_OUTPUT(obuf, cc); X (void) write(1, obuf, cc); X filter_outgoing_text(master, obuf, cc); X } X done(); X} X Xdoshell() X{ X int t; X X /*** X t = open(_PATH_TTY, O_RDWR); X if (t >= 0) { X (void) ioctl(t, TIOCNOTTY, (char *)0); X (void) close(t); X } X ***/ X getslave(); X (void) close(master); X (void) dup2(slave, 0); X (void) dup2(slave, 1); X (void) dup2(slave, 2); X (void) close(slave); X execl(shell, "sh", "-i", 0); X perror(shell); X fail(); X} X Xfixtty() X{ X struct termios rtt; X X rtt = tt; X cfmakeraw(&rtt); X rtt.c_lflag &= ~ECHO; X (void) tcsetattr(0, TCSAFLUSH, &rtt); X} X Xfail() X{ X X (void) kill(0, SIGTERM); X done(); X} X Xdone() X{ X time_t tvec, time(); X char *ctime(); X X if (subchild) { X tvec = time((time_t *)NULL); X (void) close(master); X } else { X (void) tcsetattr(0, TCSAFLUSH, &tt); X printf("LOCAL: Done. (I won't be looking for encrypted output any more...)\n"); X } X exit(0); X} X Xgetmaster() X{ X char *pty, *bank, *cp; X struct stat stb; X X pty = &line[strlen("/dev/ptyp")]; X for (bank = "pqrs"; *bank; bank++) { X line[strlen("/dev/pty")] = *bank; X *pty = '0'; X if (stat(line, &stb) < 0) X break; X for (cp = "0123456789abcdef"; *cp; cp++) { X *pty = *cp; X master = open(line, O_RDWR); X if (master >= 0) { X char *tp = &line[strlen("/dev/")]; X int ok; X X /* verify slave side is usable */ X *tp = 't'; X ok = access(line, R_OK|W_OK) == 0; X *tp = 'p'; X if (ok) { X (void) tcgetattr(0, &tt); X (void) ioctl(0, TIOCGWINSZ, X (char *)&win); X return; X } X (void) close(master); X } X } X } X fprintf(stderr, "Out of pty's\n"); X fail(); X} X Xgetslave() X{ X X line[strlen("/dev/")] = 't'; X slave = open(line, O_RDWR); X if (slave < 0) { X perror(line); X fail(); X } X (void) tcsetattr(slave, TCSAFLUSH, &tt); X (void) ioctl(slave, TIOCSWINSZ, (char *)&win); X (void) setsid(); X (void) ioctl(slave, TIOCSCTTY, 0); X} END-of-local.c echo x - remote.c sed 's/^X//' >remote.c << 'END-of-remote.c' X/* X This is a trivial (2 hour) hack to the 'script' command X to show the general principle involved in hacking up a user-level X encrypted telnet equivalent. This particular hack uses 'rot13' X as its 'encryption'; feel free to make it (ahem) more robust. X */ X X/* X * Copyright (c) 1980 Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#ifndef lint Xchar copyright[] = X"@(#) Copyright (c) 1980 Regents of the University of California.\n\ X All rights reserved.\n"; X#endif /* not lint */ X X#ifndef lint Xstatic char sccsid[] = "@(#)script.c 5.13 (Berkeley) 3/5/91"; X#endif /* not lint */ X X/* X * script X */ X#include <unistd.h> X#include <sys/types.h> X#include <sys/stat.h> X#include <termios.h> X#include <sys/ioctl.h> X#include <sys/time.h> X#include <sys/file.h> X#include <sys/signal.h> X#include <stdio.h> X#include <string.h> X#include <paths.h> X X#define MAX_KEYLINELEN 4096 X Xchar *shell; Xint master; Xint slave; Xint child; Xint subchild; Xchar *fname; X Xstruct termios tt; Xstruct winsize win; Xint lb; Xint l; Xchar line[] = "/dev/ptyXX"; Xint aflg; X X X#define STATE_SIZE 128 Xtypedef struct cypherstate { X char whatever[STATE_SIZE]; X long int byteno; X /* Add useful stuff here as need be... */ X} CYPHER_STATE; X Xvoid new_cypher(CYPHER_STATE *s) X{ X int i; X /* Random mockup code as a placeholder... */ X for (i = 0; i < STATE_SIZE; i++) { X s->whatever[i] = 0; X } X s->byteno = 0L; X} X Xstatic void getline(FILE *in, char *answer) X{ Xchar *s; Xint i; Xint rc; Xchar c; X i = 0; X s = answer; X for (;;) { X c = fgetc(in); X if (c == '\r') continue; X if (c == '\n') break; X i += 1; X if (i == MAX_KEYLINELEN) { X fprintf(stderr, "Protocol failure - line too long\n"); X break; X } X *s++ = c; X } X *s = '\0'; X} X X Xvoid NEGOTIATE_SESSION_KEYS( X FILE *in, FILE *out, X CYPHER_STATE *outkey, CYPHER_STATE *inkey) X{ Xstatic char keyline[MAX_KEYLINELEN]; Xchar *ptr; X X new_cypher(outkey); X new_cypher(inkey); X /* Engage in a conversation with the program at the other X side to negotiate a session key. How you do this is X up to you. */ X fprintf(out, "REMOTE: Asking local to start an encrypted session\n"); X fprintf(out, "[%%MAGIC-PGP-START-SESSION%%]\n"); /* Detected by finite-state mc */ X /* (what I don't understand is why the line above comes out on X the user's display, encrypted) */ X /* The fgets below comes from data that 'local' fakes as if it had X been typed at the keyboard. */ X strcpy(keyline, "AAA"); X getline(in, keyline); X ptr = strchr(keyline, '\n'); if (ptr != NULL) *ptr = '\0'; X fprintf(out, "[%%I-REPLY%%]\n"); X fprintf(out, "wibble-wobble/%s\n", keyline); X fprintf(out, "[%%WHAT-DO-YOU-SAY?%%]\n"); X strcpy(keyline, "BBB"); X getline(in, keyline); X fprintf(out, "[%%FAIR-ENOUGH-ANYTHING-ELSE?%%]\n"); X strcpy(keyline, "CCC"); X getline(in, keyline); X fprintf(out, "[%%THANK-YOU%%]\n"); X} X XCYPHER_STATE outstate, instate; X Xchar rot13(char c) X{ Xreturn(isalpha(c) ? ((c > (islower(c) ? 'z' : 'Z')-13) ? c - 13 : c + 13) : c); X} X Xchar stream_cypher(CYPHER_STATE *s, char byte) X{ X return(rot13(byte)); /* bwahahahaha! */ X} X Xvoid DECRYPT_KEYBOARD_INPUT(char *buff, int count) X{ X /* First iteration - keyboard input in clear, X only screen output to be encrypted */ X} X Xvoid ENCRYPT_SCREEN_OUTPUT(char *buff, int count) X{ X int i; X for (i = 0; i < count; i++) { X buff[i] = stream_cypher(&outstate, buff[i]); X } X} X Xmain(argc, argv) X int argc; X char *argv[]; X{ X extern char *optarg; X extern int optind; X int ch; X void finish(); X char *getenv(); X X while ((ch = getopt(argc, argv, "a")) != EOF) X switch((char)ch) { X case 'a': X aflg++; X break; X case '?': X default: X fprintf(stderr, "usage: script [-a] [file]\n"); X exit(1); X } X argc -= optind; X argv += optind; X X shell = getenv("SHELL"); X if (shell == NULL) X shell = _PATH_BSHELL; X X getmaster(); X /* This session is negotiated before we do the complicated X stuff with the two processes... Anything we send to the X screen can be trapped by 'local', and local's replies X will appear to be typed at the keyboard... */ X NEGOTIATE_SESSION_KEYS(stdin, stdout, &outstate, &instate); X fixtty(); X X (void) signal(SIGCHLD, finish); X child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child == 0) { X subchild = child = fork(); X if (child < 0) { X perror("fork"); X fail(); X } X if (child) X dooutput(); X else X doshell(); X } X doinput(); X} X Xdoinput() X{ X register int cc; X char ibuf[BUFSIZ]; X X while ((cc = read(0, ibuf, BUFSIZ)) > 0) { X DECRYPT_KEYBOARD_INPUT(ibuf, cc); X (void) write(master, ibuf, cc); X } X done(); X} X X#include <sys/wait.h> X Xvoid Xfinish() X{ X union wait status; X register int pid; X register int die = 0; X X while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0) X if (pid == child) X die = 1; X X if (die) X done(); X} X Xdooutput() X{ X register int cc; X time_t tvec, time(); X char obuf[BUFSIZ], *ctime(); X X (void) close(0); X tvec = time((time_t *)NULL); X X for (;;) { X cc = read(master, obuf, sizeof (obuf)); X if (cc <= 0) X break; X ENCRYPT_SCREEN_OUTPUT(obuf, cc); X (void) write(1, obuf, cc); X } X done(); X} X Xdoshell() X{ X int t; X X /*** X t = open(_PATH_TTY, O_RDWR); X if (t >= 0) { X (void) ioctl(t, TIOCNOTTY, (char *)0); X (void) close(t); X } X ***/ X getslave(); X (void) close(master); X (void) dup2(slave, 0); X (void) dup2(slave, 1); X (void) dup2(slave, 2); X (void) close(slave); X execl(shell, "sh", "-i", 0); X perror(shell); X fail(); X} X Xfixtty() X{ X struct termios rtt; X X rtt = tt; X cfmakeraw(&rtt); X rtt.c_lflag &= ~ECHO; X (void) tcsetattr(0, TCSAFLUSH, &rtt); X} X Xfail() X{ X X (void) kill(0, SIGTERM); X done(); X} X Xdone() X{ X time_t tvec, time(); X char *ctime(); X X if (subchild) { X tvec = time((time_t *)NULL); X (void) close(master); X } else { X char tmp[128]; X (void) tcsetattr(0, TCSAFLUSH, &tt); X /* This too has to be hacked when we do a real encryptor */ X /* This text should be sent and checked encrypted */ X strcpy(tmp, "\n[%MAGIC-PGP-END-SESSION%]\n"); X ENCRYPT_SCREEN_OUTPUT(tmp, strlen(tmp)); X printf("%s", tmp); fflush(stdout); X /* Need a 'sleep' here to flush that damn buffer properly */ X sleep(2); X } X exit(0); X} X Xgetmaster() X{ X char *pty, *bank, *cp; X struct stat stb; X X pty = &line[strlen("/dev/ptyp")]; X for (bank = "pqrs"; *bank; bank++) { X line[strlen("/dev/pty")] = *bank; X *pty = '0'; X if (stat(line, &stb) < 0) X break; X for (cp = "0123456789abcdef"; *cp; cp++) { X *pty = *cp; X master = open(line, O_RDWR); X if (master >= 0) { X char *tp = &line[strlen("/dev/")]; X int ok; X X /* verify slave side is usable */ X *tp = 't'; X ok = access(line, R_OK|W_OK) == 0; X *tp = 'p'; X if (ok) { X (void) tcgetattr(0, &tt); X (void) ioctl(0, TIOCGWINSZ, X (char *)&win); X return; X } X (void) close(master); X } X } X } X fprintf(stderr, "Out of pty's\n"); X fail(); X} X Xgetslave() X{ X X line[strlen("/dev/")] = 't'; X slave = open(line, O_RDWR); X if (slave < 0) { X perror(line); X fail(); X } X (void) tcsetattr(slave, TCSAFLUSH, &tt); X (void) ioctl(slave, TIOCSWINSZ, (char *)&win); X (void) setsid(); X (void) ioctl(slave, TIOCSCTTY, 0); X} END-of-remote.c exit

1 0

Anonymous Encrypted Remailer Interface for Emacs
by michael shiplett 17 Dec '03

17 Dec '03

Hello, I finally wrote some code. This interface automates the wrapping of messages for use with the encrypted anonymous remailers--provided you're willing to enter into Emacs for the wrapping. I've sent & received several messages using it. Please let me know if you find any problems. enjoy, michael =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ;;; anon-remail.el v1.0, anonymous remailer interface ;;; written by michael shiplett <walrus(a)umich.edu> ;;; Any comments or suggestions welcomed. ;;; License ;;; No implied or expressed warranty nor any other guarantee. ;;; Do what you want with this. ;;; Anonymous Encrypted Remailer Interface ;;; Usage: ;;; You must set ar-remailer-list to a list of anonymous ;;; remailer addresses. These must be in a valid mail ``To:'' ;;; format. The initial recipients address must also be in a valid ;;; ``To:'' format; addresses depending on alias files will not ;;; work because your mail program (MH, Elm, mail, etc.) will ;;; not get a chance to process them before the message is wrapped. ;;; After writing your message, invoke ar-wrap-message. If you ;;; wish to sign the message, you should only sign the first ;;; wrapping. ;;; After the message has been wrapped, a list will appear in ;;; the minibuffer--this is the route the message will take. ;;; This package requires that you have mailcrypt configured ;;; for use with pgp (unless you send to ripem remailers). ;;; To Do: ;;; Modify mc-encrypt to take a boolean argument for ;;; signing the message. ;;; Allow for different remailer lists based on whether ;;; the transit delay one wants, e.g., fast, normal, or slow. (require 'mailcrypt) ;; User Variables (defvar ar-remailer-list nil "*List of remailers from which to choose.") (defvar ar-hops 3 "*Number of remailers among which to pass message.") ;; Hooks (defvar ar-start-hook nil) ;; Functions (defun ar-wrap-message (&optional hops) "*Wrap the current message for a person and then wrap it for HOPS remailers. If HOPS is nil, use the value of `ar-hops'." (interactive "P") (run-hooks 'ar-start-hook) (let ((remailer-path (list (mail-fetch-field "to" nil t)))) (ar-wrap-message-for-individual) (if (not hops) (setq hops ar-hops)) (while (< 0 hops) (let ((remailer (ar-choose-remailer))) ;; `remailer-path' is to prevent us ;; from sending to the same remailer twice ;; in a row. ;; It gives the path the message will take ;; beginning with `(car remailer-path)' (while (string= remailer (car remailer-path)) (setq remailer (ar-choose-remailer))) (setq remailer-path (cons remailer remailer-path)) (ar-wrap-for-remailer remailer) (setq hops (1- hops)))) (message "%s" remailer-path))) (defun ar-choose-remailer () "*Select a random remailer from `ar-remailer-list'." (let (number-of-remailers remailer) ;; Choose a remailer (setq number-of-remailers (length ar-remailer-list)) (or number-of-remailers (error "No remailers!")) (nth (random number-of-remailers) ar-remailer-list))) (defun ar-wrap-for-remailer (remailer) "*Wrap the current mail buffer for mailing to a specified remailer." (let (recipient) ;; Keep track of whom should receive the resent message (setq recipient (mail-fetch-field "to" nil t)) ;; Add the magic redirection words (goto-char (point-min)) (search-forward (concat "\n" mail-header-separator "\n")) (setq start (point)) (insert "::\nRequest-Remailing-To: " recipient "\n\n") ;; Wrap the message for the remailer (mc-encrypt-message remailer nil) ;; Add in the final magic remailer incantation (goto-char start) (insert "::\nEncrypted: PGP\n\n") ;; Set the message to be sent to the remailer (ar-set-recipient remailer) )) (defun ar-wrap-message-for-individual () "*Does the initial wrap for a message not intended for a remailer" ;; Figure out to whom the message is currently intended (let (recipient) (setq recipient (mail-fetch-field "to" nil t)) (mc-encrypt-message recipient nil) )) (defun ar-set-recipient (recipient) "*Set the ``To:'' field of a message. This will not work on a multi-line ``To:''." (or recipient (error "No recipient!")) (goto-char (point-min)) (search-forward "To:") (let ((beg (point))) (end-of-line) (delete-region beg (point))) (insert " " recipient)) (provide 'anon-remail)

1 0

New fast cryptocomputer chip
by bart＠netcom.com 17 Dec '03

17 Dec '03

On page 20 of EE Times, Feb. 14, 1994, Roger Woolnough wrote: "By linking up with an Israeli company specializing in cryptographic technology, SGS-Thompson Microelectronics has developed a family of monolithic cryptocomputers aimed at high-security smart-card applications. The new devices combine SGS-Thompson's ST16XYZ secure smart-card architecture with cryptographic enhancements developed by Fortress U&T Ltd." Summarizing the remainder - The approach is based on public key encryption, speed is enhanced by a modular arithmatic coprocessor developed by Fortress for very fast execution of modular exponentiation operations. "A typical 512-bit signature calculation can be performed 10 times faster than with the best performing smart-card cryptoprocessor currently on the market. The ST16CF54 will be followed by further devices, such as the ST16KF74, capable of full-speed X.25 communications."

1 0

Information Highway Beautification Fund
by jim＠Tadpole.COM 17 Dec '03

17 Dec '03

Date: Fri, 4 Mar 1994 04:01:33 -0500 From: "Carl Malamud" <carl(a)radio.com> To: "Announcements" <announce(a)radio.com> Org: Internet Multicasting Service Channel: Internet Town Hall Subject: Information Highway Beautification Fund The Information Highway Beautification Fund Abstract: A Proposal To Turn on the Lights on the Information Superhighway This document outlines some of the background on the Clipper proposals and shows how Clipper is just one example of the underlying public key technology. We argue that in the Clipper debate has concentrated on national security and individual privacy and we may have lost sight of other fundamental constitutional issues, the need to promote commerce and establish a safe and secure information highway. Businesses will not open their doors to cyberspace until we provide clean, well-lit streets in the global village. This document proposes a royalty-free licensing pool for the technology, obtaining public use of the public key patents through the use of eminent domain or other mechanisms. The document then proposes a license for users of the public key technology, the proceeds of which would be placed in an Information Highway Beautification Fund. The license allows an individual or corporation (presumably with different fees structures for each type of user) the right to use the basic public key technology. The proceeds from the license fee would be used to pay back the original patent holders and to fund public works projects on our National Information Infrastructure. A crucial aspect of this proposal is that the license plates be on a per-person basis, not on a per-certificate basis. People must be able to change their certificates on a frequent basis: the license is a right to use the technology not a fee for a single certificate. This is not an invitation to have a single government certification hierarchy or to register the certificates. The license is a right to use the technology, not an invitation to form a universal ID system or a rigid, inflexible certification bureaucracy. In fact, it is possible (and often desirable) to use the basic public key technology without using a certificate at all. Background: The Clipper Controversy The current debate on cryptography and computer security centers around two often-conflicting government functions embodied in our constitution: maintaining our national security and preserving the rights to personal privacy. The public debate on the Clipper issue has revolved around the question of whether government should have a "back door" into a cryptographic chip. Should the government be able, under appropriate court orders, to decode a conversation? Should criminals be able to hide themselves behind a mask of strong cryptography? The Clipper proposal requires government users to purchase a chip that has a special key that is kept in the custody of two government agencies, a concept known as "key escrow." Under appropriate conditions, the government can decode a conversation that was encoded using the Clipper chip. The Clipper proposals use the theory that government, by purchasing large numbers of these chips, will encourage private users to adopt the same scheme, thus leading to lower prices from higher volumes and also leading to a standard for the use of cryptography on the information highway. While the national security and law enforcement goals are clear, there are strong reasons why this proposal may not work. The efficacy of a key escrow scheme and the ability of the government to keep these crucial secrets hidden has been questioned by computer and legal experts. Civil liberties experts have questions the constitutional propriety of a back door. Leaving aside the basic constitutional issues, the idea that the government will lead through its purchasing power has been shown to be flawed in a number of other situations. In the area of the Government OSI Profiles (GOSIP), for example, NIST and other agencies attempted to lead the market through purchases but ended up far behind the technology curve as government and business alike flocked to solutions that were more practical and cost effective. Just because the government purchases lots of $600 hammers doesn't mean that corporate users will necessarily follow suit. The real problem with the Clipper debate, however, is that we have neglected some much more fundamental issues: the question of how we deal with public key cryptography. Public key cryptography, the underlying technology behind the Clipper chip, does much more than simply encrypt data, it is a building block for our information highway. The Importance of Public Key Cryptography Public key cryptography is a fundamental technology that provides a basic security fabric for the national information infrastructure. The most important function it provides is authentication, the ability to know who another person or computer or program is in cyberspace. Public key cryptography is the basic stuff from which we make streetlights for the information highway. Authentication and privacy of data are two functions of a security infrastructure, but there are others. For example, public key cryptography allows us to append a digital signature to a document, a method that allows us to verify the integrity of the document and assure the recipient that the document was not changed since it was originally generated. Public key cryptography also allows us to provide services such as non-repudiation, a way of verifying that a document was actually received (analogous to a delivery receipt from a registered letter). Public key cryptography thus provides a bundle of extremely fundamental services: authentication, privacy, message integrity, and non-repudiation, among others. This technology is so basic that it must be embodied throughout our computer networks in a way as fundamental as the deployment of steel in a building. Public key cryptography is one of the basic building blocks for computer networks. Many people feel that they need to decide how this technology should be applied. The Clipper proponents, for example, feel that public key cryptography is to be used to encrypt bits on the wire. Another community is advocating a particular style of electronic mail, known as Privacy Enhanced Mail (PEM). A building block as fundamental as public key cryptography must be deployed throughout the infrastructure. No one person or group will know in advance everywhere we need to use something so basic. Take PEM for example. Even if PEM is your messaging solution, there are a host of other applications ranging from remote login to file transfer to listening to radio or making a telephone call. The important point is that we don't know now all the ways that we use a general-purpose infrastructure. We will only know as we deploy it and we can't deploy the technology until we get the basic tools to make it secure. We cannot make security a special service. We cannot make security a government program or the responsibility of a particular group. We must build security into the very framework of the NII or the streets of the global village will remain unpopulated. Without a fundamental security infrastructure, businesses will not conduct commerce on the NII, but will have to build special-purpose networks for each function. Sharing an infrastructure is essential if we are to realize the cost savings of an information highway and even more essential if we are to provide the framework that will encourage small, mom-and-pop digital delis open their doors for business. The current policy debate ignores the fundamental economic importance of services such as authentication. We cannot open our doors for business until we can see who is knocking at the door. We can't sell a fax for two cents or a movie on demand for a dollar or do any of the fundamental transactions of an economy without this basic technology. Commerce in the real world requires a multitude of different models and methods. Cash, barter, purchase orders, credit cards, and checks are just a few of the methods. There is no reason to think that we can avoid the same real-world motley technology in cyberspace. We need to build the fundamental technologies of public key cryptography into the very fabric of our infrastructure, applying security throughout the NII at all layers. How Public Key Works To understand why public key is so fundamental, it helps to have a basic idea of how it works. The public key technology is based on two related keys: a private key and a public key. You keep your private key secret and let people know your public key. A piece of data encoded with the private key can be only decoded with the public key and vice versa. The most obvious application of this technology is privacy. I take your public key and encode a message. You have your private key and can decode the message. Alternatively, I take my own private key and encode the message. You have my public key and can decode the message. In reality, public key cryptography is a very slow way of encoding and decoding an entire message. Instead, we use public key cryptography to exchange a shared secret: a symmetric key that we both know about and use to do encoding and decoding. For example, a common encryption algorithm is the Data Encryption Standard (DES). DES is very fast, but requires both parties to know the same DES key. In a typical scheme, we would use the public key method to exchange the DES key and then use the DES key to encode the message. For example, I could generate an arbitrary DES key and hide it by encoding it with your public key. You would then "unwrap" the package with your private key and use the resulting shared secret to quickly and efficiently decode my message to you. The fundamental benefit that public key gives us is authentication: knowing who we are talking to. If I know your public key, you can use your private key to send me a "certificate." I know that only you could have generated this certificate, since I am able to decode it successfully using your public key. Certificates ultimately only work if public keys are widely deployed and well-known. The scheme proposed by many is to define a standard certificate, containing a public key and information about the certificate holder, such as the name or institutional affiliation. Validation of certificates is done using a certificate hierarchy. If there are a few very well known public key, say for the federal government or for MIT, that key combination can be used to certify other public keys. I know that your public key is really yours because MIT certifies that it is and everybody knows the MIT key. There are thus two aspects to a security infrastructure. First, there must a wide deployment of public-key based certificates. Second, there must be many different kinds of programs throughout the computer network that understand what a certificate is and how to use it. One program might use the keys as the basis for encrypting data on the wire or in an electronic mail message. Another set of services might use keys as the basis for allowing access to telecommunications service or for deciding the type of access to libraries a person should get. The Current Status of Public Key Cryptography Public key cryptography has its roots in research conducted at Stanford by Diffie and Hellman and at MIT by Rivest, Shamir, and Adleman. In both cases, the academic research efforts spun off commercial companies. In the case of Stanford, the company Cylink was formed and in the case of MIT a company called RSA Data Security, Inc. was formed. The basic patents that govern public key cryptography are thus owned by four entities: MIT, Stanford, Cylink, and RSA. Because the basic technology is so intertwined, one cannot really do effective work in the field without using pieces of several different patents. To resolve licensing problems, the four entities formed Public Key Partners, which handles licensing of the technology. A commercial entity that wants to use public key technology needs a license from Public Key Partners. Because the basic technology was developed with federal dollars, the federal government has the right to use the technology. In addition, in many international jurisdictions the technology is widely available, to the extent that the basic algorithms can be downloaded anonymously from a variety of locations. To address the question of non-commercial use, RSA has worked with the Internet Engineering Task Force on the PEM proposals. In the case of PEM, there are versions of the software that are available for federal and academic institutions. It should be noted that the reference implementation that RSA provides for non-commercial users is specifically restricted to PEM- like mail systems and does not apply to general-purpose uses of the technology. Commercial users, of course, must use a licensed version from a software developer or negotiate a license directly with Public Key Partners. Commercial entities in the United States, groups that include software developers, computer hardware companies, and telecommunications companies, must secure a license from Public Key Partners. Public Key Partners has pursued a strategy that has resulted in a number of large corporations licensing the technology, including DEC, Lotus, and many others. However, commercial deployment has been limited because of the lack of the ability to build the technology into multi-vendor standards and because of the lack of a certificate system. More importantly, small businesses have often avoided the technology because of fears of high licensing costs. To complicate matters, the National Institute of Standards and Technology (NIST) has proposed a public key standard that is related to the RSA algorithms. In order to get around potential patent conflict problems, the commercial rights to this technology go to Public Key Partners. Public Key Partners thus has an exclusive grasp on this basic technology in the commercial realm. The current patent situation is very much like the situation earlier this century for vacuum tubes and for Frequency Modulation (FM). In both those cases, the fundamental patents were so intertwined that no progress was made in the field. In both cases, the federal government stepped in to help lead us towards a solution. A Proposal: The Information Highway Beautification Fund The main problem with the current situation is that it requires every developer to obtain a license. Licenses are priced high enough that small, ad hoc developers can be easily discouraged. More importantly, it leaves the decision on how to use the technology in the hands of a few entities, such as NIST or Public Key Partners. The decision on who gets a license is an appropriate one for some technologies, but not for one as basic as public key. We need the engineers building our NII to be able to use fundamental tools without asking each time they come up with a new application. Public key cryptography is a classic public good. If we can universally deploy certificates, there is a tremendous public benefit, benefits that are not reflected in a system based on commercial licensing of monopoly patents. Public key-based certificates are the license plates for the information highway, the light that lets us know who we are talking to. While Public Key Partners may derive some benefit from selling the technology to a few large corporations, society (and under our proposal, Public Key Partners) will benefit even more from universal deployment. If we recognize the fundamental importance of this technology, there are some policy options that easily come to mind. The first policy outcome, the one essential to conducting electronic commerce on the Internet, is to make public key technology widely available. We propose here a royalty-free license pool for the public key patents. It is essential that the pool allow use of the technology without prior approval: no one bureaucracy or regulation can determine in advance how this technology can be used. Such a pool could be established by negotiation between the federal government and Public Key Partners, or could be established by more assertive techniques such as the use of eminent domain. The use of eminent domain recognizes that the patents are valuable property. Eminent domain says that your property is very nice, but unfortunately we need to build a freeway through it. Eminent domain recognizes the taking and requires the government to compensate the property owners. Eminent domain is an extreme way of reaching the goal of making the technology widely available, and there are other, less drastic solutions available. However, the key point is that the technology must become widely available to allow us to build it into the infrastructure of our information highway. Once the technology is available, we suggest that the government establish a license, a fee which is levied upon a user or corporation. We beg the question here of the format of the certificate (and feel strongly that a single certificate hierarchy or certificate format would be a grave technical and constitutional mistake). We suggest instead that the government resolve the more fundamental issue of placing the technology in an open pool and levying a per-user license fee. Once the basic principle is in place, the government can convene a set of hearings to flesh out details such as which agency collects the license fee and the fee structure. Presumably, the user fee would be a one-time fee of $100 or less and corporations would pay on a sliding scale that would encourage small enterprises. A crucial aspect of this proposal is that the license fee be on a per user basis, not on a per certificate basis. We cannot have a government hierarchy of certificates, or a requirement to keep certificates in some standard format, or to keep certificates around to allow an audit or to control how the certificate is used, In fact, there are many instances where public key technology would not use a certificate. The fee pays for a license to use the technology not a way to audit how the technology gets used. The revenues from the proposed license fee would be placed in the Information Highway Beautification Fund. Part of the proceeds of this fund would go to pay back Public Key Partners for the taking under eminent domain, and the remainder would go towards paying for public works projects on the NII. The public works part of the fund would be available to pay for things like information interstates, publicly funded information sources, and establishing equal access to the information highway from our inner cities, our hospitals, our libraries, and our schools. Making payment to Public Key Partners a function of individual and corporate fees could easily lead to a windfall for the current patent holders. We feel this is perfectly appropriate: universal deployment of public key technology will benefit society to the tune of billions of dollars. It is an enabling technology and even a few hundred million dollars going to those who established the technology is not unreasonable. While many maintain that the patents should not have been granted in the first place, we feel that this issue has already been decided and we look for creative solutions that move us beyond the current impasse. The choice we face now is a simple one. The NII is a general-purpose infrastructure, a set of streets and roads for the information superhighway. If we can't make those roads safe and secure, then business will never use them. Instead, our corporations will continue to build special-purpose infrastructures, dedicated networks for one community or another. The cost to society is orders of magnitude higher: a general-purpose infrastructure is what allows our corporations to increase their productivity and be competitive on a world market. More importantly, a general-purpose infrastructure allows new businesses to be quickly established. The information highway is crying for leadership. Our choices are policy choices, not technical ones. The Clinton/Gore administration and the current Congress have come down firmly in support of a National Information Infrastructure. Public key cryptography is an example of an area where our government can help lead us, providing the basic building blocks for an information economy. For More Information More information on the issue of public key cryptography and the Clipper issue is available from a variety of sources, including: WIRED Online Services Gopher: gopher.wired.com E-mail: infobot(a)wired.com ("send clipper/index" in the body) WWW: http://www.wired.com Electronic Freedom Frontier FTP: ftp.eff.org Gopher: gopher.eff.org WAIS: wais.eff.org National Institute of Standards and Technology Gopher: gopher-server.nist.gov

1 0

Re: How to do encrypted telnet without being root (tutorial, includes src)
by Jef Poskanzer 17 Dec '03

17 Dec '03

That's quite interesting, but it sure looks like it's unable to encrypt the only part of the session that I really want to encrypt: the password. --- Jef

1 0

CA meeting
by mdbomber＠w6yx.stanford.edu 17 Dec '03

17 Dec '03

Is the CA Cypherpunks meeting on Saturday, 12 March? I want to try to go to it. Internet: mdbomber(a)w6yx.stanford.edu Matt Bartley GPS: 33 49' xx'' 117 48' xx'' (xx due to SA :-)

1 0

UK cypherpunks ready to meet at 2000 or 2200 on 12 March?
by russw＠netcom.com 17 Dec '03

17 Dec '03

To the UK participants on the cypherpunks list, and particularly those in the southeast (London, Kent, Essex, etc): Are any of you interested in holding a meeting synchronous with the physical/teleconference meeting of 12 March in Mountain View, CA and other US locations? Regardless of the technical arrangements, I can guarantee a venue that day in London for you. If you decide to go the way of a brief telephone call-in from London, I will pay for the call. If interested, let me know immediately, and I'll make calls to those nearby who are not on the list, but who are interested and sympathetic. Cheers, Russell Russell Earl Whitaker russw(a)netcom.com Director, Extropy Institute 408-366-5435 ================================================================

1 0

CFP roomshare...
by W Lee Nussbaum 17 Dec '03

17 Dec '03

I know this is not quite appropriate to this list, but here goes: Is anyone going to Computers, Freedom, & Privacy 4 in Chicago later this month, and interested in splitting a room to keep costs down? Please mail me at wln(a)tla.org if you are interested. Thanks. - Lee

1 0

How to clear sign messages with PGP (FAQ)
by exabyte!smtplink!mikej＠uunet.UU.NET 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > How do you get those great signatures on your posts? > > I've been trying to do this with PGP, but I only get a signature file. This > file seems to be a binary file or just a signature. I'll use a command > like: pgp -s filename. > > Perhaps your using a shell? No, I just use this MS-DOS batch file called sign.bat: pgp -sta +clearsig=on %1 The %1 expands to the first argument on the command line. To sign a text file called toscott.txt, I just give the command sign toscott.txt When you get a message signed like that, you should be able to verify the signature by simply executing pgp on the file you get (provided you have my key -- it is on the key servers, available by finger mpj(a)csn.org or mpjohnso(a)nyx.cs.du.edu, ftp://csn.org/mpj/mpj4.asc, or on my BBS (303-938-9654): pgp frommpj.txt For more pgp tricks, see the FAQ ftp://netcom.com/gbe/ (echoed on ftp://csn.org/mpj/public/pgp/) or on the Colorado Catacombs BBS. ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj(a)csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso(a)nyx.cs.du.edu mikej(a)exabyte.com | | |||\ ( | m.p.johnson(a)ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.4 iQCVAgUBLXdfdj9nBjyFM+vFAQEkDAQA0sp3qwbXBcp9F4LhtHaLCtag0LKXR1XQ 6hlNsE+M5KIZzLBYcQirlMY0qQKeKwXg9SE3kPs/m/hBySsGbFMqVh0OBSVNjT8a 9QizZB2MZQg+oh91eyNq+Ys5SG04TeOCQtW5UtKdqD4Pe+Teb7UIJxbCq+gGaQ0O Ba1dF1DC8/4= =6W/G -----END PGP SIGNATURE-----

1 0

Re: How to do encrypted telnet without being root (tutorial, includes src)
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

That's quite interesting, but it sure looks like it's unable to encrypt the only part of the session that I really want to encrypt: the password. --- Jef True - that's why I suggested using one-time passwords before you get to that stage. I'm using s/key myself. If you can't install s/key checking in login, you can use an s/key shell as a user process (assuming you can change your shell that is). By the way, S/Key *doesn't* need an intelligent card - you can do what I do and print off 100 passwords small on a credit-card slip. I fetched it as soon as I discovered this. It's not a perfect system but it helps. G

1 0

Standards for Stenography/Steganography?
by Gary Jeffers 17 Dec '03

17 Dec '03

Tim May says that the criticism I received was mild. It was not that mild. I am particularly incensed by Poskanzer's suggestion that I fetch the old information when, it turns out, that info was not available. That was bullshit! Anyway, hopefully, Poskanzer's technical skills are great & he will pull a giant rabbit out of the hat. In our defense, I would guess that Sergey had the same idea that I had: "Steganography! a hide in plain sight, travel casually in day- light, leave no footprints, safe long term storage, last-ditch, safe crypt. & , apparently, no one's working on IBM micro implementations! What an opportunity to make a contribution! If we don't write the code I'll bet we can provoke a really good programmer with crypt knowledge to do it." It would be difficult for us to know that this area was already discussed, tactics pretty much resolved, & had big old guns working on it without them telling us. Thank God the big old guns were there to disabuse us of our pipe dreams & illusions! I'm pretty irreverent, but I do have a lot of respect for the really smart guys who are sacrificing huge chunks of time in writing code & theory to free us as well as themselves. It takes me many hours per week to deal with cypherpunks mailing list. So, I can understand how the big old guns can get bothered by newbies farming old ground & taking up lots of bandwidth while mudding the water. With that said, & having a lot less to say that I thought I had, I shall go back to a higher LURK/BANDWIDTH ratio & stop annoying people. As Johnathan Winter's mother used to say: "If you can't be bright, be polite." also quiet? Yours Truly, Gary Jeffers

1 0

No Subject
by hughes 17 Dec '03

17 Dec '03

Date: Wed, 2 Mar 1994 09:14:40 -0800 From: Hal <hfinney(a)shell.portal.com> Sender: hughes(a)toad.com Message-Id: <199403021714.JAA17114(a)jobe.shell.portal.com> To: cypherpunks(a)toad.com Subject: Re: Insecurity of public key crypto #1 (reply to Mandl) [Maintainer's note: Sometimes the subscribe filter for majordomo works too well. This message came in a couple of days ago, got filtered, and I've finally figured out how to massage majordomo into getting it out into the list. Sorry about that, Hal.--EH] I run a simple script which will provide the Cypherpunks list in encrypted form. Send me your email address and a PGP public key and I will add you to the list. Once you have it working nicely you can then unsubscribe from the regular list (I can't unsubscribe you from the regular list). Interestingly enough, I have been doing this for about a year, and in that time about ten people have asked to sign up (I haven't publicized it heavily). All but two have asked to be removed within a week, saying that it was too much hassle to deal with that volume of incoming encrypted mail! Let me know if you want to try it. Hal Finney hfinney(a)shell.portal.com

1 0

Standards for Stenography?
by Gary Jeffers 17 Dec '03

17 Dec '03

Tim May says that the criticism I received was mild. It was not that mild. I am particularly incensed by Poskanzer's suggestion that I fetch the old information when, it turns out, that info was not available. That was bullshit! Anyway, hopefully, Poskanzer's technical skills are great & he will pull a giant rabbit out of the hat. In our defense, I would guess that Sergey had the same idea that I had: "Steganography! a hide in plain sight, travel casually in day- light, leave no footprints, safe long term storage, last-ditch, safe crypt. & , apparently, no one's working on IBM micro implementations! What an opportunity to make a contribution! If we don't write the code I'll bet we can provoke a really good programmer with crypt knowledge to do it." It would be difficult for us to know that this area was already discussed, tactics pretty much resolved, & had big old guns working on it without them telling us. Thank God the big old guns were there to disabuse us of our pipe dreams & illusions! I'm pretty irreverent, but I do have a lot of respect for the really smart guys who are sacrificing huge chunks of time in writing code & theory to free us as well as themselves. It takes me many hours per week to deal with cypherpunks mailing list. So, I can understand how the big old guns can get bothered by newbies farming old ground & taking up lots of bandwidth while mudding the water. With that said, & having a lot less to say that I thought I had, I shall go back to a higher LURK/BANDWIDTH ratio & stop annoying people. As Johnathan Winter's mother used to say: "If you can't be bright, be polite." also quiet? Yours Truly, Gary Jeffers

1 0

Soundblaster for Secure Voice
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

Any number of persons had mentioned the use of a SoundBlaster board for use in a secure voice application for PCs. In the February 17, 1994 issue of EDN, there is an article entitled 'Speech-synthesis and -recognition chips personalize consumer products' by John Gallant, Tecnical Editor, starting on P. 27. There is a company mentioned, ESS Technology, Fremont CA, (510)226-1088, that produces two Sound Blaster register level compatible chips, the ESS488 (without music synthesis) and ESS1488 (with music synthesis). The ESS1488 will run on 3.3 or 5 volt Vdd, and appears to be intended for portable computer applications. Cost per ESS1488 is $18 (presumeably in quantity).

1 0

FWD>CPSR Alert 3.05
by Dave Banisar 17 Dec '03

17 Dec '03

>From CPSR FWD>CPSR Alert 3.05 ============================================================== @@@@ @@@@ @@@ @@@@ @ @ @@@@ @@@@ @@@@@@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @@@ @ @@@ @@@@@ @ @@@ @@@ @ @ @ @ @ @ @ @ @ @ @ @ @ @@@@ @ @@@ @ @ @ @ @@@@ @@@@ @ @ @ ============================================================= Volume 3.05 March 3, 1994 ------------------------------------------------------------- Published by Computer Professionals for Social Responsibility Washington Office (Alert(a)washofc.cpsr.org) ------------------------------------------------------------- Contents [1] Welcome to the CPSR Alert [2] FBI Digital Telephony Bill Returns [3] Clipper Petition Passes 40,000 Signatures [4] Clipper and Cantwell [5] FCC and Electronic Mail [6] NTIA Privacy Inquiry [7] DIAC Conference Announcement [8] New Files at the CPSR Internet Library [9] Upcoming Conferences and Events ------------------------------------------------------------- [1] Welcome to the CPSR Alert We should take a moment to welcome the new readers of the CPSR Alert. In the last month, the number of subscribers has more than tripled. We'd like to thank you for your interest in CPSR and tell you about a few more services available. If you have FTP/Gopher/WAIS access you should explore the CPSR Internet Library at CPSR.ORG. There is a wide range of materials covering Clipper, civil liberties, information policy and the NII. Many of the Administration's materials are available from CPSR.ORG. We also provide archives for the Taxpayers Assets Projects, Privacy International, and the Cypherpunks mailing list. If you are interested in Clipper and other civil liberties issues, you should consider attending the Computers, Freedom & Privacy conference in Chicago, March 23-26. CPSR sponsored the first CFP in 1991. It is now a leading event for people interested in civil liberties and privacy. (see calendar for more information). In April, CPSR is sponsoring a two-day conference on the National Information Infrastructure at MIT. Featured speakers include Benjamin Barber, Herb Schiller and Tom Grudner. (see section 7 for more information). If you are interested in NII policy, you might want to get a copy of the CPSR NII report, "Serving the Community: A Public Interest Vision of the NII." The report is based on a series of principles developed by the Telecommunications Policy Roundtable and provides a very useful overview of the NII policy debate. The paper is available electronically by sending email to listserv(a)cpsr.org. In the message body write the command "GET CPSR NII_POLICY" (no quotes). The paper will automatically be mailed to you. You can also get the paper through ftp/wais/gopher at cpsr.org/nii/cpsr_nii_policy.txt. To request a paper copy (about 30 pages) send email to cpsr(a)cpsr.org. Welcome again to the CPSR Alert. ------------------------------------------------------------- [2] FBI Digital Telephony Bill Returns The Federal Bureau of Investigation has reintroduced its controversial 1992 proposal to require that communications service providers redesign their equipment to facilitate electronic surveillance. The Bureau has sent a draft to Congress but so far, no Senator or Congressperson has stepped forward to sponsor it. The draft bill, ironically named the Digital Telephony and Communications Privacy Improvement Act of 1994, mandates that common carriers (phone, cable and computer network companies) modify their switches and computers to ensure that surveillance can be conducted concurrently from a remote government facility. It requires that manufacturers and support companies assist carriers. In an addition to the 1992 bill, the 1994 bill also mandates that systems be designed to collect transactional information that users generate and make that information available to law enforcement agencies. This information includes data on calls made and received. Under the NII, future information collected may include all manner of transactions, including purchases, financial and medical information. Any company that fails to comply with the requirements of the bill would be fined $10,000/day and shut down. Companies would have three years from the date of enactment to comply. The Attorney General would have the authority to enact these penalties and would be encouraged to cooperate with the Federal Communication Commission. The FCC would issue rules to cover the cost of complying with the procedures. An internal FBI memo released to CPSR under a Freedom of Information Act lawsuit estimates the cost of compliance at $300 million. Communications Daily reports that other experts have estimated that the cost will be over one billion dollars. The bill also revises sections of the Electronic Communications Privacy Act to extend the legal protection of ECPA to cordless phones and clarifies ECPA to allow for monitoring of computer systems by system managers. The 1992 bill was never formally introduced due to lack of a sponsor after industry, civil liberties groups and the public criticized it. Copies of the 1994 and 1992 drafts are available from the CPSR Internet Library. (see below for details). Also available are educational materials about the Digital Telephony proposal. To obtain a video copy of the ABC Nightline special on the original FBI proposal, send $14.98 plus 3.98 s/h to MPI Home Video, 15825 Rob Roy Dr., Oak Forest, IL 60452 and request a copy of the 5/22/92 program "FBI Pushes for Wiretap Powers." The program features a debate between former FBI Director William Sessions and CPSR Washington Director Marc Rotenberg. Available from CPSR is a 450-page sourcebook of materials on privacy and cryptography, including the materials on the original digital telephony proposal with commentary. The CPSR Sourcebook is available for $50. Send a check to CPSR, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003 --------------------------------------------------------------- [3] Clipper Petition Passes 40,000 The CPSR Internet Petition to oppose the Clipper Proposal has now passed 40,000 signatures. The petition has been signed by users at over 2,600 sites, including 1,100 companies and 800 colleges. For specific sites, MIT has the highest single vote tally, with over 600 messages. Messages continue to arrive at a rate of over 1,000 per day. To sign on to the letter, send a message to: Clipper.petition(a)cpsr.org with the text "I oppose Clipper" (no quotes) You will receive a return message confirming your vote. To obtain a copy of the petition, email a blank message to petition-info(a)cpsr.org For more information on Clipper, email clipper-info(a)cpsr.org. You will receive a copy of the Clipper FAQ. Thanks for your help. --------------------------------------------------------------- [4] The Cantwell Bill and Clipper We've received several inquiries concerning H.R. 3627, Rep. Maria Cantwell's bill to liberalize export controls on encryption software. Some people have been given the impression that the Cantwell bill is a response to the Administration's Clipper initiative and that passage of the legislation would effectively put the Clipper issue to rest. Because of the confusion surrounding this proposed legislation, we think it's important to provide some clarifying information. Rep. Cantwell introduced H.R. 3627 on November 22, 1993. Her comments on the purpose of the legislation appeared in the Congressional Record on November 24, 1993, at Volume 139, Page 3110. According to Rep. Cantwell: The legislation I am introducing today is needed to ensure that American companies do not lose critical international markets to foreign competitors that operate without significant export restrictions. Without this legislation, American software companies, some of America's star economic performers, have estimated they stand to lose between $6 and $9 billion in revenue each year. American hardware companies are already losing hundreds of millions of dollars in lost computer system sales because increasingly sales are dependent on the ability of a U.S. firm to offer encryption as a feature of an integrated customer solution involving hardware, software, and services. * * * This legislation takes some important steps to resolve a serious problem facing some of our most dynamic industries. It would give the Secretary of Commerce exclusive authority over dual use information security programs and products, eliminates the requirement for export licenses for generally available software with encryption capabilities, and requires the Secretary to grant such validated licenses for exports of other software with encryption capabilities to any country to which we already approve exports for foreign financial institutions. * * * My legislation is straightforward. It would allow American companies to sell the commercial software they develop in the United States to their overseas customers including our European allies -- something that is very difficult if not impossible under present policies. Rep. Cantwell's remarks contained no reference to the Administration's Clipper initiative, which had first been announced some seven months earlier. Indeed, there is no provision in H.R. 3627 that would in any way rescind the Administration's recent decision to adopt key-escrow Clipper technology as the government encryption standard. The legislation would do precisely what Rep. Cantwell said it would do -- relax restrictions on the export of strong encryption products outside of the United States. Some have suggested that passage of the Cantwell bill would create an environment in which it is less likely that Clipper will become the de facto encryption standard within the United States. This view was expressed by the Electronic Frontier Foundation (EFF) and several large corporations in a letter to the President last December which expressed "tentative" support for Clipper on a "voluntary" basis. CPSR dissented from this position in a subsequent letter to the President and expressed its opposition to the Clipper proposal under any circumstances. While it is possible that the Cantwell legislation would make it less likely that Clipper will become the de facto privacy standard, such a result is by no means a certainty. It is, in fact, possible that passage of the legislation would provide better U.S. encryption products overseas than would be available within the United States -- particularly if, as many fear, Clipper eventually becomes a mandatory standard in this country. We believe that the Cantwell bill is a step in the right direction, as it would remove current disincentives to the development of strong encryption products by U.S. companies. But the proposed legislation is not a panacea -- it would not address the threat to privacy in the United States created by the Clipper initiative. Export controls on cryptography are a related issue, but they are not central to the Clipper controversy. The Administration's adoption of the key-escrow Clipper standard must be opposed and reversed. --------------------------------------------------------------- [5] FCC and Electronic Mail [Note: The Taxpayers Assets Project is circulating a letter to encourage public participation in FCC proceedings through the Internet. CPSR has endorsed the letter and encourages other organizations and individuals to support this effort. Please repond by March 15.] SIGNATURES NEEDED FOR LETTER ASKING THAT INTERNET BE USED TO BROADEN DEMOCRATIC DEBATE OVER FCC PROCEEDING The following is a letter that will be sent to Reed Hundt, the Chair of the FCC, asking that the FCC use the Internet to broaden democratic participation in FCC proceedings. Specifically, Hundt is asked to 1) set up listserves for discussions of FCC rulemakings and inquiries, 2) accept public comments by electronic mail, and 3) provide easier access to the new FCC.GOV internet node. If you are willing to sign the letter, send the following information to Michael Ward of the Taxpayer Assets Project at: Internet: TAP(a)ESSENTIAL.ORG Fax: 202/234-5176 Postal: P.O. Box 19367, Washington, DC 20036 Voice: 202/387-8030 Name: _________________________ Affiliation: _________________________ (Optional, will be listed as: for purposes of identification only) Postal Address:__________________________ __________________________ __________________________ Voice: __________________________ Internet: __________________________ -------------------------------------------- March 15, 1994 Honorable Reed Hundt Chairman, Federal Communications Commission 1919 M Street, Room 814 Washington, D.C. 20554 Dear Chairman Hundt: We are writing to ask that you use the Internet to broaden opportunities for democratic participation in FCC proceedings. We applaud the FCC for its recent announcement that it has established FCC.GOV as an Internet node, and that the FCC Daily Digest is now available for free by ftp from FCC.GOV. We were also pleased that you have asked the FCC staff to examine methods and procedures for accepting comments on FCC dockets electronically. The measures discussed below would build on your efforts, and are intended to make it easier and less costly for citizens to follow the FCC's work. 1. The FCC should provide Internet electronic mail discussion "lists" on all FCC rulemakings and inquiries. Citizens should be able to sign up for a proceeding by sending a message to the FCC.GOV listserve, with a simple message such as "subscribe pcs-auction-rules-93-253." These Internet discussion lists use today's technology to empower citizens, by enhancing their ability to follow important policy debates. In an Internet discussion list, a citizen can send a message to the FCC listserve, and that message will be echoed to every subscriber on the list. The persons receiving the message will have an opportunity to respond, and a real dialogue can take place. As discussions and debates on the Internet email lists unfold, citizens will have opportunities to gain a much deeper understanding of the issues raised in the proceedings, and how they will be affected by the FCC's actions. 2. In considering methods for accepting comments from the public in FCC dockets, the Commission should provide citizens the opportunity to file comments via electronic mail which is gatewayed through the Internet. These comments should be separate from the dialogue on the discussion lists, and reflect the commentors final views on the subject matter. Several federal agencies now provide opportunities to file comments by electronic mail. For example, OMB's Office of Information and Regulatory Affairs (OIRA), began accepting comments on its Circular A-130 by electronic mail in 1992. 3. As you have already indicated, it will be important that the FCC take steps to ensure that the use of electronic communications is consistent with the legal requirements that the public record be complete and accessible. We understand that the Commission will have to devise ways of ensuring that this broadened public dialogue becomes part of the public record and is in compliance with the Administrative Procedures Act. The Commission should make these comments available to the public both online and through the FCC's reading room. 4. Many citizens can access the Internet via electronic mail, but do not have access to ftp or gopher technologies. Thus, it would be very helpful if the FCC.GOV would provide an "email ftp" service for obtaining files from FCC.GOV, as well as an ability to subscribe to the Daily Digest through electronic mail. Of all the vaunted promises of the information superhighway, the most important is that new information technologies provide opportunities to enhance democratic processes. One of the most important and valuable aspects of the Internet has been its role in restoring civic discourse on a wide range of issues. By adopting these recommendations, the FCC will gain a deeper understanding of the opportunities for enhanced democratic discourse, and it will broaden citizen opportunities to participate in debates over FCC policies. Sincerely, James Love, Taxpayer Assets Project Jeff Chester, Center for Media Education Marc Rotenberg, Computer Professionals for Social Responsibility ---------------------------------------------------------------------- James Love, Taxpayer Assets Project; internet: love(a)essential.org P.O. Box 19367, Washington, DC 20036; v. 202/387-8030; f. 202/234-5176 12 Church Road, Ardmore, PA 19003; v. 215/658-0880; f. 215/649-4066 ---------------------------------------------------------------------- --------------------------------------------------------------- [6] NTIA Privacy Inquiry DEPARTMENT OF COMMERCE National Telecommunications and Information Administration [Docket No. 940104-4004] Inquiry on Privacy Issues Relating to Private Sector Use of Telecommunications-Related Personal Information AGENCY: National Telecommunications and Information Administration (NTIA), Commerce ACTION: Notice of Inquiry; Request for Comments SUMMARY: NTIA is conducting a comprehensive review of privacy issues relating to private sector use of telecommunications-related personal information associated with the National Information Infrastructure. Public comment is requested on issues relevant to such a review. After analyzing the comments, NTIA intends to issue a report, which may make recommendations to the Information Infrastructure Task Force and Congress in the area of telecommunications and information policy, as appropriate. DATES: Comments should be filed on or before March 30, 1994, to receive full consideration. ADDRESS: Comments (seven copies) should be sent to the Office of Policy Analysis and Development, NTIA, U.S. Department of Commerce, 14th St. and Constitution Ave., N.W., Room 4725, Washington, D.C. 20230. FOR FURTHER INFORMATION CONTACT: Carol Mattey or Lisa Leidig, Office of Policy Analysis and Development, 202-482- 1880. AUTHORITY: National Telecommunications and Information Administration Organization Act of 1992, Pub. L. No. 102- 538, 106 Stat. 3533 (1992) (to be codified at 47 U.S.C. s. 901 et seq.). A full copy of the notice is available at the CPSR Internet Library (see below for details). --------------------------------------------------------------- [7] DIAC Announcement "Developing an Equitable and Open Information Infrastructure" Directions and Implications of Advanced Computing (DIAC-94) Symposium Cambridge, MA, USA April 23 - 24, 1994 Benjamin Barber on Electronic Democracy Herbert Schiller on Media Control and Alternative Programming Tom Grundner on Grassroots Networking The National Information Infrastructure (NII) is being proposed as the next-generation "information superhighway" for the 90's and beyond. Academia, libraries, government agencies, as well as media and telecommunication companies are involved in the current development. Computer Professionals for Social Responsibility (CPSR) and other organizations believe that critical issues regarding the use of the NII deserve increased public visibility and participation and are using the DIAC Symposium to help address this concern. The DIAC-94 symposium is a two-day event and will consist of presentations on the first day and workshops on the second day. The DIAC Symposia are held biannually and DIAC-94 will be CPSR's fifth such conference. We encourage your participation both through attending and through conducting a workshop. Sponsored by Computer Professionals for Social Responsbility Co-sponsored by the Internet Society and the MIT Communications Forum. Other co-sponsors are being sought. Please contact us if your organization would like to help with this event. For more information on co-sponsorship or on general issues, contact conference chair, Coralee Whitcomb, cwhitcom(a)bentley.edu. ------------------------------------------------------------- [8] New Files at the CPSR Internet Library Dr. Dorothy Denning's paper presenting the law enforcement view of cryptography and privacy issues. /cpsr/privacy/crypto/ denning_crypto_law_enforcement_feb_94.txt NTIA Call for Comments on Privacy Issues related to Private Sector use of Telecommunications Related Information. /cpsr/privacy/misc_privacy/ntia_privacy_comments_notice_feb_94.txt The inaptly named FBI Digital Telephony and Communications Privacy Act of 1994, Feb 1994 draft. /cpsr/privacy/communications/wiretap/ fbi_wiretap_bill_draft_feb_94.txt The CPSR Internet Library is a free service available via FTP/WAIS/Gopher/listserv from cpsr.org:/cpsr. Materials from Privacy International, the Taxpayers Assets Project and the Cypherpunks are also archived. For more information, contact ftp-admin(a)cpsr.org. ---------------------------------------------------------------- [9] Upcoming Conferences and Events "Computers, Freedom and Privacy 94." Chicago, Il. March 23-26. Sponsored by ACM and The John Marshall Law School. Contact: George Trubow, 312-987-1445 (CFP94(a)jmls.edu) Directions and Implications of Advanced Computing (DIAC)-94 "Developing an Equitable and Open Information Infrastructure" Cambridge, MA. April 23 - 24, 1994. Sponsored by CPSR. Contact: cwhitcomb(a)bentley.edu or doug.schuler(a)cpsr.org. Computer-Human Interaction 94. Boston, Mass. April 24-28. Sponsored by ACM. Contact: 214-590-8616 or 410-269-6801, chi94office.chi(a)xerox.com "Navigating the Networks." 1994 Mid-Year Meeting, American Society for Information Science. Portland, Oregon. May 22 - 25, 1994. Contact: rhill(a)cni.org Rural Datafication II: "Meeting the Challenge of Providing Ubiquitous Access to the Internet" Minneapolis, Minnesota. May 23-24, 1994. Sponsored by CICNet & NSF. Contact: ruraldata-info-request(a)cic.net. Send name, mailing address and e-mail address. "Information: Society, Superhighway or Gridlock?" Computing for the Social Sciences 1994 Conference (CSS94). University of Maryland at College Park. June 1-3, 1994. Contact: Dr. Charles Wellford 301-405-4699, fax 301-405-4733, e-mail: cwellford(a)bss2.umd.edu. Abstracts for papers due March 1. Contact William Sims Bainbridge (wbainbri(a)nsf.gov) Grace Hopper Celebration of Women in Computer Science. Washington, DC June 9-11. Contact: 415 617-3335, hopper-info(a)pa.dec.com DEF CON ][ ("underground" computer culture) "Load up your laptop muffy, we're heading to Vegas!" The Sahara Hotel, Las Vegas, NV. July 22-24, Contact: dtangent(a)defcon.org. Conference on Uncertainty in AI. Seattle, WA. July 29-31. Contact: 206-936-2662, heckerma(a)microsoft.com. Symposium: An Arts and Humanities Policy for the National Information Infrastructure. Boston, Mass. October 14-16, 1994. Sponsored by the Center for Art Research in Boston. Contact: Jay Jaroslav (jaroslav(a)artdata.win.net) Third Biannual Conference on Participatory Design, Chapel Hill, North Carolina, October 27-28, 1994. Sponsored by CPSR. Contact: trigg(a)parc.xerox.com. Submissions due April 15, 1994. (Send calendar submissions to Alert(a)washofc.cpsr.org) ======================================================================= To subscribe to the Alert, send the message: "subscribe cpsr-announce <your name>" (without quotes or brackets) to listserv(a)cpsr.org. Back issues of the Alert are available at the CPSR Internet Library FTP/WAIS/Gopher cpsr.org /cpsr/alert and on America Online in the Mac Telecomm folder. Computer Professionals for Social Responsibility is a national, non-partisan, public-interest organization dedicated to understanding and directing the impact of computers on society. Founded in 1981, CPSR has 2000 members from all over the world and 23 chapters across the country. Our National Advisory Board includes a Nobel laureate and three winners of the Turing Award, the highest honor in computer science. Membership is open to everyone. For more information, please contact: cpsr(a)cpsr.org or visit the CPSR discussion conferences on The Well (well.sf.ca.us) or Mindvox (phantom.com) ======================================================================= CPSR MEMBERSHIP FORM Name ___________________________________________________________ Address ___________________________________________________________ ___________________________________________________________ City/State/Zip _____________________________________________________ Home phone _____________________ Work phone ______________________ Company ___________________________________________________________ Type of work ______________________________________________________ E-mail address _____________________________________________________ CPSR Chapter __ Acadiana __ Austin __ Berkeley __ Boston __ Chicago __ Denver/Boulder __ Los Angeles __ Loyola/New Orleans __ Madison __ Maine __ Milwaukee __ Minnesota __ New Haven __ New York __ Palo Alto __ Philadelphia __ Pittsburgh __ Portland __ San Diego __ Santa Cruz __ Seattle __ Washington, DC __ No chapter in my area CPSR Membership Categories __ $ 75 REGULAR MEMBER __ $ 50 Basic member __ $ 200 Supporting member __ $ 500 Sponsoring member __ $1000 Lifetime member __ $ 20 Student/low income member __ $ 50 Foreign subscriber __ $ 50 Library/institutional subscriber (Corporate memberships also available) Additional tax-deductible contribution to support CPSR projects: __ $50 __ $75 __ $100 __ $250 __ $500 __ $1000 __ Other Total Enclosed: $ ________ Make check out to CPSR and mail to: CPSR P.O. Box 717 Palo Alto, CA 94301 ------------------------ END CPSR Alert 3.05 -----------------------

1 0

more steganography talk
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Stuff that Sergey Goldgaber, Hal, and others wrote induced the following ideas in my head: Goal - create a steganography system that hides cyphertext in such a way that only the true recipient of the message will be able to prove an encrypted message is hidden within a public message. Nobody else will be able to determine if the public message also contains an embedded encrypted message. In Hal's words: > A test, then, for the success of a steganographic > technique is this: given some sampling of data items, > half of which have embedded hidden messages, can the > opponent guess which ones have such messages with better > than 50% accuracy? If not, the steganography is fully > successful. If he can do slightly better than 50%, it may > still be useful depending on the situation. If he can > guess with 100% accuracy, the steganography has failed > and is totally worthless. > If the LSBs of most picture files were truly random, then good steganography would be trivial. Anyone could just plop an unremarkable encrypted message (Stealth-PGP) in the LSB's, starting at the beginning of the file. Since one sequence of truly random bits statistically looks like any other sequence of truly random bits, nobody would be able to prove the picture file contained a hidden encrypted message. Unfortunately, I doubt that most, or even many, picture files have truly random LSBs. It would be possible to write frame grabber or scanner software to purposely place random bits in the LSB of picture files to generate a source of useful picture files. When this software became widely used, good steganography would become trivial. Unfortunately, I don't have much confidence that this could be pulled off on a large enough scale. If it could be done, great, but I'm not holding my breath. Assuming the LSBs of most picture files are not truly random, and wont be any time soon, the next approach to good steganography would be to figure out how to transform a sequence of random bits (your encrypted message) into a sequence of bits that resemble the kinds of bit patterns you see in typical picture files. If you could do this, and do it without requiring more secret keys, then good steganography becomes trivial again. [Actually, you don't have to transform your random bits into a *sequence* of typical picture file LSB bits. The steganography algorithm could deposit the bits anywhere in the picture file, as long the process was reversible and the result was undetectable.] "Reversible, undetectable, without requiring additional keys." Sounds like a good set of requirements for a steganography system. I have an idea to help with the "reversible" part and the "no additional secret keys" part, and it suggests a direction for the "undetectable" part. The idea: Encrypt a widely known value with the recipient's public-key and use the result as an initialization vector for a clever transformation/steganography algorithm. The message recipient recovers the encrypted message by re-calculating the initialization vector using the same widely known value and his public-key and reversing the transformation/steganography step. The initialization vector will be different for each message recipient. The "widely known value" could be a large block of bytes. A large file of random bits could be shipped with the steganography executable. The intent is to make it more difficult and time consuming for the opponent to determine if a public message contains a hidden encrypted message. It's not fool-proof. The opponent could try to discover a hidden message by reversing the process using every known public-key. Worse, an opponent could narrow the search by only trying the public-keys of suspected recipients. However, I think it is an improvement over the techniques being used today. One significant property this technique does *not* possess is deniability. A perfect steganography system will produce results that will let a recipient claim that they did not know a message contained a hidden encrypted message (e.g. most picture files had truly random LSBs). If somebody sent you a hidden message using your public-key and the initialization vector technique, your claim of ignorance might not hold up. Anybody could use your public-key to recover the random bit sequence. They would not recover the contents of the hidden message, but they would be able to show that your file did contain what appears to be a hidden message. It might be enough to tip the scales of justice against you. In my mind, the perfect steganography system depends upon either an environment containing ubiquitous random bit sequences or a reversible algorithm that can transform non-random bit sequences into random bit sequences without using encryption (unlikely). However, I believe a less-than-perfect, but still useful steganography system could be created using the initialization vector technique described above. Jim_Miller(a)suite.com

3 2

SF Chron comes out against Clipper
by baum＠newton.apple.com 17 Dec '03

17 Dec '03

Well, not exactly the Chron, per say, but... this morning a new column debuted about computer networks, the internet, the information highway, and other extrememly trendy topics. The first column was all about Clipper, and why it was a bad idea. I didn't bring it with me today, so I'm not remember lots of details. The writer has an email address on the well (rbr(a)well.sf.ca.us??) ************************************************** * Allen J. Baum tel. (408)974-3385 * * Apple Computer, 20525 Mariani Ave, MS 305-3B * * Cupertino, CA 95014 baum(a)apple.com * **************************************************

2 1

even more steganography talk
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Another way to describe a successful steganography system... I am the opponent. I possess a collection of files that might contain hidden encrypted messages. My task is to determine if they do contain hidden encrypted message. A casual inspection of the files does not reveal any bit patterns that deviate significantly from patterns found is most examples of these kinds of files. However, I suspect these files contain hidden messages that were deposited using a steganography algorithm initialized from a public-key generated initialization vector. To test my hypothesis, I will reverse the steganography process using a large collection of public-keys and then examine the resulting bit sequences. -------- If the steganography algorithm is a good one, reversing the steg process will produce a sequence of bits that appears relatively random, even if there is *no* hidden message. What does "appears relatively random" really mean? How do you measure the randomness of a sequence of bits? I'm not an expert in this field, but I would guess you could measure the randomness by attempting to compress the bit sequence. If the bit sequence does not compress much, it is relatively random. How much is "not much"? In other words, what threshold compression percentage value should you use to declare one bit sequence random and another not random? I don't know. To generalize, an opponent will perform some kind of test to determine if the result of reversing the steg process produces a random bit sequence or a non-random bit sequence. The test will have some threshold value below which indicates a random sequence. If the output of the reverse steganography step always falls below the threshold, even if there is no hidden message, then the opponent will not be able to determine if a file contains a hidden message. Jim_Miller(a)suite.com

2 1

Re: more steganography talk
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Eric Hughes writes: > Assume one hundred each for 10 billion persons. That's > 2^40 keys, or an effective key length of 40 bits. Since > there are not more than 2^16 public keys right now (a > generous estimate) we can assume that this technique is > insecure for public keys. > I'm not really sure what you mean by "insecure for public keys". I'm not trying to achieve "security through obscurity". I'm trying to achieve "deniability through obscurity". If the reverse steg process makes it look like all, or even many, files contain hidden messages, even when they don't, then you can plausible deny knowledge of a suspicious bit pattern in any specific file. Jim_Miller(a)suite.com

1 0

Re: New mailing list?
by mcb＠net.bio.net 17 Dec '03

17 Dec '03

I was thinking about Alan's proposal for a moderated real-world-crypto list (which sounds good, by the way!), and it brought up my main problem with cypherpunks, which is sheer volume, volume, volume! It's not a "noise" problem -- since the end of the LD foolishness the greatest part of what has been posted here has been intelligent, thoughtful stuff. But since c'punks has grown to the size of a newsgroup in volume, simply getting through it is *difficult*. My proposal is pretty simple: splitting the list into cypherpunks-tech and cypherpunks-policy. (Cypherpunks-announce would be left alone of course.) I think a large number of readers would want to be on both lists, but a large number (like myself) would *not*, and if nothing else, it would cut down the mailer load on toad. In short, technical crypto articles, reviews of papers, steganography stuff, PGP-specific stuff, all source code, etc., would go to the cypherpunks-tech list; while policy articles, Clipper stuff, political discussions, anarcholibertarian/extropian material, social implications of digital cash, etc., would go to the cypherpunks-policy list. I *know* there are people out there who would rather that the political stuff not get in the way of their technical discussions, and then there are people like me who are more focused on the policy issues (and regardless of technical background, are never going to be code-level crypto hacks). Comments? -- Michael C. Berch mcb(a)net.bio.net / mcb(a)postmodern.com

3 2

Re: Gun conversion info banned
by mcb＠net.bio.net 17 Dec '03

17 Dec '03

Mike Godwin writes: > > "labeling for an unlawful medical device" -- the Orgone Accumulator. > > Likewise FDA seizures of Scientolgy literature in the '60s as "labeling > > for an unlawful medical device" -- E-meters. Then there are the moves > > against vitamin literature in recent FDA raids. I don't think the courts > > have ever faced the specific issue of regulatory censorship. > > These cases are pre-Brandenburg v. Ohio. In Brandenburg, the Supreme Court > held that mere advocacy of illegal conduct is Constitutionally protected. But the Court has upheld various police-power suppressions of advertising material, etc., even after Brandenburg (1969, right?) under the "commercial speech" exception, like Pittsburgh Press v Human Relations Comm. 413 U.S. 376 (1973). [Glommed from my 1979 Con Law textbook.] This is a doctrine that commercial expression is less Constitutionally protected than political and literary expression for historical and public policy reasons. I don't know what the present state of the commercial speech exception is, but it has definitely been a nasty stain on First Amendment jurisprudence since Valentine v Chrestensen in 1942. -- Michael C. Berch mcb(a)net.bio.net / mcb(a)postmodern.com

1 0

CPSR "explains" why Cantwell bill doesn't matter much - a rebuttal
by Stanton McCandlish 17 Dec '03

17 Dec '03

I'm finding myself, unfortunately, needing to respond to a widely distributed article of sorts from the 3.05 issue of CSPR Alert. The article was unsigned, so I can't address it to anyone by name. The article states: >Some people have been given the impression that the Cantwell bill is a >response to the Administration's Clipper initiative and that passage of >the legislation would effectively put the Clipper issue to rest. >Because of the confusion surrounding this proposed legislation, we >think it's important to provide some clarifying information. Avoiding the passive verb structures, this can better be rephrased as "Some people have assumed that..." People are not given impressions, they _form_ impressions themselves. It is indeed important to clarify information. However the attempt to do so that I see here does not in fact clarify. To wit: >Indeed, there is no provision in H.R. 3627 that would in any way >rescind the Administration's recent decision to adopt key-escrow >Clipper technology as the government encryption standard. The >legislation would do precisely what Rep. Cantwell said it would do -- >relax restrictions on the export of strong encryption products outside >of the United States. To my knowledge, no one in the know has suggested that the purpose of the Cantwell bill is to "recind" the Clipper EES. It is plain from a reading of EFF's material on the subject, Cantwell's own commentary on the bill, and, of course, the bill itself, that HR 3627 is not intended to directly challenge Clipper (unlike Senator Leahy's proposed hearings, also supported by EFF), but is intended to liberalize export restrictions, pulling an important rug out from under Clipper/Skipjack's metaphoric feet. If one cares to read the mass of Feb. 4 documents issued by the White House, Dept. of State, and other agencies, it is abundantly clear that clamping down export restrictions on all cryptographic products, except those supporting the Administration's EES, is a major part of the proposed Clipper deployment plan. It's been more than adequately debated over the last several months that the such a clampdown is necessary if Clipper is to be a so-called success. The measure is aimed at making it difficult for any non-EES crypto application to compete with Clipper, thereby establishing Clipper as a de facto standard. Given this, _any_ attempt to reduce export restrictions is a positive move for privacy-advocates to support, and serves as a strong, though indirect, countermeasure against Clipper. >Some have suggested that passage of the Cantwell bill would create an >environment in which it is less likely that Clipper will become the de >facto encryption standard within the United States. This view was >expressed by the Electronic Frontier Foundation (EFF) and several large >corporations in a letter to the President last December which expressed >"tentative" support for Clipper on a "voluntary" basis. The writer of the message I am replying to here is well aware that this entire matter has been thoroughly dealt with and fully explained. I've done this so many times, I am hesitant to do so again, but these recurring misinterpretations leave me little choice but to clarify one more time: >From EFF's Dec. 8 Cryptography and Policy Statement: >>[There] was a misunderstanding of what the DPSWG offered the >>administration in this proposal [the letter referred to above], leading to >>the belief that both the DPSWG (a coalition of over 50 computer, >>communications, and privacy organizations and associations) and it's >>principal coordinating organization, the Electronic Frontier Foundation, >>have offered to ease their opposition to Clipper. >> >>We see it as a pragmatic effort to get the government to wiggle on >>these issues: one step in the right direction, with many more to >>follow. This step is that we insist that use of Clipper and key >>escrow must be completely voluntary. It's not voluntary if users of >>the Skipjack algorithm are forced to use key escrow. It's not >>voluntary if users who do choose escrow are forced to use the >>government's choice of escrow agents. It's not voluntary if >>manufacturers such as AT&T are pressured into withdrawing competing >>products. It's not voluntary when competing products can't be sold in >>a worldwide market. It's not voluntary if the public can't see the >>algorithm they are "volunteering" to use. It's not voluntary if the >>government will require anyone to use Skipjack or escrow, even when >>communicating with the government. >>... >>But NSA is digging in, and a legislative fight looks more likely. >>If diplomacy fails, EFF must fight for our rights. Thus, we are >>going to need all the allies we can find, from IBM, Apple, Lotus, >>and Sun, to cryptographers, cypherpunks, and folks on the net. >> >>EFF wants the public and the Administration to know (as we have >>frequently stated to them face to face) that the Electronic Frontier >>Foundation would fight to the end any attempt by the Administration to >>do any more than let companies use Clipper if they want and to let people >>buy it if they want -- and only in a market which has other strong >>encryption schemes available because export controls have been lifted. If one actually reads this, one finds that our definition of "voluntary", which has been made _very_ clear to the Administration in repeated face-to-face meetings, stipulates: 1) no forced key escrow, and no forcing of governmental-only escrow for even those that _want_ key escrow 2) no governmental pressure on the marketplace 3) no export restrictions 4) no classified algorithm 5) no FIPS standard, and no forcing _anyone_, even govt. agencies, to use it. In other words, if the entire Clipper scheme were reworked such that Clipper was nothing more than the open, _truly_ voluntary, publicly examinable successor to DES - a quite innocuous govt. crypto standard - then and only then would EFF and the Digital Privacy and Security Working Group offer it's "tentative" support. Please keep in mind that, barring secret NSA backdoors, there is nothing inherently "bad" or "wrong" about the Clipper/Skipjack encryption. Only the methodology involved is reprehensible and unAmerican. >CPSR dissented from this position in a subsequent letter to the President >and expressed its opposition to the Clipper proposal under any >circumstances. Please note that EFF also signed this letter. Any opposition to CPSR being perceived here is 100% illusory. At any rate, I'd also like to point out that the DPSWG letter and the EFF '93 crypto-policy statement are at this point old history. They are no longer applicable (an example line: "It is December, the escrow system is still uncertain, and the Administration is still drafting a report which was due in July" - how timely does this sound?) Dragging such a dead horse out for another beating is quite unfathomable to me. I sincerely hope this will the very last time I have to clarify this matter, partly because I'm tired of repeating myself, but mostly because this sort of inter-organization baiting is counter-intuitive and counter-productive for all organizations and individuals involved, and could cost us (by which I mean those opposing Clipper, in general) a lot of credibility. To continue with the present matter, however: >While it is possible that the Cantwell legislation would make it less >likely that Clipper will become the de facto privacy standard, such a >result is by no means a certainty. It is, in fact, possible that >passage of the legislation would provide better U.S. encryption >products overseas than would be available within the United States -- >particularly if, as many fear, Clipper eventually becomes a mandatory >standard in this country. This is false on its face. Please support the notion that crypto which, somehow, becomes illegalized in this country would be allowed to be manufactured for export purposes only. That's absurd; it's like imagining a "gun control" law that banned using firearms in the US, but encouraged everyone to buy guns and ship them to other countries. At any rate, EFF intends to help see to it that Clipper does _not_ become mandatory, nor that non-Clipper crypto is outlawed [pretty much the same in effect]. No ifs, ands or buts about it. Even beyond this, this scenario is completely unrealistic, not least because the best crypto in the world is _already_ available outside the US. No amount of lawmaking is going to stop it, short of destroying every computer, phone line, fax machine and printing press in the country. Even this will not put the crypto genie back in the bottle anyway. Fact is, some of the best crypto in the world wasn't even made in the US in the first place. Ever heard of IDEA? >We believe that the Cantwell bill is a step in the right direction, as >it would remove current disincentives to the development of strong >encryption products by U.S. companies. On this much I think we can be in complete agreement. >But the proposed legislation is not a panacea -- Of course it isn't. Please quote anyone saying that it is. >it would not address the threat to privacy in the United States created by >the Clipper initiative. Export controls on cryptography are a related >issue, but they are not central to the Clipper controversy. The >Administration's adoption of the key-escrow Clipper standard must be >opposed and reversed. Export control reform is indeed central to the issue. Without export controls, the major market-leverage crutch of the entire Clipper scheme is ripped away, revealing the "poor lame beggar" act to be a scam. Law enforcement doesn't "need" the "protection from terrorists, drug dealers and child pornographers" supposedly to be provided by Clipper, any more than the American people need another hole in their privacy. But you know that. If all you mean to say is that the Cantwell bill is not the only way fight Clipper, and will not solve all of the problems, you'd be right. But why don't you just say so, instead of taking this as yet another opportunity for grandstanding? It's unbecoming of an organization on the same side as the rest of us. In closing, I'd just like to say that everyone realizes that Cantwell is not the be-all and end-all of pro-privacy, anti-Clipper action. You can bet I added my signature to _your_ petition, and I hope everyone does, whether it will work or not. Better to have tried and failed that never to have lifted a finger. With that, I must ask you, have _you_ sent in your letter of support for the Cantwell bill yet? If not, it's real easy: State your reasons for supporting the bill, and send them to cantwell(a)eff.org. The results, already numbering in the thousands, are regularly printed out and delivered to Rep. Cantwell personally. With high regard, but a fair amount of exasperation, S.McC. "We must all hang together, or assuredly we shall all hang separately." - Benjamin Franklin, at signing of Declaration of Independence; July 4 1776 -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0