December 2003 - cypherpunks-legacy

RIPEM & MacPGP
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

I have a friend that uses RIPEM and I use PGP if he sent me his RIPEM public key ther wouldn't be any problems between the 2 would there? Any opinions on which is the better program(seems like PGP is, RIPEM is still kinda raw) Reuben Halper PGP key available on request

1 0

Having Meetings is the Most Important Issue
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

(I sent this off several hours ago and it still hasn't appeared at my site, so I'm sending it again.)

1 0

Re: Standard for Stenography?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Hal Finney writes: > Bill Stewart, Norm Hardy, and other list members who have more experience > and who have discussed these issues in the past will I think agree that the > correct approach is to separate the function of the steganography program > to be a simple and clean insertion, and to have other components be > responsible for assuring that what is inserted is statistically indistin- > guishable from what is replaced. It's somewhat of a tradeoff, though, since you really *do* need to have the system be convenient enough to use and standardized enough that everybody will use it. My own programming approaches tend to solve this through reasonably clean programs connected by shell scripts or C frontends grossly infected with Creeping Featurism; the faults of this widely-used approach are well-known (:-). The important decisions, in my opinion, are whether to have an explicit stego program or something that appears to be more general-purpose, and whether to make sure the cyphertext you're hiding looks random. If you're going to have an a program that admits to doing stego, the main risks in having it do a fancy job are detectability and portability, and it sounds like Jef's handling that well. And Xenon's ranting has helped encourage someone to release Stealth-PGP:-) so that's good. Carl Ellison's "tran" program takes an interesting approach for data scrambling - it takes a simple checksum of the first N bytes of the data, which is order-invariant (I think it was a byte-wise XOR?) and uses it as a random-number seed for scrambling blocks of data; it's easy to reverse because the checksum is the same after scrambling. (I forget if the scrambling is also a self-inverse or not, which lets you use one program for both directions; wouldn't be too hard to do.) That might be a clean approach if you're still looking for a satisfactory scrambling method, though you could also do bitwise things instead of bytesized, since you have to split the text out into bits for stego anyway. Bill

1 0

Re: Need info on Encyption book
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> >Has anyone heard of this book [_Top_Secret_ - Data Encryption Techniques] and > >is it with the $19.95 that they want for it? > > Only if you have a pressing and immediate need for a doorstop, or need > special help solving the "Cryptoquotes" in your local paper. If I'm not mixing it up with a similar book I saw in the store, I wouldn't be *quite* that negative; I'll comment on the two together. They're not academic books, and if you're using PGP there's not much you'll gain from them. The big weaknesses I saw were: - not mentioning that the techniques discussed are way outdated and easily broken by professionals (they tend to say this for the simpler methods, just not for the more complex ones.) - not discussing the *existence* of mathematical crypto techniques; it's ok not to go into details, depending on the scope of the book, but there should at least be pointers to the topics. One interesting feature of the books I looked at was that one of them came with a floppy disk with code on it. I didn't notice anything on the first few pages about "Not for export" or a mention that the government treats crypto as munitions that need special permits to export - I assume the authors are unaware of this, or that the NSA doesn't really care about this level of crypto any more than they care about rot-13 being exported :-) - but you'd think the publishers would notice.... Bill

1 0

Re: Standard for Stenography?
by smb＠research.att.com 17 Dec '03

17 Dec '03

I welcome any and all of Bill Stewart's comments on this issue. I have, since the beginning, noticed a distinct dislike of "security-through-obscurity" among the senior members of this and other similar lists/newsgroups. Many people preach this dislike. Most don't seem to understand its foundations fully; neverthelless, they consider it a closed issue and usually don't bother to explain why. Obscurity is certainly a help. Attacking an unknown system is very much harder than attacking a known one. And everyone in the business knows that. However -- in the real world, as opposed to an academic exercise, you cannot keep an algorithm secret forever. Partners will betray you, spies will steal copies, enemies will capture them. Do you trust everyone on cypherpunks? Should you? If your algorithm is not strong enough to withstand an attack by an enemy who has captured it, you're in trouble. And although you can replace the algorithm, it's a lot harder than changing keys -- good cryptoalgorithms take a *lot* of work, and the details often matter a lot. Besides, your old traffic will then be readable. Security through obscurity is more than a buzzword. It's a necessity in this business. --Steve Bellovin

1 0

Re: Standard for Steganography
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Jef Poskanzer writes: > The problem is the length field - you've got to have it, and it's > recognizeable because it begins with a run of 0s. [several hiding approaches.] Actually, you don't really need it, at least for PGP. PGP messages keep track of how much real stuff the message has, and ought to be able to do the right thing if there's extra stuff at the end; I'd guess that Stealth-PGP can do the same. I realize PGP isn't the only thing people will want to hide, but most things need hiding have enough structure to them thatpadding wiht garbage at the end is no problem. On the other hand, if you do have a length field, you do have to do something reasonable with it, and just putting it at the beginning makes it difficult to do other stuff with the stego program, like inserting text bitplanes into a picture.... Bill

2 1

Re: Standard for Stenography?
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Sergey writes: > I have often heard it said that one should always assume that one's > opponent knows everything except one's secret key. To me, this makes no > sense! If your opponent is good enough and determined enough to get by > all the layers of obscurity you may have put up, than its just one more > step to getting your secret key. If your cryptography methods are good enough to withstand an opponent who has full documentation of your algorithms and methods, lots of funds, and everything except your keys, then you don't need to waste your time with all the other stuff. And if you can't protect a couple of keys, it doesn't really matter how much other security you have. On the other hand, steganography is almost by definition an obscurity technique, and while security-by-obscurity is a naive waste of time, obscurity-by-obscurity is hard to argue against real clearly :-) On the other hand, if your cyphertext looks like random bits anyway, it doesn't take a lot to make them invisible. The real need is to make your data look like Somebody Else's Problem.... Bill

5 9

Re: Standard for Stenography?
by Jef Poskanzer 17 Dec '03

17 Dec '03

Eli makes a reasonable case for leaving out the length field altogether. The desteg program would produce a file of width*height bits, and it would be up to the next layer to produce text from that. However, I'm not sure it's a *compelling* case. If adding the length doesn't actually hurt security, I'm inclined to keep it. >Tangentially, why choose bit permutation for your second-level >encryption? There are plenty of schemes that will be a lot faster >than doing all that bitmangling. Slowness is not necessarily bad - it also makes it harder for attackers to search through large numbers of images for ones with hidden data. But the main thing that the permutation gives you is that it spreads out the data bits among unmodified bits, making statistical tests harder. For a 1000 byte message in a 640x480 image, only 2% of the bits will be changed. If that 2% was all jammed into the first 80000 pixels of the file, it might be detectable; if it's spread evenly throughout the file, it's probably safer. --- Jef

2 1

Mail server for crypto files on csn.org?
by exabyte!smtplink!mikej＠uunet.UU.NET 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Problem: the time-varying directory name changes too fast for reliable mail server access to the crypto software on csn.org:/mpj/ for those who don't have live ftp access, but are legally qualified to get that software under the ITAR. It IS possible, but you have to get README.MPJ then request the software right away (before I log in to csn.org to check my mail the next time -- usually one to three times a day whenever I feel like it). Proposed solution #1: change the ITAR. Unfortunately, I can't do this unilaterally. Write your Congressional Representative about changing the ITAR. Proposed solution #2: set up a "secure" mail server on csn.org itself. My idea is to have a filter program scan incoming mail for requests for crypto programs. The request would have to contain a statement that the requestor won't break the law, as well as the names of the files requested. If the mail scanning program is able to detect a valid destination for crypto software, it could then mail uuencoded or radix-64 encoded copies of the software requested in the message. Here is where I confess some ignorance and ask for help: How do I do this? Could someone send me source code for any automatic mail handling programs they have written for a Sun host, or perhaps point me at some good documentation? I could probably muddle through this in time, but I'm not to proud to accept a head start. ___________________________________________________________ |\ /| | | | | \/ |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 iQCVAgUBLXYgQj9nBjyFM+vFAQFccQQAo/zjyDzpsH0Ik1pGI6D+0ST8M7I84TYe /O9rqZRc4HpX5N4htPML9dm6+RrJoNzm9vXvxqhdptAB1nxzkRJgnVpTtH9nhFAM 6hX5k52H2t4Htq5diuAtk31CQG8t0GzA7iJ1qVhqwMG/pgoddRoX+cyVd5rdzX9j TN5+NZYugbU= =nSyZ -----END PGP SIGNATURE-----

2 1

Re: Security through Obscurity
by Hal 17 Dec '03

17 Dec '03

From: Sergey Goldgaber <sergey(a)delbruck.pharm.sunysb.edu> > > To sum up, obscurity is not bad. What is bad is to confuse obscurity > > with security. > > If I have understood you correctly, there is nothing wrong with equating > obscurity with a practical, albeit temporary, increase in security. > Equating obscurity with ultimate security is a mistake. As is equating a > "strong" algorithm with ultimate security. I would not put it like this. Rather, if you want a temporary increase in security, you need to calculate, or at least assume, how much extra time it will take for your opponent to defeat your temporarily-secret information. Just saying, "oh, well this complication ought to slow him down some, heh hey," doesn't cut it. Again, you need to be explicit about exactly what information you are keeping temporarily secret, and how long you expect it to be kept secret. > > In encryption, the opponent's desire is to find out the original message. > > What is the opponent's desire in steganography? I feel it is to be able > > to prove or determine with some degree of certaintly that there is a > > hidden message. We use steganography in a context where sending such a > > message openly is for some reason undesirable. Hence our goal is to > > prevent the opponent from knowing that a message exists. > > I would like to propose that there is a goal, in addition to those you have > revealed, for the opponent as well as the legitimate user of steganography. > The opponent would, ideally, wish to not only determine that there is a > message within the data; in addition, he would prefer to be able to extract > that message for analysis. Therefore, I believe that it would be to the > advantage of the stego-user to not only hide the existence of his message, > but to do so in such a way that the cost of successfully extracting that > message, by his opponent, is maximized. > I think this is a plausible, although less ambitious, goal. But what's this about "maximizing cost"? Where does that fit into the analysis? This does not tell you whether your "maximization" has actually helped or not. 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 reason I say this is less ambitious is that if the opponent can determine there is a message, but not what it is, they may be able to bring penalties to bear on those communicating, depending on the circum- stances. For example, finding a stego'd file on someone's hard disk might represent probable cause that illegal encryption was used, in some hypothetical future.) > I have to take exception with the assertions made in this paragraph. > Using the principles of public-key systems, the steganography key itself > does not have to be kept secret. The sender, reciever, and indeed the > opponent would all have access to this key without compromising the > security of the system. The challenge, for the opponent, lies in figuring > out which public-key the sender has used. I have no statistics on > exactly how difficult this challenge would prove; but, considering the > number of public-keys currently availiable and projecting several years > into the future, the challenge may be a very significant one. What key are you talking about here? The public one? That is not secret. As you say, the opponent has access to it. Are you assuming that the opponent cannot guess which public key was used? How will you measure the accuracy of this assumption without statistics? I really don't think you have understood my essay. The point, again, of avoiding StO is to make it clear what you are keeping secret, and to count the costs of keeping it secret. If you are counting on keeping secret the recipient of the message then you have these costs: Any stego files found in the recipient's possession are broken. Stego files can be exhaustively searched against a list of public keys. If a particular group or person is targeted for surveillance his keys can be used against all widely-known stego channels. Further, your own test is so weak (inability to recover the actual message) you have not attempted to make it impossible to guess when you have recovered the message, even with the correct key information. So in each of the cases above the authorities know when they have the message in hand. Now if you are tempted to say that this isn't true, because we could arrange for the message ALSO to be unrecognizable even when successfully recovered (so that the opponents don't know when they have recovered it) then you have missed the whole point. You earlier rejected this test. If you had accepted it, you wouldn't have needed your keys at all. Hal

2 1

Right to vote
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

There has been some discussion over the last week about what is a 'right', and whether the right to vote is a right or not, as the basis is a ruling by the Supreme Court. However there seems to be strong support for the right to vote in several amendments. Apart from the lenthy 12th amendment describing the process of electing Presidents and Vice-Presidents, there are: Amendment XV (1870) Section 1. THE RIGHT OF CITIZENS OF THE UNITED STATES TO VOTE shall not be denied or abridged by the United States or by any state on account of race, color, or previous condition of servitude. Amendment XIX (1920) THE RIGHT OF CITIZENS OF THE UNITED STATES TO VOTE shall not be denied or abridged by the United States or by any state on account of sex. Amendment XXIV (1964) Section 1. THE RIGHT OF CITIZENS OF THE UNITED STATES TO VOTE in any primary or other election for President or Vice President, for electors for President or Vice President, or for Senator or Representative in Congress, shall not be denied or abridged by the United States or any state by reason of failure to pay any poll tax or other tax. Amendment XXVI (1971) Section 1. THE RIGHT OF CITIZENS OF THE UNITED STATES, who are 18 years of age or older, TO VOTE, shall not be denied or abridged by the United States or any state on account of age. Note: ele tronic versions of the US and other constitutions are available through gopher, or ftp at wiretap.spies.com, Gov/World. Many international treaties and other UN and government documents are under the Gov/ directory. ----------------------------------------------------------------------- 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 -----------------------------------------------------------------------

1 0

Re: PC Expo, Mac World, Comdex, etc..
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Absolutely. A Mac version would be great. (My main machine is a Mac but keep in mind that unless we target Mac World Expo, 99% of the atendees will be PC folks.) Actually if you do your stack any time soon, please send it my way so I can "port" it to the PC somehow. (Probably, just by grabbing pictures and stuff...) BTW: Speaking of vapor ware, I'm making some progress with the SecureDrive like thing for the Mac.... I feel like I'm walking through molasses when reading about the extents file in Inside Mac, but I'll eventually have it sink in my brain and get something to work. (Incase you aren't familiar with SecureDrive, it's a device driver that automatically encrypts a whole partition.) The driver I'm working on will use a file to store the encrypted volume on. Once the drive is mounted anything stored on it is secured. I'm going to leave the crypto code open. I'll probably provide a module for DES and IDEA, and leave some open specs so others can write their own modules and stuff. I'd encourage others to use these modules in other software that they'll write... They're basically stand alone code. I haven't decided if the crypt modules will be just code resources or INITs with Gestalt selectors installed. Depends on how feasable the stuff is with drivers... Anyhow, enough on vaporware. Two things to add to the Mac version of this disk: Curve Crypt, and Mac PGP. If you know of any other Mac stuff to throw in, please do so. I strongly sugggest we use 1.44Mb disk since Apple is braindamagedly trying to push new drives that won't support the old 800K GCR disks. :-( HELP REQUEST: If anyone knows how to read a file off a Mac HFS volume using sector reads/writes or knows of sample code (C, Pascal, Basic,68000, etc.) please send it my way. Basically I need to figure out where a file lives in terms of sectors and blocks. Hint: you can't call FSRead/FSWrite from a disk device driver because the file read/write routines are non-reentrant.

1 0

Re: PC Expo, Mac World, Comdex, etc... (fwd)
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Export of "Top Secret Data Encryption Techniques"
by mpjohnso＠nyx10.cs.du.edu 17 Dec '03

17 Dec '03

> >Has anyone heard of this book [_Top_Secret_ - Data Encryption Techniques] and ... > One interesting feature of the books I looked at was that one of them > came with a floppy disk with code on it. I didn't notice anything > on the first few pages about "Not for export" or a mention that > the government treats crypto as munitions that need special permits > to export - I assume the authors are unaware of this, or that the > NSA doesn't really care about this level of crypto any more than > they care about rot-13 being exported :-) - but you'd think the > publishers would notice.... I was curious about that, too, but found out that the NSA declared it to be exportable. Note that there is no requirement that exportable crypto be marked as such. I've looked at the stuff in the book, and determined that I could probably crack most of it if I cared enough and had a fast computer. I also found that the author made a mistake in implementation that could cause some messages to not decrypt even if you have the right key, if you have a different brand of math coprocessor than the sender had. ___________________________________________________________ |\ /| | | | | \/ |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 | | ||| \ \_/ |___________________________________________________________|

2 1

Security through Obscurity
by Hal 17 Dec '03

17 Dec '03

Security through Obscurity Here's my view of the problems with the security through obscurity approach. First I'll discuss encryption, then steganography. I use StO to mean "Security through Obscurity". It's true that obscurity can't hurt and might help. If you can not only keep your key secret, but your algorithm as well, then the attacker will have a much harder time breaking your encryption. And traditionally this has been done. I understand that much of the work in breaking the codes during WWII was involved in finding out the algorithm; once that was done then finding the keys was a considerably smaller problem. I think the the "No StO" maxim refers to a design methodology for the creation of cryptographic algorithms. In this technique, you divide the algorithm into those parts which must be kept secret, and those which don't have to be. The parts you keep secret you call the key, and you accept that you will have to take extreme measures to protect those secrets. The other parts are less protected. In other words, you conceptually draw a line between those parts which have to be protected at all costs, and those which don't. You then analyze the algorithm's strength on the assumption that the secret parts are kept secret. You also carry out the analysis on the assumption that the non-secret parts fall into enemy hands. In the end, an algorithm is judged on this basis. In the context of this design technique, StO would refer to the hope that the non-secret parts are also kept from enemy hands. While this may be desirable and beneficial, it breaks the rules of the method. The advantage of this method is that it allows you to do a clean cost versus benefit analysis. You calculate the cost in terms of what it takes to keep the keys secret, and you calculate the benefits in terms of how much security you gain if you keep the keys, and only the keys, secret. To also give credit for the additional security of keeping the non-key portions secret, you would also need to calculate the costs of keeping those parts secret. Since historically it has been very difficult to keep all parts of a cryptographic method secret, one has to consider these costs to be very high. Avoiding StO means avoiding falling into the trap of counting the benefits of keeping the non-key parts secret without counting the costs. In this light, there is no inherent violation of the NoStO principle in a cryptographic system which keeps the algorithm secret. It simply means that the algorithm has to be considered as secret as the key, and protected just as securely as the key is protected. In many circumstances this would be excessively costly but in some limited situations it may be practical. As long as you fully recognize that this line between the secret and the non-secret portions is drawn to put the algorithm on the "secret" side, you are properly avoiding StO. In the context of commercial or public-domain cryptographic algorithms, it is basically impossible to keep algorithms secret. That is why any cryptosystem of this nature which relies on a secret algorithm is scorned as violating the NoStO principle. It is generally not practical to expect to keep a secret which is made widely available. To sum up, obscurity is not bad. What is bad is to confuse obscurity with security. Now, in the context of steganography, we should make clear what problem we are trying to solve. There are several components to this problem, but I will focus just on the last step: hiding one bit pattern in another. Generally we do this by replacing some of the bits in the target data with bits from the data we are hiding. In encryption, the opponent's desire is to find out the original message. What is the opponent's desire in steganography? I feel it is to be able to prove or determine with some degree of certaintly that there is a hidden message. We use steganography in a context where sending such a message openly is for some reason undesirable. Hence our goal is to prevent the opponent from knowing that a message exists. 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. Now, how does the NoStO maxim guide our attempts to evaluate steganographic algorithms? Again, the basic principle would be a need to separate that which would be kept secret from that which would be publicly known. Any system which relies on keeping secret some information which must be widely disseminated is not correctly accounting for costs when it touts its benefits. In the systems we have been discussing for a layered approach to stega- nography, the actual embedding step has no secret component. Rather, the message is first encrypted and possibly transformed in such a way that it is statistically identical to the bits which it is replacing. The actual steganographic step simply does the replacement. In this layered approach, there is no provision for key information to be used in steganography. Rather, the receiver of the message has only publicly available data. This means that when we "draw our line" we exclude nothing from the knowledge of our opponent. In counting the benefits of the steganographic algorithm we assume that the opponent will use exactly the same technique to de-steganize the message as our intended recipient will. Therefore, we are forced to assume that the opponent can successfully extract the hidden message. Now, the question that he must still answer is, is this in fact a message or is it just random noise? In order to meet the goal above of making such a guess impossible with better than 50-50 chances, it follows that the message must appear identical to random noise. Any pattern in the message, such as a plaintext header, will make the steganography useless. This is also why proposals to scramble or permute the bits as they go into the data, or to use a special offset instead of the beginning of the data (then wrapping the bits around when we come to the end) do not fundamentally help the situation. By the basic premise above, we assume that the opponent will be able to undo such artifices just as the intended recipient will. This way, again, we count our costs and benefits on fair grounds. Now, it is true that this is assuming that there is no "key" information used in the steganography. The NoStO principle would lead us to investigate keyed steganography, where the receiver has specific secret information which the opponent would not have. But if we are going to do this, we have to accept the costs. That key must be kept just as secret as the keys in an encryption system. We can't just let it be something obscure like a checksum based on a public key, information which the opponent will have as well. It has to be *secret*. That is what NoStO tells us. If we want the benefit of a key, we have to pay the cost. It's not clear whether keyed steganography has any benefits over the unkeyed system discussed above which is used as part of a chain which includes (presumably keyed!) encryption. It would seem that the stego would still have to match the statistics of the bits being replaced, and if you can do that then the unkeyed approach would work. But perhaps there are useful solutions along these lines. The important point, again, is that if you want a secret, you have to keep it secret. Looking at the advantages of a system which benefits if some information is withheld from the opponent without calculating the costs of actually keeping that information secret is the foolhardy behavior which the NoStO principle warns against. Hal Finney hfinney(a)shell.portal.com

2 1

Big Brother Inside pays off
by Matt Thomlinson 17 Dec '03

17 Dec '03

I got a call this afternoon from Paul Andrews at the Seattle Times, wanting to ask me a few questions. After playing phone tag for an hour or so, we got connected. We discussed cypherpunks, steganography, and clipper. He seemed to have a good handle on how scary the clipper (and tessera) recommendations were. I was able to supply him with a little more information (contact #s) and answer some questions he had. His article will be in this sundays' Seattle Times, but it sounds like he may be gearing up to write another. In any case, I'm going to keep in touch. It looks like someone in the downtown area had the big brother inside logo on their windows desktop screen and _that_ is what caught his attention. I'm glad it served the purpose it was meant for -- catching people's attention and making them think. 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

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