December 2003 - cypherpunks-legacy

French Govt Confirms Plans To Issue Smart Card ID Cards 03/04/94
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Someone sent me this message and suggested I forward it to the List. I'll just send it along via the normal channels. By the wa, this is just one of several indications that non-U.S. nations are just as far along as the U.S. is in moving toward a Surveillance State. I mentioned this a few weeks back, and some List members from Norway, Australia, and elsewhere contributed tidbits from their own countries. Germany, France, and the United Kingdom are very far along in such developments, and generally lack the same kind of civil liberties consciousness that the U.S. has (this is not a criticism of Europeans, but a statement of fact. Lacking robust constitutions--not that the U.S. document is looking particularly robust these days--the police have extensive powers of search and seizure, and of detention, and of surveillance, that even the American Security Apparatus can only envy. The Germans are on the verge of rescinding some constitutional provisions to allow for increased police surveilance. Ironically, the Bundesnachrichtendienst (BND) seeks these powers ostensibly to combat Neo-Nazism and nuclear terrorism, while Neo-Nazi murderers are slapped on the wrist. Read "The Economist" for details of events in Europe, or "Germany Alert," a newsletter out of New York written by German ex-pats to educate the world about the dangers of fascism in Germany and Europe today. The links to Clipper and the "family keys" being prepared for the French, Japanese, and other nations tell us that the key deals have already been cut. Here's the article, this one about France. Subject: French Govt Confirms Plans To Issue Smart Card ID Cards 03/04/94 (fwd) To: tcmay(a)netcom.com Date: Fri, 4 Mar 94 23:05:30 Tim, you might wanna forward this to cypherpunks under the information liberation front. I don't have a list of currently working remailers so I really can't forward it anonymously now. Its scary. > PARIS, FRANCE, 1994 MAR 4 (NB) -- The French government has > confirmed its plans to replace citizen's paper-based ID cards with > credit card-sized "smart card" ID cards. > > According to Charles Pasqua, the French Interior Minister, the smart > ID cards have already been trialled in several regions of France and > will be phased in across the whole of the country by the end of next > year. The new cards are distinctive, Newsbytes notes, owing to their > blue color. > > Initially, the cards can be read by anyone with a suitable card > reader and will include name, address and date of birth > information. Plans are in hand, however, to allow advanced card > readers to link to the French central database and automatically > update the card with new information, such as change of address > etc., as it becomes available. > > According to Pasqua, the main reason for the introduction of the > cards was one of national security, as he noted that, since the > cards began their trials in 1988, more than 500,000 had been issued > and not one forgery had turned up. In comparison, out of three > million paper ID cards issued in 1992, around 10,000 were forged. > > Visitors to France, Newsbytes understands, will shortly be > issued a computerized stamp, including a barcode readable tag > affixed to their passport. Visitors with "right to remain," (a > term applied to visitors staying longer than six months) will be > issued with the smart ID cards in due course. > > Smart cards are all the rage in France at the moment, Newsbytes > notes. Almost all Visa cards issued by French banks are smart cards, > with the electronics supplied by Thomson CSF and other French > technology companies. > > The cards contain details of recent transactions, as well as act > as an "electronic purse" for smaller value transactions using a > personal identification number (PIN) as authorization. "Purse > transactions" are usually separate from the card credit/debit > system, and, when the purse is empty, it can be reloaded from the > card at a suitable ATM or retailer terminal. > > (Steve Gold/19940304) > > >

1 0

Re: more steganography talk
by Peter Wayner 17 Dec '03

17 Dec '03

On Fri, 4 Mar 1994, Jim Miller wrote: > 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). Such is the function of Mimic, available at ftp.cs.cornell.edu in /pub/wayner/Mimic It holds the most promise for steganography, in my oppinion. Unfortunately, it may be difficult to implement, initially. Sergey ------------------------ Sorry to be so distracted. This is a very interesting topic for me, but I've been bogged down with more prosaic topics. I think the Mimic FUnction implementation that I did is a very general standard for steganography. On the current level, it just deals with text, but you can make it do bits by just using the alphabet of just plain {0,1}. Here are the important points about it: 1) If the grammars are made complex enough, they can simulate anything you can compute with a computer. I.e. You can encode data in a Turing-complete way. 2) Even if you limit yourself to plain old context-free grammars, you still have a class of encryption functions that can be as powerful as RSA. I.e. You can show that any general program that can infer the grammar used in a Mimic function can also break RSA. This proof is done by translating RSA encryption into a context-free grammar. 3) If you use Turing-complete grammars, then the result is technically "undecidable." I.e. it may be technically "unbreakable." I don't put much stock in this claim, but it is interesting to note that there is _no_ possible brute-force attack on these systems. I do believe, though, that there could be many practical "incomplete" attacks that worked in general cases. 4) It is still unclear how to generate RSA-level strength with Mimic Functions. The simplest way may be just to encrypt with RSA first. Understanding what makes grammars hard and easy to grok is a hard question. 5) That being said, I think that Mimic grammars are one of the most natural ways to specify steganography. There are many other forms that are Turing-complete, but I think that grammars are one of the most natural ways to specify what you want to happen. 6) The process is slightly difficult to implement, but I've got two running versions (as I've mentioned before on the list). One in C and the other in Pascal. Your choice if you live in the Continental US. It is not clear to me if the software is "exportable". I considered applying to the commerce department to get a free assessment of the cryptographic strength, but then I found out that they were denying licenses to systems that I could break. So they're not a great oracle for these questions.

2 1

Truly Stealthy PGP
by Hal 17 Dec '03

17 Dec '03

Eric points out the difficulty of making a "stealth PGP" which is 100% indistinguishable from a string of random bits. The problem is that we have to encode the RSA encrypted number, m, which is less than n, the RSA modulus. PGP first puts out two bytes of bit length, then m. This obviously won't do, since the bit length is generally much less than 2^16 and so these two bytes are a dead giveaway. However, we could leave these two bytes off and just output m as raw bits, padded to the length of n. The recipient knows n so he would be able to extract m. The problem here, as Eric points out, is that m is less than n, so the high bits of m will look non-random. If the high two bytes of n are, say, 0x0C12, then m's high two bytes will never be bigger than this. This will allow the opponent to do much better than 50% on guessing which files have embedded messages. This was discussed some time back on the pgp developers' list, and at that time the suggestion was made to add a multiple of n to m so that it covered a fuller range of values. The recipient would then just take the exponent mod n and try that. Mathematically, call L the next multiple of 256 above n. (0x10000... in the example above.) We want to choose k so that M = m + k*n is randomly distributed between 0 and L-1 if m is randomly distributed between 0 and n-1. This may not be possible in this form. Perhaps there is another deterministic and reversible transformation would accomplish it, though. In that case we would have M = f(m,n) such that f can be reversed given M and n (we can recover m). As a trivial example of this problem, given n=2 and L=3, try to come up with a way to turn a random 0/1 value into a random 0/1/2 value which is both reversible and produces each of 0/1/2 with 33% probability. Seems pretty tough! Hal

2 3

Re: Security through Obscurity
by Hal 17 Dec '03

17 Dec '03

From: Sergey Goldgaber <sergey(a)delbruck.pharm.sunysb.edu> > Well, if we adopt the method of comparing the cost of implementing a > given steganography method to the cost of breaking it as a valid measure of > its effectiveness; then, it would make sense to "maximize" the cost of > breaking it as a means of making the method more effective (ie. making > the method more obscure would make it more effective). I don't think this is a valid measure of steganography's effectiveness. I proposed my own measure, which I think is valid. I think the fundamental problem with your measure is that it counts a system which is easy to break but very easy to implement as effective. I would count such a system as ineffective. > > Instead, if you are going to adopt this goal, this means that the test of > > your steganography is whether the opponent can extract the message. It's > > not that your goal is to "maximize his difficulty". It's that your goal is > > to stop him. Again, NoStO emphasizes clear statements of your goals and > > costs. > > The more difficult it is for one's opponent to extract the message, the > more effective the method is. Thus, "maximizing his difficulty" is a > valid goal. As I see it, this is a goal of most encryption systems. To > make decryption as difficult as possible, if not impossible (ie. maximum > difficulty). I don't think this is right either. The problem is that "as difficult as possible" does not allow for a measure of success. Something which is "as difficult as possible" may nevertheless be useless. This whole notion of maximizing difficulty as a goal is completely misguided. The correct goal is to achieve secrecy. If you have not done that, then maximizing difficulty is pointless. Your goal in making a parachute is to create something that will land you safely. It isn't to "maximize slowness of fall". Suppose I made a parachute out of lead, designing it to maximize slowness among lead parachutes. Will you jump out of an airplane with it? I'd think not. The problem is that this is the wrong goal. > I do not think you have understood _my_ essay. My proposal was for a > default, variable offset in certain steganography applications. The > benefit of this is obvious: having no offset or a non-variable offset > would make for generally poorer security; as, the effort required in > figuring out where one's file is located is nonexistant. Effort > increases when a variable offset is implemented. OK, let me ask this: what is the harm done if the opponent guesses the right offset? How bad are things? Some of your security has been lost. How much? Suppose your stego method is not completely invisible and does give away its existence to some extent. Would you still use it if protected by your offsets, or would you refrain until you had an undetectable stego? How much would you trade off the protection provided by your offsets against the protection provided by undetectable stego? Suppose I am a naive user of your program asking these questions. When I receive a stego'd file and put it on my disk, should I re-format it to change the offset? How much security does this gain me? Is it worth it? Should I have more than one public key, so that the opponent would have more offsets to guess? How much does this help? How much should I worry if I think I may be targetted for surveillance, which would increase the chance of them trying my keys as the offsets? Should I avoid controversial issues, keep a low profile, so that I can prevent this from happening? How much should I trade off against the benefit of making my offset less likely to be tried? I think if you are seriously proposing that your offset scheme adds security, you need to be able to answer questions like these. If it really adds security, you must be willing to pay a cost to achieve that security (recall the NoStO principle: count your costs when you count your benefits!). If you can answer questions like these then you are not violating StO, in my opinion. Hal

1 0

Meeting in Seattle?
by Ophir Ronen 17 Dec '03

17 Dec '03

Morning(or whatever fits your time zone) all, Is anyone in Seattle setting up a link for the meeting? If so, please let me know. Thanks, -Xeryus

3 2

Re: Update on user-level hack to do telnet encryption posted recently
by Graham Toal 17 Dec '03

17 Dec '03

As for this current "idea", with an implementation of an encrypted STANDARD telnet already written and likely available soon for anonymous FTP, I think I'm being sane, not "a wet blanket". You can already get a version of the Cray telnet that implements the authentication code and hack in a reimplementation of the encryption code if you wish. See below for that. However, producing silly non-standard telnet hacks makes little sense. Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with the BSDI distribution (original code in the US, a re-implementation on supplementary floppies in the UK) - I've had it for half a year now, and you know what? - it's of no use to me at all. Not *one* of the dozen odd sites I telnet to is running it. Maybe in several years time we'll all be running the same encrypted telnet, but for now I want *something* to keep the nosey little kids from reading my packets and if I have to ftp a short source and compile it every time I log in somewhere then that's what I'll do. I bet my telnet sessions are secure a lot sooner than yours are. The degree of that security depends to some extent on how much help I get implementing a stream cypher because I'm not sure I trust myself to do it properly. So I would really appreciate if you don't think this project is worthwhile, that you simply don't contribute rather than going out of your way to encourage others not to as well. G

2 1

Stego in Jazz?...The Miles Files
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Straightahead jazz fans take note! More significant bits follow: * Critics who claim jazz = noise now will understand that jazz evolved in the 1940s as a stego method for communicating with agents in the field. * Hitler was right in suspecting "that Negro music." * Agent Parker developed method of putting signals in Bird calls, with great sax appeal. * Unveiling below of "crypto-jazz" movement. Cryptids are spreading the PGP word. Jazz raves to be the Next Big Thing. From: esharp(a)panix.com (Elliot Sharp) Newsgroups: rec.music.bluenote Subject: crypto-jazz Date: 3 Mar 1994 12:10:51 -0500 Organization: PANIX Public Access Internet and Unix, NYC Message-ID: <2l55mr$b5s(a)panix.com> Summary: a night of Keywords: Sharp,Ribot,Berne on Tuesday, March 15, the Cooler (416 W. 14, NYC) will present a night of crypto-jazz with: 10 pm Elliott Sharp's THE CRYPTIDS (Sharp-reeds, guitar w/ Reuben Radding-bass, David Gould-drums) 11 pm Marc Ribot - solo guitar 12 am Tim Berne's BLOODCOUNT (Berne-reeds with quartet)

1 0

Update on user-level hack to do telnet encryption posted recently
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

OK folks, I've started tidying up that hack code I posted recently which outlined a method for rolling your own telnet-style encryption. In particular, I've done the hard bit of making it work with an arbitrary binary 1:1 stream cypher, rather than the original hack which *had* to encrypt printable text as printable text (to get it through 7 bit terminal links). [Note, anyone who didn't look at it too closely because they thought it was only for telnet - look again: it's useful for *any* local to remote connection, even kermit down a serial line, as long as you're calling between unixes.] Now, what I need are volunteers - preferably outside the US and any other country where any relevant patents are valid - to work on a suitable stream cypher. Note you don't have to use any patented technology, as long as whatever you come up with is sufficiently secure for your needs - this will eventually be issued as a modular system, with the default encryption module being rot13. If you don't really care much about the strength of encryption (assuming your only opponents are kids who sniff packets who won't have enough crypto experience to decode even an trivial cypher) then there's a lot to be said for everyone implementing their own variation... just for the amusement of tying up the time of all those more competant people who feel they have to know everything that's going on everywhere in the world. Machine cycles they can afford aplenty; man years are a different question... Anyway, back to the project: Currently there's a trivial interface that you can work to - I suggest for demo purposes just using a hard-coded known key at each end, and we'll do the key exchange stuff after we've got the stream cypher working. Here's the header file: /* Placeholder module for arbitrary stream encryption */ #define STATE_SIZE 128 typedef struct cypherstate { char *unique_tag; char whatever[STATE_SIZE]; long int byteno; /* Add useful stuff here as need be... */ } CYPHER_STATE; void new_cypher(CYPHER_STATE *s, char *unique_tag); char stream_cypher(CYPHER_STATE *s, char byte); Put any state you need in the struct, initialise it (with a known secret key for now) in new_cypher; and supply a function that does a 1:1 encoding of a byte in stream_cypher. Make the function stateless apart from the CYPHER_STATE parameter so that it can be used to encode multiple streams without interference. With a bit of help from you guys, this project shouldn't take more than a week to get a prototype running... When I have a feel for what sort of encryption methods people want, and how precisely they're implemented, I'll know better how to generically code the key-exchange part too. I don't think it's appropriate for me to post any more source over the net. Anyone who wants to discuss this in public rather than by mail, I suggest we stick to alt.sources.d Anyone wants the current sources, send mail to gtoal(a)an-teallach.com Thanks G PS The sources I have probably won't work anywhere except on BSD systems. If you want to make the framework bit work on other versions of unix, drop me a line about that too. Your programming will have to be up to the level of writing a clone of the unix 'script' command, which is all this program is really. PPS Americans: please don't get either you or me in trouble by mailing me unsolicited gifts of crypto code. I don't want it. The crypto part of this project is for those people in countries where there's no legal barrier to them participating.

2 1

Seattle Times, 3/6/94
by Matt Thomlinson 17 Dec '03

17 Dec '03

The Seattle Times' front page story (1984 + 10 years) leads into a few articles on pg 18 that deal with encryption/clipper/privacy. Paul Andrews seems to have a _few_ misconceptions about exactly what the clipper chip will do, but all in all it seems like a good wake-up call. This article is the first in a series in privacy, it says. I'm glad something like this made the front page. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

1 0

Looking for listserver
by Syl Miniter 803-768-3759 17 Dec '03

17 Dec '03

i am interested in setting up a listserver and I would appreciate it if someone can point at a source of some basics on the Internet thanks Syl

2 1