December 2003 - cypherpunks-legacy

Re: S314 and potential hell-raising
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

>What other kind of responce other than no compromise should be entertained? Very much agreed. In this type of situation there is no room for compromise. If we compromise, we lose, thus my earlier snipy comment about EFF. They compromised and lost. We cannot do this now, we must win this or it starts going downhill from here. _____________________________________ {-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-} {-: www server: http://josaiah.sewanee.edu/ :-} {-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-} PGP block.

1 0

Re: MIME based remailing commands
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

>Nathaniel Borenstein <nsb(a)nsb.fv.com> writes: > >>Excerpts from junk.interesting: 7-Feb-95 Re: MIME based remailing co.. >>"Perry E. Metzger"@imsi. (2553) > >>> > > It is being remailed via a MIME-based structure where two new >>>content types >>> > > are defined: multipart/remail and application/remail-commands. The >>> > > multipart/remail type is supposed to be composed of two parts, the >>> > > application/remail-commands part which has remailer commands, and the >>> > > other part which is the "payload" to be remailed. > >>Perhaps you might consider writing up an informational RFC to define >>these types? I think that would be very useful. -- Nathaniel > >Well, that was just an example; I was making those names up off the top >of my head in order to concretize what I understood Perry was suggesting. > >I can see that putting remailer commands into a specific part of a MIME >multipart message has some advantages. Right now we are basically >having the remailing commands be mail header fields. But really people >aren't supposed to just make up new fields like that. I think the >"name space" of these fields is protected somewhat more than many other >aspects of communication protocols on the net. Is there precedent for >adding service-by-mail functionality in this way? I am not completely >comfortable with it. And as we think of new functionality and new >commands they all have to get added at this top level, the same >visibility and name space as "Subject", "From", and "To". > >OTOH it does have the advantage that it is easy to do, at least with the >"::" pasting token idea (which perhaps would need to be documented in its >own right). > >If we did use a separate message part we'd have our own little name space >to use, with no fears of conflicting with someone else. (Maybe "Latency" >might be used in a future extension of RFC822 for some other meaning than >what we are using it for.) I am not sure what has to be done to get an >RFC approved but I suspect that adding mail header fields would be much >more likely to hit opposition than adding yet another MIME type. > >What does Mixmaster use for its commands? Does it use "::" followed by >Anon-Send-To: and such? Or some other format? Maybe it should be made >MIME compliant from the beginning. This way we are moving with the >current, the flow of the net, rather than across it. > >Hal With Mixmaster, everything is hidden inside the encrypted and ascii armored message structure. I use the :: token to let the remailer know that this is a remailer message of some sort. The Remailer-Type will eventually be used to indicate the version that created the message. It would be easy to add support for MIME. It would just replace the token and version number. All remailing instructions are inside the ascii armor. Note that the block of ascii armor is allways exactly the same length. :: Remailer-Type: 2.0 -----BEGIN REMAILER MESSAGE----- hQCMAgbmF1BLzawNAQP/RFw2/UagugMFPlnJ94KLmhaxDoplzAhNBCxuFRL2fosL V1YnFd2XVckJJ6vTe6DB+POO+V7HEdXkp3sWtjb56Am+/B+tM1TdeC6NPNV4g5PC 15oYl7eD0ZxyjB34GdN5z/C2mOMbvP3k9eK3pn3ffkaXHBt1Y0I9ZieHkE6erxem AAAAusuiqVunPh15+7gttD5pNuIAOFDKfH8NJ39ReSEFAeeiOun6KSneJT+2DJ9Q LbK14WqsBVu1kDaUOHKchE9hPSFfTijTJp7I+GuiuOkDChUzZNZ21xpBS+8xMg58 0i61z9EEf11G0G5JShTaeaGWNd14QxoyrxjTh9PrItOz49M9lSY71KoTP2+fVc0h xDGHw7iVeeToOtFqmDBI14FOVJz2rYuMu7vTD+MTwP3INkraCXqTeBoJ7g31Nhqj <SNIP> LbK14WqsBVu1kDaUOHKchE9hPSFfTijTJp7I+GuiuOkDChUzZNZ21xpBS+8xMg58 0i61z9EEf11G0G5JShTaeaGWNd14QxoyrxjTh9PrItOz49M9lSY71KoTP2+fVc0h xDGHw7iVeeToOtFqmDBI14FOVJz2rYuMu7vTD+MTwP3INkraCXqTeBoJ7g31Nhqj VYbH5jxvKPjF4HEaS++MaBwTvzBkEKxbS+6oh7G/ndkHBxA7d7C0sx+qX9sjJyAs OIpGERZYA9RVspXUWys5fihnwrhk90dDAVZb8hTsPQfTXLp4 =ouPq -----END REMAILER MESSAGE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

2 1

(fwd) OREGON HOUSE BILL 2319 - Outlaw Anoniminty??
by skaplin＠mirage.skypoint.com 17 Dec '03

17 Dec '03

Damn!! Has this been a crappy week!!! Sam Path: skypoint.com!scipio.cyberstore.ca!math.ohio-state.edu!howland.reston.ans.net!news.sprintlink.net!uunet!news.fc.net!ima!libertybbs!terry.liberty-parker From: Terry.Liberty-Parker(a)libertybbs.ima.infomail.com (Terry Liberty-Parker) Date: 09 Feb 95 08:26:51 Newsgroups: comp.org.eff.talk Subject: OREGON HOUSE BILL 2319 - Message-ID: <ff3_9502091822(a)ima.infomail.com> Organization: Austin InfoMail Association - Austin, TX Lines: 112 -=> Note: Forwarded (from: LIBALERT) by Terry Liberty-Parker using timEd. Originally from ERIC GRAY (76:48/200.0) to ALL. Original dated: Feb 05 '95, 03:42 This message was from LES LEMKE to ALL, and was forwarded to you by ERIC GRAY. ------------------------- ( HB 2319 Page 1 ) 68th OREGON LEGISIATIVE ASSEMBLY - 1995 Regular Session HOUSE BILL 2319 Ordered printed by the Speaker pursuant to House Rule 12.00A (5), Presession filed (at the request of Representative Kevin Mannix) SUMMARY The following summary is not prepared by the sponsors of the measure and is not a part of the body thereof subject to consideration by the Legislative Assembly, It is an editor's brief statement of the essential features of the measure as introduced. Directs operators of computer networks to keep records of identity of users of network and of personal information about individuals that is disclosed to users. Requires disclosure to individual when information about individual is accessed by user of network. Sets rules for disclosures. Allows injunction or maximum civil penalty of $100,000, or both, for violation. A BILL FOR AN ACT Relating to computer information systems. Be It Enacted by the People of the State of Oregon: SECTION 1. As used in sections 1 to 3 of this Act: (1) To "access" means to instruct, communicate with, store data in, retrieve data from or otherwise make use of any resources of a computer, computer system or computer network. (2) "Computed' means, but is not limited to, an electronic device that performs logical, arithmetic or memory functions by the manipulations of electronic, magnetic or optical signals or impulses, and includes all input, output, processing, storage, software or communication facilities that are connected or related to such a device in a system or network. (3) "Computer network" means, but is not limited to, the interconnection of communi cationlines, including microwave or other means of electronic communication, with a computer through remote terminals or a complex consisting of two or more interconnected computers. (4) "Computer program" means, but is not limited to, a series of instructions or statements, in a form acceptable to a computer, that permits the functioning of a computer system in a manner designed to provide appropriate products from or usage of such computer system. (5) "Computer software" means, but is not limited to, computer programs, procedures and associated documentation concerned with the operation of a computer system. (6) "Computer system" means, but is not limited to, a set of related, connected or un connected, computer equipment, devices and software. (7) "Data" means a representation of information, knowledge, facts, concepts, computer software, computer programs or instructions. "Data" may be in any form, in storage media, or as stored in the memory of the computer, or in transit, or presented on a display device. "Data" includes, but is not limited to, computer or human readable forms of numbers, text, stored voice, graphics and images. SECTION 2. (1) An owner or operator of a computer network or computer system shall establish procedures requiring each person who accesses the network or system to disclose NOTE: Matter in boldfaced type in an amended section is new; matter [italic and bracketed] is existing law to be omitted. New sections are in boldfaced type. LC 984 [1] --- * Origin: Stargate Oregon - North Bend, Oregon USA (1:356/3) * OLX 2.2 TD * The oldest question known to man: "Where are my keys?!" ___ GOMail v2.0t Beta [94-0145] - Origin: The Desert Reef * LIB * Tuc.Az * V.34 * 602 624 6386 (76:48/200) --- timEd 1.00 * Origin: LibertyBBS Austin,Tx [512]462-1776 (1:382/804)

1 0

NSO Challenge 95 Nr. 1
by Network Security Observations 17 Dec '03

17 Dec '03

*********************************** Network Security Observations Challenge Nr. 1995-001 February 8, 1995 *********************************** Network Security Observations invites the international research community to produce a detailed presentation on the following subject: > Establishment, authentication, and verification of a relationship and untraceability of undeniable secret transactions < Conditions - Party A (Alice) - Party B-n (Bob) - A multitude of Bobs know who Alice is - Alice - being only one party - does not personally know who the Bobs are - It is the desire of Alice to transact - Bob - only producing a certain proof - remains further a static party - At one given time Alice established a relationship with Bob-n - Further, from time to time Alice wants to check this relationship with Bob-n - Alice may utilize the verification process only for this purpose - At a given point Alice might want to terminate her relationship with Bob-n, or vice versa - It is essential that the relationship between Alice and Bob-n is set up so that Bob can prove to Alice that he is the legitimate Bob, but, in such a way that his real identity remains secret for Alice - Alice can only use this procedure to verify Bobs legitimacy - Alice may only verify, but not register - Alice may have the option to repeatedly challenge Bob s legitimacy, but the conditions under which these separate verification checks take place may not be registered as well - Alice now wants that Bob can undeniably prove to her that he is who he says he is, by untraceable number verification, thus without actually knowing the real identity of Bob, and without the ability to utilize the verification process for any other purpose The presentation should include the full theoretical processes, applying known cryptographic algorithms, the theories of undeniable untraceable number verification and secret transactions as developed by Dr. David Chaum (see proceedings Crypto, Eurocrypt, etc.), and envision a practical applicability in a real world environment. The presentations will be judged by a team of seven international experts of senior academic/research level. The best presentation will receive international acclaim (including, but not limited to TV) and a (secret) financial reward of substance. It is essential to register, (name, surface mail address information, affiliation, email address, p-pgp key (optional)). One should do so by sending an email message with this information to: nso(a)delphi.com Upon registration a notification and detailed instructions will be mailed to the individual who registers by surface mail/airmail. There is no limitation as to origin, nationality, position, or seniority of the researcher(s). The presentation may be made by more than one researcher, but a lead-researcher must be registered. Co-researchers will share equally in the benefits, allowing for one extra share for the lead-researcher. There is no set maximum number of pages for the presentation, though an extended abstract must be at least 15 pages, while the full paper must be at least 25 pages in length. The lead-researcher and at least two co- researchers (if any) must be prepared to present the efforts in person during an international conference. Commercial entities/companies may not participate. Employees of commercial entities/companies may participate individually, but must testify that their employer shall have no benefit of their efforts. To allow for proper preparation the deadlines are as follows: 1. registration with NSO: ends on March 1, 1995. 2. proposed presentations (extended abstracts) should be received by NSO on or before August 31, 1995. 3. final presentations must be received by NSO on or before November 30, 1995. The presentation selection/review process takes place in three rounds: - first selection of the extended abstracts - correction selection of first round passed - final selection of remaining passed More details will be available in the next issue of Internet Security Monthly and the next supplement of Network Security Observations. | Network Security Observations - Internet Security Monthly | International Research Journals on | Datacommunications and Network Security | Suite 400, 1825 I Street NW, Washington DC 20006 | United States | Telephone +1 202 775 4947 - Fax +1 202 429 9574 | Internet: nso(a)delphi.com ----------------------X----------------------

1 0

Re: The drumbeat against anonymity continues....
by rparratt＠london.micrognosis.com 17 Dec '03

17 Dec '03

Allen B. Ethridge wrote: > The technology to reduce cellular fraud, through encryption and > authentication, is easily implementable, but for some reason neither > the operating companies nor the manufacturers want it. > > In contrast, European cellular (GSM) products do implement > encryption and authentication (at least as far as laws allow). > GSM mobile phones can be equipped with a slot for a card that > identifies the subscriber. Billing is based on the subscriber's > identity, not the phone's. Actually, all GSM phones use a smart card to ID the subscriber. There was at one point the idea that this card would be useful for other things, e.g. you could plug it into a fixed line phone and have that phone take on your personal number, or even use it as a payment card. However, the desire for ever smaller phones means that the credit card form factor is dying out for SIM cards, and one doesn't want to keep popping a 0.5" x 1" mini-SIM out of the bowels of the phone. GSM uses less than strong encryption, by the way. I forget the technical details, but it is of the level that governments can fairly readily crack, but beyond the reach of most private organisations. (So no more 'Squidgy-gate'). It would, however, be quite feasible to add additional second stage encryption to phones (since the dataflow is digital point-point). I wonder if Nokia, a Finnish company well outside the scope of COCOM, might offer a feature like this. Incidentally, is there likely to be any adoption of GSM in the US in the near future? -- Richard Parratt

1 0

Crusade's End
by Nathan Zook 17 Dec '03

17 Dec '03

Date: Wed Feb 1 20:35:31 1995 From: Rick Busdiecker <rfb(a)lehman.com> Date: Wed, 1 Feb 1995 18:59:54 -0600 (CST) From: Nathan Zook <nzook(a)bga.com> Instead of routing all of those messages to /dev/null, forward them back to the authors, perhaps with a notice that the message appears to have been mistakenly routed to you? And then all LD has to do to have lots-o-fun is to send you a whole bunch of "your OS sucks" messages with the From: line set to alt.religion.scientology(a)some.mail2news.site . . . . Rick Presumably, this sort of censure would occur very rapidly. The script had specific from/to lines it was looking for. Neat idea, though. Nathan

1 0

Frothing remailers - an immodest proposal
by Nathan Zook 17 Dec '03

17 Dec '03

kevin(a)elvis.wicat.com: >Be gentle, though - it's my first time. Here? You jest. ;) >It seems to me that the current remailer web suffers a fundamental flaw. >It is simply too static. When a remailer disappears, service is >disrupted and messages are lost. Humans have to statically route their >messages through the web either by hand or using relatively primitive >tools such as the chain script (not to belittle the useful work that has >been done, but it is by no means idiot proof yet). Basically, the >current web of mailers shows nothing of the dynamic nature that has kept >the internet alive and has offered us a decent chance at truly anonymous >communications, nor is it easy to use to its full potential. > >Consider a more dynamic web of remailers. I envision remailers that >actively advertise their presence on the web so that all active >remailers are aware of all other active remailers. This advertising is >to have very low latency so that a new mailer can be known to the web >within minutes (I will address the implementation of this later). Thus, >remailers can constantly be appearing and disappearing without impact on >the web as a whole (I refer to this dynamic web of remailers as a >"froth"). Imagine also that remailers are allowed to dynamically perform >the routing functions that are currently done statically offline (for >reasons I will discuss shortly). > Some version of this discussion came up a few months ago, and I passed on it then, but I think I've heard enough to comment now: The remailers are based on an inherently different model than the InterNet. Some of these differences, in fact, are crucial. 1) The InterNet is based on mutual cooperation/mutual trust. Cypherpunks trust no one that they don't have to. This is not just a result of our twisted psyche. If we could trust everyone, we wouldn't _need_ remailers. Since we don't even know who is whom out there, we avoid extending trust. 2) The InterNet is concerned first about reliability, and not at all about privacy. The remailers are concerned first about privacy, and can leave reliability to the users, if need be. There is nothing to prevent Alice and Bob agreeing to send each other ACK statements, and retransmitting messages if they don't get the ACK. There has been some mention of remailers doing the same with each other, in an attempt to improve net-wide reliability. BTW, with T1, sending ACKs is not unreasonable between remailers. 3) From 1) and 2). The remailers are heading towards mandatory PGP, possibly nested. All InterNet messages are world-readable--although this may be changing as the model breaks down. Again, this has to do with the intrinsic diffences. >The use of such transient routers implies allowing dynamic routing. If >any given remailer may go down or move at any point, it is impractical >to expect users to keep track of which are up at the moment and create >static routes in the current manner. The only reasonable solution I have >come up with is to allow the remailers themselves to choose routing, >given that they have full knowledge of the current state of the froth. Here we have the real head of the problem, as Hal so asutely points out: in your model, if the first remailer is bad, the message is compromised. If user encrypt to all remailers, they might as well encrypt directly to mole(a)snakeoil.nsa.gov. If they don't, they severly limit who can pick out their messages. In particular, they bypass transient remailers. But that isn't all. If the remailers pick the route, they are in a no better state than the users. Since the flushing attack requires remailers to operate on ticks, with carryover, an hour delay per remailer is almost minimal, untill traffic really picks up. So if some message routes through four remailers, a minimum of four hour delay results. In your case, this could easily move between in/out of service modes. > Think about the proposed extension to MixMaster to >allow separate parts of a multi-part message to be routed separately, >and consider whether you really want to have to do this by hand. I >strongly suspect that most messages are currently routed via boilerplate >scripts, which has to make the job of traffic analysis much easier for >our good friend Eve. Stupid is as stupid does. >By the way, a brief rant on a related topic; people speak of not >trusting remailers any further than necessary, while I am clearly >suggesting granting more authority and trust to the remailers. This >notion of not assigning trust is simply nonsense. When you send a piece >of mail to a remailer, encrypted or not, you are assigning complete >trust in that remailer to keep you anonymous and not to forward your >mail to the NSA immediately. NOT TRUE. With proper use of encryption, you are trusting your first remailer only to not reveal that you sent a message, and not to correlate that message to the one it sends out. With rational use of garbage running two deep, you can even suffer this loss without significant harm. >This does lead to a related problem, however; if we allow remailers to >pop up at random and join in the froth, how do we know that Deitweiller >won't set up a number of black hole remailers that take your mail and >throw it away, disrupting the froth, or forward it to nphard(a)nsa.gov? How indeed? The reason we chain is because we _don't_ really trust our first remailer--or any other. >Fortunately, we already have the PGP web of trust model in place and can >use it to good effect in this case. Remailers should simply not route >mail through any remailer whose public key is not trusted unless >explicitly ordered otherwise. This requires remailer operators to >cooperate to some extent to validate one another's remailer keys, but >does confer the great advantage of portable remailers as mentioned >above; if I run a trusted remailer on one machine, I can move it to >another machine, and as soon as I advertise the new address and the PGP >public key, it is a trusted and useful part of the froth. Actually, there may be something here. I don't know about you all, but my PGP isn't very happy about all these new remailer keys. We could agree to the following standard: Signing a remailers' key means that you believe the remailer to be secure. Trusting a remailer key means trusting the remailer operator to validate other remailer's security. This adds a whole new meaning to the phrase, "key compromise certificate". >While we are advertising a PGP key and internet address, we might as >well incorporate other useful information. For instance, remailers could >advertise their maximum latency. While I agree that it is useful to post the operating characteristics of the remailers, the maximum latency must theoretically be infinite in the standard model to prevent flushing attacks. > Kevin Hal <hfinney(a)shell.portal.com>: >I do like Kevin's ideas about a dynamic remailer net, but I think >another approach would put more smarts into the client program used by >the originator. Hear ye, hear ye! And along those lines... I'm scetchy (at best) by what is meant by "pinging" a remailer. Would it not be possible for live-on-the-net remailers to accept a (socket?) quick check to see if they are online? If so, then the ping would only work if the remailer was active when tried. Furthermore, client software could startup by sending out these pings, and presenting only responding remailers to the user--with an exception list for those not "live". Nathan P.S.: Late breaking weakness: Pinging a group of remailers is strong evidence that you are about to send a message.

1 0

re: Remailer Encryption Module
by Nathan Zook 17 Dec '03

17 Dec '03

From: eric(a)remailer.net (Eric Hughes) From: Nathan Zook <nzook(a)bga.com> I also believe that hacking PGP is a bad thing (tm), because it means that every time an upgrade comes out, it will need to be re-hacked, and once you start hacking, when do you stop? I agree. PGP just does not have the support for the encryption required for mixing remailers. These deficiencies have been known for about two years at this point and still nothing has happened. I expect this not to change anytime soon. That means that we have to replace PGP as the encryption module for remailers. The first thing to do is to design a data format which supports what the remailers need now, and nothing speculative. Since this data format has a single purpose, we can make new revisions more easily than for a general purpose package. Once we get a data format, implementations will follow. Eric As I've considered this problem, I've arrived at essentially the same conclusion. We need an RSA-IDEA package that does something very close to Mixmaster. The only caveat is that we _must_ retain compatibility between signature formats, even though, as I've suggested, a signature on a remailer's key might mean something different than a signature on an individual key. Nathan

1 0

IQ & such
by Nathan Zook 17 Dec '03

17 Dec '03

For what it's worth, I have a tested IQ of 151. While I am capable of being trained to perform certain feats quite rapidly via methods that "average" people don't understand, this is a far cry from the 30-point never-can-be-explained claim made earlier. There is one task that I have observed an intuitive bonus on, but I have _never_ been unable to explain the methods used to anyone that expressed intrest. I once multiplied two 45 (decimal) digit numbers with no intermediate work on a challenge. I claim that my methods could be explained with no trouble to almost anyone who can multiply two two digit number--I believe that they are essentially the standard ones for multiprecision multiplication. Nathan A reasoning machine, in the shape of a man, but with no conscious, is not truly human. --paraphrase from a letter to the Editor in a Mensa publication

1 0

Lucky primes--third time's the charm?
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The algorithm I posted the second time works, (nice improvement, eh?) but is likely to take several thousand years to complete. And when it does, we can expect weak primes. The enhancement I propose should fix that. As I recall, PGP uses 0x10001 for its e. It does so in order to be able to easily determine that e is a primitive root of unity in Fp. Since we are assuming that the p we actually work with is prime, we have: n^p = n mod p ie: n^((p-1)*i+1) = n mod p. So we want ed = (p-1)*i+1, ie: ((ed-1)/i)+1 = p. Let 2*x be the target number of bits in the modulous. We then look for two primes with approximately x digits such than d (for each prime in turn) is small. We know that ed = (p-1)*i+1, so we search for small i's that work. d = ((p-1)*i+1)/e, so for a given p, d will be small iff i is small. But in general, the calculation to invert e is long. We therefore fix ed-- that is our n1--and hope for a small i that works. If none work, we increment d and try again. Once we have a p that gives us a small d, we then count the 0's in d, hoping for a high count. If we don't get it, we increment d. *** That is what my previous algorithm did. Of course, we can expect a halt exactly when d ends with a bunch of 0's, followed by a few spare bits. B-A-D bad. The solution, though, is easy: pick a random high-0 d. Multiply it by 0x10001 to get ed, and search for small i's. If you fail, increment d. Doing so won't affect the number of 0's in d by much, and we expect a prime fast enough that cumlatives won't be a problem, either. *** Let 2*x be the target number of bits in the modulous. GetPrime twice. GetPrime: Let d be a large random number with x-15 bits. If d has too many 1's, pick digits at random and 0 them until d is sufficiently 0-rich. This would include room for extra 1s to appear as d is incremented. Let n1 = d * 0x10001 Let t2 be n1 mod 8, t3 be n1 mod 9, t5 be n1 mod 25, t7 be n1 mod 49. Loop: For i = 2 to 7 If n1 = 1 mod i and (n1-1)/i + 1 is not a multiple of {2,3,5,7} /* This can be done very fast, and eliminates most canidates. */ If (n1-1)/i + 1 is prime, record and exit Loop. /* This would be the long test in RSAREF, or Miller-Rabin. */ EndIf EndIf Next d++ n1 += 0x10001 EndLoop EndGetPrime By keeping track of various quantities, we can eliminate all multiprecision divisions except for the original one needed to get the t's and the first n1/i's, and doing increments instead. Nathan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLzmnanmgMs8UcStNAQECpQf6Ag8PUhiHySvv/lK8dIsmJhknKCuDR0Fi dVT0oVnTijmz1mdX0a6tlhnXyrj+oO4sYLCsej03e+685HZSd5orCYMsMXI/12SU f8PUVbKK7g/tDFYFah0se7cFL4kvQXwnOYDdzmfVnguW82QDDuS0iSssG42mqUKD e0QH1jZKxMK+usRF53P0Bui7goNfk7MkN2hI/ShMQggywcDQHYRX/d3QHkhZp6iG P7rJrW2aRxHYQT9MtiSpOv64Ae1JvmJk4DLXYMhXOSQet8xntRTnm4FIoVStBRmb dTnOj0d//dHyYWWEVKKFz0GoepnglxjQ0/k3PAKvVgPV5DWzn3xFJQ== =PzTo -----END PGP SIGNATURE-----

2 1

Re: Why encrypt intra-remailernet.
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I was finally able to read Lance's stuff. Great work! Ironically, I arrived at the conclusion that his methods are necessary just before downloading my mail (including his stuff). With that in mind, I have now a new DRAFT: model. I anticapate continued discussions on this matters mostly under that topic. Also, could you send me a copy of Chaum's paper? I don't have metamail, but I can convert GIFs, if you could send it PGP -a. Thanks!!!!!!! > From: Nathan Zook <nzook(a)bga.com> > [ Re: remailers checking signatures on incoming messages ] > > What benefit does Alice gain? > > 1) Plausible deniability. Remember, "reasonable doubt." Remember Abscam? > > The gov't is in a good position to fake source info. This squishes > > that. (It squishes even better if Chaum _requires_ signatures.) > > She doesn't get that. A signature lets her prove that she sent a > message. It doesn't let her prove she didn't send a message. > If Chaum only accepts validly signed packets, she can. (Or at a minimum, the government must demonstrate that she compromised these other keys.) > > 2) If Chaum sends Alice a copy of the message that failed the signature > > check, Alice knows that someone is trying to spoof her. This > > information may be critical in determining how serious her opponents > > are. > > I don't really understand this threat that Alice may be "spoofed". Why, > of all places, would her opponents try to spoof her through an anonymous > remailer? Isn't this kind of like sending mail with no return address, > and pretending it comes from someone else? This seems terribly subtle. > It's called "faking evidence". It's a real problem, especially if you are a religious nut with guns. Or just a nut with guns. If the government knows you are using the remailers, and wants to establish that you are using them to conspire, this is the only way to fake evidence. As for hacking PGP, I am convinced that the mixmaster-type remailers require their own package. Coming soon. > I can see the problem with standard packets in a chaining context, that > they would shrink slightly in size as each successive remailer stripped > off its envelope. Re-encrypting would solve this by providing more > padding. OTOH you can actually stick padding into a PGP packet if you > know what you're doing. I have a perl script around somewhere which will > do this. > But padding is worthless if Eve runs some of the remailers. I know I just changed the threat model, but stay tuned... > > The most obvious one: Eve checks messages (in vs out) for matching tails. > > If the tails match, the messages match. The only way around this is for > > the entire message to be wrapped. Thus, the extropian requirement. > > It is true that encrypting messages intra-remailer would prevent this > attack as far as that one remailer in the chain is concerned. But it > seems to me that the message still suffers from this attack against the > remailer network as a whole. This points up the fundamental problem with > this form of encrypted reply block. They are really not secure unless > the body itself gets transformed at each step as in Chaum's model. > This attack fails if the last link encrypts on the way out, since the session key changes. Bob still gets the dupe message, Eve gets no info. There may be another way to handle dupe messages, stay tuned... > > When I say that the Mark I remailers are laughably easy to crack, I mean > > laughably easy. > > None of this is news. Then why did you say, "Let's not start rumors..."? > > Get stuck? Need a hint? Resend a message. Watch for the repeat on the > > out. > That's why Chaum identified one of the main features of a remailer being > that it would reject duplicates. Mixmaster does some version of this, > although that needs improvement to really meet this attack. > Not if Chaum encrypts to Bob. Chaum encrypting to Bob pushes Eve back to Wei Dai's work. > > Alice has been hauled into court. The Feds claim that she is the one that > > actually sent messages M1,...Mx to Bob through Chaum, even though these > > messages have varied From: (and From) lines. As root, she cannot claim > > that this is not possible. OTOH, if Chaum requires a match, the Feds would > > have to claim that she compromised the secret keys of all of all the > > cooresponding From: addresses. Much tougher. > > OTOH, if Alice actually has signed those messages, her jig is up pretty > good, wouldn't you say? Do we really want to force people to use the > nets in a mode in which they can be incriminated like this by a hostile > government? > I suppose that depends on the threat model. If the gov't has control of all the remailers, she's toast, except for being able to claim that the message was forged. Here, she loses. In all other models, the gov't gains only the proof that she used the remailer net. In and of itself suspicious (some places and times), but presumably _not_ a hanging offense. > > Seriously, if a sight is being shadowed, then it is insecure. It is to our > > advantage to know this. You are right that we "don't care" where a message > > comes from only if we assume that the message _didn't_ come from an LEA. > > (Or a big corporation. Some of them probably have the power to do this, > > too.) > > Hell, Detweiler has the power to do this! He's spoofed messages plenty > of times. How do we know? Because of remailer logging. That's the real > threat, IMO (the logging). > I mean the power to spoof a remailer, in the sense of processing messages for it, possibly altering them. I admit, with intra-remailer encryption, this is equivalent to compromising the key. > > If it did, then the remailer net is under attack, and we most > > definitely _do_ care about that. > > Even if a message comes from a fake address that is hardly evidence of an > attack by a powerful opponent. It could just be an extra-paranoid > legitimate remailer user who doesn't want to extend any more trust than > necessary. > Yes, but... If the address faked is nzook(a)bga.com, then I have something to be upset about, no? > I meant to refer to encrypted messages identical in size and otherwise > opaque, so that your apparent rate of output is constant. > Okay, but in practice we need a lot of garbage. > > >Do you see your suggestion as protecting against Wei's in/out correlation > > >attack? > > > > Yes! Well, not by itself. My suggestions about "rational use of garbage" > > do that. If Bob recieves x messages each tick, 0 to x of which are real, > > Eve is hosed--if all messages are standard sized & encrypted!. Eve is even > > more hosed if the x messages are concatenated & superencrypted. If Alice > > sends y messages each tick, Eve is hosed. Even more so if the messages are > > concatenated & superencrypted. > > How can Bob arrange to receive a constant number of messages each tick? Every remailer knows to send Bob x messages per tick. It's right after his PGP key in the database. > Do all his messages come from one remailer? Or do all of the remailers > which might send to him check among themselves before sending to him so > they can mutually know how many fake messages to send? > Each remailer does its own work. The sum of equals is equal. > IMO the real solution to the correlation attack is to have a constant > message generation rate. That is sufficient. Solutions to the other > attacks mentioned in Chaum are described in Chaum. (This attack was not > described in Chaum's paper.) > But the correlation attack might mean more than just A sending to B. It could be B recieves message, then commits act X. > > >Of course it was Chaum himself in his 1981 paper (which I think is available > > >from the CP FTP site) who described the duplicate-message attack. I don't > > >see that inter-remailing encryption helps much, because the attacker can > > >still notice that whenever they inject message A, _something_ goes to > > >Bob. The real solution, as Chaum pointed out, is that the remailer must > > >reject duplicate messages, even when separated by days. Doing this without > > >keeping a database of all messages ever sent is left as an exercise. > > > > > > > I disagree. If identical input to Chaum does not produce identical output > > to Bob, how does Eve coorelate them? Repeating, she can match the top of > > the body of messages, so random tails reveal the actual encrypted message, > > for whatever that is worth. > > I'm not sure what you mean by "matching the top of the body of messages". > Are you referring to an encrypted reply block, which might be the same > for two different messages to the same user? Or are you suggesting that > messages would have some headers or some other structures at their top > which would be preserved through a remailer? > No. I was refering to your trust in packing garbage on the end of a pgp message. If the headers and bodies are encrypted separately, and the remailers just tack garbage onto the end of the message, you get 12345xyz one time, and 12345pqr the second. Match. > > And if Bob receivs x packets per tick, or a BIG packet every tick, how does > > Eve trace it? > > If the input to Bob really can be made constant across the whole remailer > net then this does seem to largely protect against duplicate-message > insertion, in conjunction with the intra-remailer encryption. However it > would apparently also be necessary for every remailer to send a constant > number of packets to every other remailer. Otherwise a bolus of > duplicates into one remailer would all leave to go to the next remailer > at once and would show up. This means that the net as a whole has to > carry a constant traffic load on all inter-node links, which could mean a > large cost in bandwidth load. > Your analysis, as I see it, is essentially correct. I think that the total load can be time-dependent, but should be even across all remailers on each tick. We need a lot of garbage in the net in order to cover all types of attacks/foolish useage. > No, of course message size standardization is a necessary step. This has > been recognized for 15 years. > So why mention it in this context? > > > It's one thing if I send a message along with thousands of > > >other people, and Bob gets a message along with everyone else. But if I > > >send 10 messages and Bob gets 10 from that batch, that fact alone can > > >help to link us up. So splitting my big message into 10 standard ones > > >isn't that great if they're all sent at once. Ideally you'd want to > > >dribble them out at some standard rate, a rate at which you always send > > >a message whether you have something to send or not. But this may introduce > > >unacceptable latency. > > > > "Dribble them out at some standard rate". Yes. y packets per tick. Set y > > equal to your average number of real packets per tick, plus 3 standard > > deviations. Since you are chaining, the latency of you input will be less > > than the latency of the remailernet. > > OK, but chances are your average number of real packets per tick is < 1, > e.g. if a tick is a few hours and you only send one or two messages > a day. So when you do need to send that 500KB GIF it's going to take a > lot of ticks. > But I said average plus 3 standard deviations. If you know you are going to send GIFs at some point, you make a point of setting you standard that high. BTW, I envision a tick period of 30 minutes to an hour. > I would sum up by agreeing with several points: the need for standard > message sizes, and for a standard rate of message output. I am neutral > on whether a remailer may want to super-encrypt a message to the next > link in the chain (whether a remailer or an end user) if it happens to > have a key handy. I don't see any harm in this and the remailer > software will already handle this transparently on the receiving end. > I disagree with the idea of remailers checking signatures. I don't > agree that inter-node remailer encryption provides significantly more > protection than padding. I think that encrypted reply blocks are > unsafe even with inter-node remailer encryption. See Chaum's paper for > ways that encrypted reply blocks can be used safely. We have also had > some suggestions here for modifications to Chaum's method. And I don't > see how you can arrange to receive a constant load from the net without > a highly centralized system, which would have its own dangers. > > Hal > Hopefully, I made my positions on these matters clear. As I said, I have new ideas, several of which supercede these. Nathan On multiple Request-Remailing-To:'s > I don't follow how requiring pgp wrappers would kill this. Couldn't > he create a remailing request to 10 remailers, wrap that in pgp, stick > on a remailing request to 10 remailers, wrap that... and end up with > the same effect? > Hal Yeah. I realised this right after sending it. Genius that I am. I guess you have to limit the number of remailers in the multiples to 1. Even then, you could end up with a remailer-based spam. (joy) I guess you have to, as a matter of policy, allow 1 remailer and nothing else or any number of others. Nathan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLzmmLnmgMs8UcStNAQHk4Af/Qn+azQ9MDiWEbiQgGSfnn1a7w2xS2ktG RJTEBlVXAduurz7e+DGxS4ggfvtU61QVpn/rJkM7Q5vk2gZMzdb0v6f9sMkex8ew tFFMLf2Q9JXlahONyxiW5yLWHdOjpj18Gf4jfGWVM9DZxWwaA25l8x/qROEzg1Hi TM04/mmF+yJVLHJLfyxSTG6d2oaXpbOMsbwwosvWc91iCTA5QqSFNpQFIRqWQE3n UKl9+Ym9I93hfJiLL3xvnBrfZQZC26DMZUugoxTUaXfWjUiSeDlc2b0UBpSOn/VN FTPr9C5Wa4rDC8gT8BVq4F+M4b0lVcgqijyoQhgMItvA3eZ7Vdd1iQ== =Hh4N -----END PGP SIGNATURE-----

1 0

Threat models. [was: Why encrypt intra-remailernet]
by Nathan Zook 17 Dec '03

17 Dec '03

> From: Nathan Zook <nzook(a)bga.com> > > When I say that the Mark I remailers are laughably easy to crack, I mean > laughably easy. > > By whom? I am hearing a general denunciation of the current remailer > system. These blanket denials are false on their face, because they > are not true in every circumstance. > By anyone with the resources to snoop up- and down- stream of all the remailers. > The only reason that our systems are actually able to do any good is that > our threat model _is not_ an LEA--with government resources, and government > patience. > > _Our_ threat model? > > There is not one threat model. Each person has their own threat model > and their own desired level of security. An individual also desires > more security for some messages than others. The current remailer > network is good for some purposes and bad for others. > > Every evaluation of security _must_ include the nature of the security > desired, because there is no single concept called "security" which is > the same in every situation. > > Eric Yes, but... The very act of going to the trouble of using these remailers means that you are dealing with someone powerful enough to read past forged From/From: lines. Does it take that much more to snoop these sites? My gut says no. Everybody harps chaining. Does snooping take more effort than compromising? I think it would be hard indeed to say so. So if we think Eve can compromise some remailers, and/or read past From/From: faking, we are, I believe, forced to believe that Eve can snoop all the remailers. Threat models need to be uniform in the power of the opponent. Nathan

1 0

Mixmaster + T1
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- *** Background Cypherpunk remailers have been very effectively keeping the net.cops at bay--mostly because the net.cops aren't _real_ cops. Lance has offered a standard that goes quite a distance towards defeating the latter opponent. I hope that my suggestions can close the gap. The remailers, and their mailers, use IDEA, RSA, MD5, PGP, and D-H. *** Threat Model Our attacker, Eve, is a wealthy national government. Eve has corrupted at least some of the law enforcement agencies, but not much of the judiciary. Contact with the remailers has not been outlawed. Individual use of strong crypto has not been outlawed. ( I know this probably violates the equality of power demand, but...) Alice and Bob are sending each other messages through the net, and know that they are being watched. Eve does not have the secret (PGP/RSA) keys of anyone she has not explicitly compromised. The historical examples might be Chinese dissidents, Afgan or Nicuaraguian freedom fighters, David Koresh, Randy Weaver, or Mary of Scotland. *** Goal Our goal is to help Alice and Bob carry on an extended conversation without Eve being able to produce proof that either one of them actually sent any real message. This include the possibility that on occasion, theirs is the only real message in the remailer net. By produce I include manufacture. Forward security for all involved is preferable. *** Attack Modes I believe that there are five primary modes of attack: traffic analysizing individual remailers, traffic analysizing the remailer net as a whole, compromising remailers, correlating the reception of messages by Bob or Alice with their later outside actions, and fabricating messages from Alice to Bob. *** Basic Abilities Eve knows all of our protocals, and can convince the Internet that she is anyone. She records all traffic into or out of all remailers, as well as Alice and Bob. She runs most of the remailers, and can temporarily and selectively block traffic through the remailers. *** Attack Methods. I will not redetail the standard attacks which include flushing, spam- copying, single copying (stuttering), size matching, or We Dai. I will, however, detail certain attacks that I believe are either new or have not been generally discussed. ** Fabricating Evidence As we have seen with our own government, lack of evidence is a condition that governments can correct by fiat. (Randy Weaver) Alice has to be able to prove that a message on the Internet "from" her to a remailer did not in fact originate with her. ** Sandwiching (This attack may not be possible at this time. But it is hard to know...) If Eve owns remailers on either side of another, she may seed "random" data with particular data in order to determine what IDEA key was used on the data. ** Remailer Spoofing Eve can attempt to process messages on a remailer's behalf. ** Message Body Matching If a copy of a message can be sent through, the first part of the body (following the headers) can be compared. If random garbage has been tacked on by the other remailer, it will be distinguished. *** Definitions for Standard Remailers and mailers together are generically called users. Alice is sending a message to Bob. All remailers operate on ticks. At certain GMTs, all remailers process all of their accumulated messages, then forward them, holding some over for the next batch. The term message refers to either the final message to be sent to Bob, or its encrypted counterparts--including padding. A header is a set of communications to a remailer, or to Bob. A message packet is a message with all of its headers. A T1 packet is the collection of all message packets going from one user to another on a given tick, with additional header information. *** Standard for Exchanging T1 Packets T1 packets are IDEA encrypted. The key is exchanged through a DH exchange which takes place inside previous T1 packets. The keys are DHed so that the compromise of one T1 packet does not lead to the compromise of all subsequent packets. In order to establish the original IDEA keys, a sender would contact a reciever with a special "origination" packet request. Such requests would intiate contact between users, or could be used to establish secure IDEA tick keys in the event of a failed connection, or compromised key. This packet includes a disposable RSA key, which the receiver would use to PGP a disposable RSA key in return. IDEA keys for future packets could be passed through these RSA keys. The RSA keys would themselves be signed by the public key associated with each user. *** The Structure of a T1 Packet T1 packets would include the DH key exchanges for future ticks, a timestamp, all message packets destined for the reciever this tick, an MD5 of the previous T1 packet recieved (decrypted), and an MD5 of the rest of the message, as a checksum. This could be turned into a signature, possibly with the timestamp. If the MD5 from the previously recieved packet matches, the copy of the old sent T1 packet is destroyed. If it is bad, the old packet is resent, with a different key. *** Selection of Message Packets to a User Mailers specify a number of message packets that they receive each tick from various remailers. If a remailer has more messages packets for a mailer on a given tick than the mailer receives, the extras are held over, and a notice is sent so that the mailer can determine if he should raise his limit. If the number of "real" packets to a user is below his limit, dummy packets are sent to him through other remailers, on a sliding scale. A user sends the same number of message packets to each remailer every tick. There is a minimum number of message packets that a remailer will send to each other remailer each turn. /* This eliminates the ability to trace a flood of messages, even if they all took the same path. */ Messages being held are flaged with the number of ticks that they have been held. There is a maximum number of ticks that a message packet can be held. Mailers send the same number of message packets each tick to each remailer that they might use. *** Use of Dummy Message Packets Dummy message packets are used to pad traffic. Dummy messages are always sent at least to third party remailers. The distribution of these third parties is random. /* If Eve runs some remailers, she can immediately eliminate dummy message sent to her machines. But if these do not originate in the machine that sent the message, her gain is much weakened. If Eve controls most of the remailers, it may be necessary to send dummy messages through three remailers in order to obscure traffic flow. If the distrubtion were flat, real messages would stand out. */ *** The Structure of a Message Packet All message bodies are standard sized, and have a standard number of standard sized headers. The reconstitution of oversized messages is handled by Bob's client. The division of oversized messages is handled by Alice's client. An exception is made for mail-to-news gateways, to reconstitute the oversized message at the last remailer. Such exceptions include a rough check to insure that the message is either valid ASCII armour, or some language. The header to a remailer includes the forwarding address, a timestamp, and the IDEA keys to be used on each other header, as well as the body. (Each is different. See below.) After decrypting, the headers are circulated. When creating the timestamp for a header number n, Alice uses the time of the nth tick coming. The top header itself is RSAed with the user's public key. /* If Eve manages, though a sandwich attack, to divine the idea key used on a header, she can use this to trace the message. If we include only the key and an increment, she can get this information if she has two remailers before the good one. If we include the key, an increment, and a permutation of the headers, she can guess the key. */ The header for Bob includes an MD5 of the message, flags in case the message is oversized, and a timestamp. *** Elimination of Duplicate Packets An MD5 record is kept of every message, every header, and every T1 packet recieved or sent for M ticks. M is related to the number of headers and the maximum number of ticks that a message is held--with room for error. If a match is found, the entire packet is rejected. If a message arrives with a timestamp older than M ticks, it is rejected. If a message arrives with a timestamp in the future, it is held until that time. *** Incorporation of Encrypted Reply Blocks Encrypted Reply Blocks would be the PGPed version of a header set. The receiver would know the IDEA keys used on the body, and the order, so he could reverse the operation. The keys could even be included in the final header. It is not possible in this system to allow multiple encrypted reply block responses without possible compromise of the recipient. *** Weaknesses Clients are required to be as sophisticated as hosts. Clients must be able to handle lots of dummy mail. Both hosts and clients must have access to good, secure, random data sources. Hosts must be able to protect their data for a period of hours or days. Hosts and clients need to be able to protect their DH information. Nathan Flame on!! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLzmk/XmgMs8UcStNAQEQQQgAkJyeh2vgOnsbVzuHrqGKVPE0pIoh37ms DtMxD7mJVMp40fGlQJmk8dT3WeVUpgeFIvJxeNvMZ86jyN51smZkjqUBNWFhJikT HBnAlDuf82g1GbuhPsR9J2vMTtTHcsfs+ytTWDp2g+xr1nWHngki4wBjPy2oOCP9 dxu5vamUnDy0oFatMmGxIZyN9jTzB7NynaXVLkDWL3Hh8amUwyW9nq7LGQJ8Oiuh 2xY4uizxJ+/SjxnATxUznT9i099xC3ClpRGX1n/3fdXY5Mu5MAJoRO6sjL5Fakz4 3i0qWNlv8ZJCqCetSqnQrINFFd6bpDhiAz5/CU4kQ9/HtStIVl/88A== =kziG -----END PGP SIGNATURE-----

1 0

Best encryption device driver for MS-DOS?
by erc＠s116.slcslip.indirect.com 17 Dec '03

17 Dec '03

Being in the consulting business, I often write prototype software for clients in Visual Basic as proof-of-concept and also to make sure I understand the client's needs before I accept a project. On occasion, I have to leave my laptop unattended on someone's desk while I go into meetings with senior management and try to convince them that I know what I'm talking about and that I'm worth whatever (exorbitant to them) I'm asking to do their application for them. I also do volunteer programming for several volunteer organizations, and it's the same situation - unattended laptop while I wander off and chat with management to tell them why it will take so long to do the impossible. ;) As you might imagine, I have a full suite of programming tools on the laptop, including MS Office Pro and VB Pro, both of which are worth about $500 apiece - I'd sure hate to lose them to a malicious cracker, or someone who would like a personal copy of my source code for their own use, or who just wants to "borrow" my secret key for awhile. What do people recommend as the solution for this? Some sort of IDEA-based or triple-DES-based device driver would seem to be the answer to this, but I'm not sure which is the "best" (most reliable, fastest, easiest to set up) one to use. I like the sound of Michael Sattler's encryption driver for the Mac, but alas, I'm running MS-DOS :( Also, if anyone has any suggestions for a similar driver for Linux, I'd appreciate it - thanks! -- Ed Carp, N7EKG Ed.Carp(a)linux.org, ecarp(a)netcom.com 801/534-8857 voicemail 801/460-1883 digital pager Finger ecarp(a)netcom.com for PGP 2.5 public key an88744(a)anon.penet.fi ** PGP encrypted email preferred! ** Cop: "How many beers have you had tonight, bro?" Suspect: "Seventy." -- from the TV show "Cops"

4 4

Key management in Hastur
by A Loose Affiliation of Millionaires and Billionaires and Babies 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Eric, if I understand you correctly, you're saying that the manner in which trust is bestowed in keys should not be generalized. Is this correct? I don't have a problem with that, and wasn't terribly interested in defining trust parameters. I do want to finish this in the next 4 to 6 weeks, after all. However, that's not exactly the problem I'm trying to solve; The phrase "key management" is likely too vague or perhaps has specific connotations that I'm unaware of, such that I'm using it wrongly. I was never strong on jargon, and "key management" is the phrase that came closest to an expression of the problem I'm trying to solve. The problem is this: You have a bitstream and you want to perform a cryptographic function on it. Therefore, you need a key. For RSA functions, I know of two different ways that keys are distributed: PGP and X.509. My intent is to support PGP keyrings and PEM-style keyrings (I am not yet familiar with the latter)... having a way to place keys into their proper keyrings would be nice, too, but there's no way I'm going to worry about that in the first rev. Would I be understanding you correctly if I characterized your advice as being to not plan to implement that at all? There are two ways that I could approach handling keys in the code: 1- Have a general RSA key format. The would include parameters that are defined in either PGP and X.509 keys and would allow the code to hand back warnings such as "this key is not trusted by you" and "this key has expired." This seems to be what you're advising against... 2- Have only a bare-bones key format that includes only the information necessary for crypto functions. This is the way I'm leaning for several reasons, not the least of which is what you cite. In either case, there must be an import function, extracting the key from the appropriate keyrings or otherwise supplying the key. Including functions that extract keys from the appropriate PGP/PEM keyrings would be a Good Thing and is right now The Plan: one can hardly expect the code to get used if it needs Yet Another (undefined) Key Distribution method. My X.509 vs PGP key question boils down to this: is it reasonable to try to convert keys of one sort into keys of the other sort, providing the functionality of converting a key obtained through an X.509 certificate into a PGP-key? Converting the other seems like a less desirable thing to do, so I'm not really thinking about that problem. I should note that in all cases in HCT where something is parameterized, the caller can supply a callback function that matches the defined interface and expect to win. Thus, it's already supported (in the general interface and soon the key handling) that a user could say (in pseudo C code, missing parameters): erics_key_stub_fn(char *id, struct keytype *key, ...); ... struct keytype *thiskey; thiskey = keyinit( KEYTYPE_RSA, (void *) erics_key_stub_fn, ...); if (!(get_key( thiskey, "eric(a)remailer.net",...))) { /* ... Do the right thing, etc. */ } Are we on a similar wavelength here, or am I totally missing the point? The input is appreciated. -- Todd - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLzqEYCoZzwIn1bdtAQHUcwF/QO2s178YMsxdSWQj6UDDErCDRv6+gaB5 CJnEyrRPwpS8jqRLOSDQmyjHDvOJbJS2 =xm8Q -----END PGP SIGNATURE-----

1 0

Re: Best encryption device driver for MS-DOS?
by pdlamb＠iquest.com 17 Dec '03

17 Dec '03

>> You leave your laptop turned on and out of your immediate reach? Geesh. >> I would NEVER leave my laptop anywhere that I didn't have it in eyeshot. It >> was the whole reason I got one. > >Well, it's rather tacky to turn off the laptop, unplug it, etc., just to >lug it into a boardroom. Not impressive. > >> > As you might imagine, I have a full suite of programming tools on the laptop, >> > including MS Office Pro and VB Pro, both of which are worth about $500 >> > apiece - I'd sure hate to lose them to a malicious cracker, or someone who >> > would like a personal copy of my source code for their own use, or who just >> > wants to "borrow" my secret key for awhile. >> > >> Business must be good, you are more worried about somebody stealing a $500 >> dollar program than a several thousand dollar laptop? > >Oh, I'm not worried about the laptop walking off, I'm worried about the >software I've written walking off... > How about an obvious solution, like the password feature on After Dark? If I remember correctly, there's a hot-key combination you can use to bring up the screen saver mode immediately as you get up from the machine. It's obviously not foolproof, but just blanking the screen and going into a password mode would probably deter the casual browser. If you're really worried, change your autoexec so it goes into windows and starts AD immediately. Low tech, maybe, but easy! Pat

1 0

Re: Best encryption device driver for MS-DOS?
by Philippe Nave 17 Dec '03

17 Dec '03

Ho, cyphernauts! My $.02 votes for SecureDevice as an MS-DOS encryption mechanism because: 1) It works within a file (or files) rather than requiring a dedicated hard disk partition; you can put up and take down encrypted "drives" without wiping out the whole disk drive and repartitioning. (VERY handy when you suddenly need to increase the size of your "drive" *RIGHT NOW*). 2) It keeps a regular DOS directory structure within the "drive" file; you set up the "drive" one time and then just throw stuff in it at will. You can encrypt single files a variety of ways, but then you have to manage them all - this way, you just chuck 'em in the safe together. 3) In a pinch, you can move the whole encrypted "drive" from place to place - since it's a self-contained data file and is encrypted throughout, you can FTP it all over the place as a binary file without hurting it. The only time I've gotten in trouble with it was when I had SmartDrive turned on for the encrypted "drive" and went down hard; now, I have a SMARTDRV -D: or whatever in my AUTOEXEC so that SmartDrive won't try to buffer I/O to the encrypted drive. My one and only gripe - it won't work under Windows NT 3.5 ! I have to boot DOS (blech!) to get at the encrypted drive. (Hint, Hint, Hint....) -Philippe

1 0

Re: Wed 15 Feb, 730pm: BayFF's first monthly Bay Area EFF meeting
by Michael Sattler 17 Dec '03

17 Dec '03

At 15:56 2/9/95, gnu(a)toad.com wrote: >John Gilmore and Cindy Cohn will speak on the constitutional issues >around export controls on cryptography. Forget export; I fear that among the next n logical steps is to ban private strong crypto for US citizens. Otherwise what's the point of the legislative path we're seeing trod. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | You couldn't get a clue during the clue mating season in | a field full of horny clues if you smeared your body with clue musk | and did the clue mating dance. - Edward Flaherty |

1 0

LESM - Link Encrypted Session Manager (3rd try)
by Wei Dai 17 Dec '03

17 Dec '03

I tried to distribute LESM to the cypherpunks mailing list twice, and neither of them made it to the nntp.hks.com list archive (my laster posts HAVE). What is going on here? This is a second repost. -----BEGIN PGP SIGNED MESSAGE----- I finished hacking Matt's ESM to do link encryption yesterday, but for some reason the mail I sent to cypherpunks didn't get echoed back to me, so I'm sending this again. To install: get ESM and RSAREF, make sure you can compile ESM, then replace the esm.c with my hacked version and recompile. To use: same as ESM, but there's an extra option "-b bandwidth", the default is 100 cps. I've attached the modified esm.c here since it doesn't include any crypto code. To get ESM, write to cfs(a)research.att.com and state the following: - you are in the US or Canada, and - you are a US or Canadian citizen or legal permanent resident, and - You've read and understand the license and export conditions. RSAREF is in ftp://rsa.com/rsaref/ Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzqTtTl0sXKgdnV5AQEmbgP8CRxE+RCGsDXwwShWhZKGytSywyWZ8RXB RPBHZmk6UgdpCR2VVo8wXjcPuEv4SHp9ZjhFTq53JZ/s3YcV5FxF33/ivSlh1Ra4 P8GSYnoEaIJoFrJyagukbBUaY6zWCx0PcnsLoVArCxujwRYwfrQvHdiNx13z7bJh OSEhhoE9djg= =PY8P -----END PGP SIGNATURE----- -------------- Enclosure number 1 ---------------- /* * LESM - Link Encrypted Session Manager * v0.6a.01 * Wei Dai * 2/8/1995 * * This program is a quick and dirty hack of: */ /* * ESM - Encrypted Session Manager * v0.6a * matt blaze * January 1995 */ /* * The author of this software is Matt Blaze. * Copyright (c) 1995 by AT&T. * Permission to use, copy, and modify this software without fee * is hereby granted, provided that this entire notice is included in * all copies of any software which is or includes a copy or * modification of this software and in all copies of the supporting * documentation for such software. * * This software is subject to United States export controls. * * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED * WARRANTY. IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. */ /* * Some of this file was stolen from the BSD "script" program, which * is covered under the following notice: * * Copyright (c) 1980 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #ifndef lint char copyright1[] = "@(#) Copyright (c) 1980 Regents of the University of California.\n\ All rights reserved.\n"; char copyright2[] = "@(#) Copyright (c) 1995 AT&T\nAll rights reserved.\n"; #endif /* not lint */ #include <sys/types.h> #include <sys/stat.h> #include <termios.h> #ifndef SUN #include <sys/ioctl.h> #endif #include <sys/time.h> #include <sys/file.h> #include <sys/signal.h> #include <unistd.h> #include <stdio.h> #include "global.h" #include "rsaref.h" #include "esm.h" char *shell; int master; int slave; int subchild; int escape=036; /* ^^ */ int ciphstate=0; int ciphbyte=0; int keyed=0; struct termios tt; struct winsize win; int lb; int l; char line[] = "/dev/ptyXX"; int aflg; #define REMOTE 0 #define LOCAL 1 #define CALC 2 int mode=LOCAL; int paranoid=0; #define SL_START 0 #define SL_GOT1 1 #define SL_GOT2 2 #define SL_GOT3 3 #define SL_GOT4 4 #define SL_KEYING 5 #define SL_CRYPT 6 int sloutstate=SL_START; char *cmd=NULL; #define TRANS 0 #define CMDWAIT 1 #define CIPHER 2 #define KEYWAIT 3 #define IV0 0 #define IV1 1 #define IV2 2 #define IV3 3 #define C0 4 #define C1 5 int state=TRANS; int cstate=IV0; FILE *fpmaster; struct timeval tvPause={0,10000}; struct timeval tvNoPause={0,0}; unsigned char filler = (unsigned char) 31; #define bwrite(fp,buf,len) (fwrite(buf,len,1,fp)) main(argc, argv) int argc; char *argv[]; { extern char *optarg; extern int optind; int ch, result; void finish(); char *getenv(); fd_set fds; struct timeval tv; while ((ch = getopt(argc, argv, "e:b:splrci")) != EOF) switch((char)ch) { case 'e': cmd=optarg; break; case 'b': tvPause.tv_usec=(long)1000000/atol(optarg); break; case 'i': case 's': case 'p': paranoid=1; case 'r': mode=REMOTE; break; case 'l': mode=LOCAL; break; case 'c': mode=CALC; break; case '?': default: fprintf(stderr, "usage: lesm [-rlc] [-b bandwidth] [-e program\n"); exit(1); } argc -= optind; argv += optind; if ((shell=getenv("SHELL")) == NULL) shell = "/bin/sh"; getmaster(); (void) signal(SIGCHLD, finish); subchild = fork(); if (subchild < 0) { perror("fork"); fail(); } if (subchild==0) doshell(); else { /* main loop */ printf("LESM v0.6a.01, hacked by Wei Dai from ESM v0.6a - encrypted session manager\n"); printf(" by Matt Blaze, AT&T Bell Labs, January 1995\n"); randinit(); cipherinit(); switch (mode) { case REMOTE: if (paranoid) printf("remote server ready\n"); else printf("remote server ready; ctl-^ to escape\n"); break; case LOCAL: printf("local layer ready (run 'lesm -s' on remote)\n"); break; default: /* not yet */ printf("lesm ready\n"); } rawtty(); fpmaster=fdopen(master,"w"); if (fpmaster == NULL) done(); if (paranoid) startsession(); while(1) { FD_ZERO(&fds); FD_SET(0,&fds); tv=tvNoPause; result=select (FD_SETSIZE,&fds,NULL,NULL,&tv); if (result==1) doinput(); if (mode==LOCAL && sloutstate==SL_CRYPT && result==0) doslavein(filler); if (result<0) break; FD_ZERO(&fds); FD_SET(master,&fds); tv=tvNoPause; result=select (FD_SETSIZE,&fds,NULL,NULL,&tv); if (result==1) dooutput(); if (mode==REMOTE && state==CIPHER && result==0) domasterout(filler); if (result<0) break; } done(); } } doinput() { int cc; int i; static unsigned char ibuf[512]; if ((cc = read(0, ibuf, 512)) > 0) { switch (mode) { case REMOTE: for (i=0; i<cc; i++) domasterin(ibuf[i]); break; case LOCAL: for (i=0; i<cc; i++) doslavein(ibuf[i]); break; default: for (i=0; i<cc; i++) bwrite(fpmaster,&ibuf[i],1); break; } fflush(fpmaster); fflush(stdout); } else done(); } doslavein(ibuf) unsigned char ibuf; { int c; static int count=0; struct timeval tv; switch (sloutstate) { case SL_CRYPT: if (ibuf==escape) { bwrite(stdout,">>",2); fflush(stdout); if (slescape()) { printf("q\r\nEntering CLEARTEXT mode\r\n"); bwrite(fpmaster,"PPPPPPPPPPPPPPPP",16); sloutstate=SL_START; } break; } c=cfb8_encrypt(ibuf); if (!(++count % 8)) bwrite(fpmaster,"!",1); sendhex(fpmaster,c); tv=tvPause; select (FD_SETSIZE,NULL,NULL,NULL,&tv); break; default: bwrite(fpmaster,&ibuf,1); break; } } slescape() { char buf; int c; int escaped=0; while (read(0,&buf,1)>0) { if (escaped) { escaped=0; bwrite(fpmaster,&buf,1); continue; } if (buf==escape) { c=cfb8_encrypt(buf); sendhex(fpmaster,c); return 0; } bwrite(stdout,&buf,1); fflush(stdout); if (buf=='\\') { mode=escaped; continue; } if (buf=='\r') return 0; if (buf=='C') { return 1; } printf("\r\nType one of the following:\r\n"); printf(" \\[char] to send char as cleartext\r\n"); printf(" ctrl-^ to send escape character\r\n"); printf(" 'C' to return to CLEARTEXT session\r\n"); printf(" <enter> to return to encrypted session\r\n"); } return 1; /* should never happen */ } domasterin(ibuf) unsigned char ibuf; { int c; char ch; static int bad=0; switch (state) { case TRANS: if (ibuf != escape) bwrite(fpmaster, &ibuf, 1); else { state=CMDWAIT; bwrite(stdout,">>",2); cstate=IV0; } break; case CMDWAIT: if (ibuf == escape) { bwrite(fpmaster, &ibuf, 1); state=TRANS; } else switch (ibuf) { case '\r': case '\n': bwrite(stdout,"\r\n",2); state=TRANS; break; case 's': case 'S': startsession(LONG); break; case 'Q': done(); break; default: printf("Type 's' to start encrypted session\r\n"); printf(" 'Q' to terminate remote session\r\n"); printf(" ctrl-^ to send escape character\r\n"); printf(" <enter> to return to session\r\n"); break; } break; case CIPHER: if (strchr("0123456789abcdef!",ibuf)!=NULL) { bad=0; if ((c = cipherout(ibuf)) >= 0) { ch=c; if (ch!=filler) bwrite(fpmaster,&ch,1); } } else if (bad++ > 16) { delkey(); bwrite(stdout,"XXXXXXXXXXXXXXXX",16); if (paranoid) done(); state=TRANS; } else ciphstate=0; break; case KEYWAIT: if (strchr("0123456789abcdef:",ibuf)!=NULL) { masterkeyin(ibuf); } else { delkey(); bwrite(stdout,"XXXXXXXXXXXXXXXX",16); if (paranoid) done(); state=TRANS; } break; } } int pubstat=0; int pubpos=0; unsigned char pubbyte=0; int pksize = -1; startsession() { static unsigned char buf[5] = {0177, '~', 0177, '~', 'L'}; static unsigned char colon=':'; int i; pklen=dhparams[LONG].primeLen; printf("Starting remote side of %d bit key exchange.\r\n",pklen*8); if (createdh(LONG) < 0) return -1; bwrite(stdout,buf,5); for (i=0; i<pklen; i++) sendhex(stdout,ourpub[i]); bwrite(stdout,&colon,1); pksize=LONG; pubstat=0; pubpos=0; pubbyte=0; state=KEYWAIT; return 0; } sltranspub(len) { static unsigned char colon=':'; int i; printf("\r\nStarting local key exchange.\r\n"); for (i=0; i<len; i++) sendhex(fpmaster,ourpub[i]); bwrite(fpmaster,&colon,1); printf("entering ENCRYPTED mode; type ctrl-^ to escape\r\n"); } masterkeyin(c) char c; { int bits; if (c==':') { if (pubpos!=(pklen+2)) /* +2 for trailing checkword */ goto abort; if (mcalckeys(pksize)<0) /* also verifies */ goto abort; ciphstate=0; state=CIPHER; return; } else if (pubpos<MAXPUBKEY) { bits=atoh(c); if (bits<0) goto abort; if (pubstat) { pubbyte |= bits; otherpub[pubpos]=pubbyte; pubpos++; } else { pubbyte = bits<<4; } pubstat = 1-pubstat; return; } abort: bwrite(stdout,"XXXXXXXXXXXXXXXX",16); if (paranoid) done(); state=TRANS; } int mcalckeys(len) int len; { int i; if (dhagree(len)<0) /* sets up session keys */ return -1; for (i=0; i<8; i++) { ivin[i]=0; ivout[i]=0xff; } if (cfb8_decrypt(otherpub[pklen]) || cfb8_decrypt(otherpub[pklen+1])) return -1; return 0; } int slcalckeys(len) int len; { int i; if (dhagree(len)<0) /* sets up session keys */ return -1; for (i=0; i<8; i++) { ivout[i]=0; ivin[i]=0xff; } ourpub[pklen]=cfb8_encrypt(0); ourpub[pklen+1]=cfb8_encrypt(0); return 0; } initslkey(param) int param; { if ((param<0) || (param>2)) return -1; pklen=dhparams[param].primeLen; pksize=param; pubstat=0; pubpos=0; pubbyte=0; } slkeyin(c) char c; { int bits; if (c==':') { if (pubpos!=pklen) goto abort; if (createdh(pksize)<0) goto abort; if (slcalckeys(pksize)<0) goto abort; sltranspub(pklen+2); ciphstate=0; sloutstate=SL_CRYPT; return; } else if (pubpos<MAXPUBKEY){ bits=atoh(c); if (bits<0) goto abort; if (pubstat) { pubbyte |= bits; otherpub[pubpos]=pubbyte; pubpos++; } else { pubbyte = bits<<4; } pubstat = 1-pubstat; return; } abort: bwrite(stdout,"X",1); state=SL_START; } int cipherout(ch) char ch; { int bits; if (ch=='!') { ciphstate=0; return -1; } bits=atoh(ch); if (ciphstate) { ciphbyte |= bits; ciphstate=0; return(cfb8_decrypt(ciphbyte)); } else { ciphbyte = bits<<4; ciphstate=1; return -1; } } int ciphercalcin(ch) unsigned char ch; { static unsigned char iv[8]; static unsigned int cbuf; int c; int i; c = atoh(ch); switch (cstate) { case IV0: for(i=0; i<8; i++) iv[i]=0; cbuf = (c&0xf)<<4; cstate=IV1; return '.'; case IV1: cbuf = cbuf | (c&0xf); iv[7]=cbuf; cstate=IV2; return '.'; case IV2: cbuf = (c&0xf)<<4; cstate=IV3; return '.'; case IV3: cbuf = cbuf | (c&0xf); iv[6]=cbuf; cstate=C0; return '.'; case C0: cbuf = (c&0xf)<<4; cstate=C1; return '.'; case C1: cbuf = cbuf | c&0xf; c=cfb8_decrypt(cbuf); cstate=C0; if (isprint(c)) { bwrite(fpmaster,&c,1); return '_'; } else { return '?'; } default: return '?'; } } #include <sys/wait.h> void finish() { union wait status; register int pid; register int die = 0; while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0) if (pid == subchild) die = 1; if (die) done(); } dooutput() { register int cc; int i; unsigned char obuf[512]; if ((cc = read(master, obuf, 512)) > 0) { switch (mode) { case REMOTE: for (i=0; i<cc; i++) domasterout(obuf[i]); break; case LOCAL: for (i=0; i<cc; i++) doslaveout(obuf[i]); break; default: for (i=0; i<cc; i++) bwrite(stdout, &obuf[i], 1); break; } fflush(fpmaster); fflush(stdout); } else done(); } domasterout(obuf) unsigned char obuf; { int c; static int count=0; struct timeval tv; switch (state) { case CIPHER: c=cfb8_encrypt(obuf); if (!(++count % 8)) bwrite(stdout,"!",1); sendhex(stdout,c); tv=tvPause; select (FD_SETSIZE,NULL,NULL,NULL,&tv); break; case TRANS: bwrite(stdout, &obuf, 1); break; default: /* throw away since i/o screws up keying */ break; } } doslaveout(obuf) unsigned char obuf; { static int bad=0; int c; char ch; switch (sloutstate) { case SL_START: bwrite(stdout, &obuf, 1); if (obuf==0177) sloutstate=SL_GOT1; break; case SL_GOT1: bwrite(stdout, &obuf, 1); if (obuf=='~') sloutstate=SL_GOT2; else sloutstate=SL_START; break; case SL_GOT2: if (obuf==0177) sloutstate=SL_GOT3; else { bwrite(stdout, &obuf, 1); sloutstate=SL_START; } break; case SL_GOT3: if (obuf=='~') sloutstate=SL_GOT4; else { bwrite(stdout, &obuf, 1); sloutstate=SL_START; } break; case SL_GOT4: /* key size indicator */ bwrite(stdout, &obuf, 1); if (obuf=='S') { initslkey(SHORT); sloutstate=SL_KEYING; } else if (obuf=='M') { initslkey(MEDIUM); sloutstate=SL_KEYING; } else if (obuf=='L') { initslkey(LONG); sloutstate=SL_KEYING; } else sloutstate=SL_START; break; case SL_KEYING: if (strchr("0123456789abcdef:",obuf) != NULL) { slkeyin(obuf); } else { bwrite(stdout,"U",1); sloutstate=SL_START; } break; case SL_CRYPT: if (strchr("0123456789abcdef!",obuf) != NULL) { bad=0; if ((c = cipherout(obuf))>=0) { ch=c; if (ch!=filler) bwrite(stdout,&ch,1); } } else if (bad++ > 8) { fprintf(stderr,"\r\nEncrypted session terminated -"); fprintf(stderr,"\r\npress enter for CLEARTEXT mode: "); waitenter(); delkey(); sloutstate=SL_START; } else ciphstate=0; break; default: bwrite(stdout, &obuf, 1); break; } } doshell() { int t; /*** t = open(_PATH_TTY, O_RDWR); if (t >= 0) { (void) ioctl(t, TIOCNOTTY, (char *)0); (void) close(t); } ***/ getslave(); (void) close(master); (void) dup2(slave, 0); (void) dup2(slave, 1); (void) dup2(slave, 2); (void) close(slave); if (cmd==NULL) execl(shell, "sh", "-i", 0); else system(cmd); perror(shell); fail(); } rawtty() { struct termios sbuf; sbuf = tt; sbuf.c_iflag &= ~(INLCR|IGNCR|ICRNL|IXON); sbuf.c_oflag &= ~OPOST; sbuf.c_lflag &= ~(ICANON|ISIG|ECHO); sbuf.c_cc[VMIN] = 1; sbuf.c_cc[VTIME] = 0; (void) tcsetattr(0, TCSAFLUSH, &sbuf); } cookedtty() { (void) tcsetattr(0, TCSAFLUSH, &tt); } fail() { (void) kill(0, SIGTERM); done(); } done() { cookedtty(); switch (mode) { case REMOTE: if (state==CIPHER) printf("XXXXXXXXXXXXXXXX\n"); printf("lesm remote "); break; case LOCAL: printf("lesm local "); break; } printf("done\n"); exit(0); } getmaster() { char *pty, *bank, *cp; struct stat stb; pty = &line[strlen("/dev/ptyp")]; for (bank = "pqrstuvwxyz"; *bank; bank++) { line[strlen("/dev/pty")] = *bank; *pty = '0'; if (stat(line, &stb) < 0) break; for (cp = "0123456789abcdef"; *cp; cp++) { *pty = *cp; master = open(line, O_RDWR); if (master >= 0) { char *tp = &line[strlen("/dev/")]; int ok; /* verify slave side is usable */ *tp = 't'; ok = access(line, R_OK|W_OK) == 0; *tp = 'p'; if (ok) { (void) tcgetattr(0, &tt); (void) ioctl(0, TIOCGWINSZ, (char *)&win); return; } (void) close(master); } } } fprintf(stderr, "Out of pty's\n"); fail(); } getslave() { line[strlen("/dev/")] = 't'; slave = open(line, O_RDWR); if (slave < 0) { perror(line); fail(); } (void) tcsetattr(slave, TCSAFLUSH, &tt); (void) ioctl(slave, TIOCSWINSZ, (char *)&win); (void) setsid(); (void) ioctl(slave, TIOCSCTTY, 0); } waitenter() { unsigned char b; do { read(0,&b,1); } while (b!='\r'); printf("\r\n"); } sendhex(fp,c) FILE *fp; unsigned int c; { static char buf[16]; sprintf(buf,"%02x",c); bwrite(fp,buf,2); }

1 0

Senate Version of HR666 (fwd)
by Brad Dolan 17 Dec '03

17 Dec '03

It is still *theoretically* possible to stop the legislative revocation of the 4th amendment, if you believe we have a representative government. Brad D. ---------- Forwarded message ---------- Date: 9 Feb 1995 11:14:58 U From: Cooley Stephen <cooley_stephen(a)space.honeywell.com> To: UWSA <uwsa(a)shell.portal.com>, baron_mark_a(a)smtpmm.space.honeywell.com, Bostock#m#_Craig_W.FL40-P02(a)smtpmm.space.honeywell.com, Kidd_Lee.FL51-P03(a)smtpmm.space.honeywell.com Subject: Senate Version of HR666 S54 - the Senate version of HR666 subverts the 4th Amendment! I called Sen Mack's (R-FL) DC office this morning for info on S54. This bill has been submitted to the Senate Judiciary Committee for consideration. Hearings for S3-The "New" Crime bill, are scheduled for Fed 15th. The new crime bill also has a Exclusionary Evidence section too. I have appended this section after S54 below. No hearings for S54 are scheduled as of yet. The aid I talked to didn't know if any hearings on S54 would even occur before it is passed onto the floor for a vote. The committe could mark up the bill and pass it on without hearings. Please pass this info onto other groups and reflectors. We have to get the word out on this bill. S54 modifies the requirements of the 4th amendment to ".....if the search or seizure was undertaken in an objectively reasonable belief that it was in conformity with the fourth amendment." Given the court rulings allowing traffic stops and searches due to an officer's descretion, "probably cause", S54 hammers another nail into the 4th Amendment coffin. Call your Senators and let them know your thoughts on this bill. There is no time to waste. FILE s54.is S 54 IS 104th CONGRESS 1st Session To amend title 18 to limit the application of the exclusionary rule. IN THE SENATE OF THE UNITED STATES January 4, 1995 Mr. Thurmond introduced the following bill; which was read twice and referred to the Committee on the Judiciary A BILL To amend title 18 to limit the application of the exclusionary rule. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, That this Act may be cited as the `Exclusionary Rule Limitation Act of 1995'. Sec. 2. (a) Chapter 223 of title 18, United States Code, is amended by adding the following two sections: `Sec. 3508. Limitation of the fourth amendment exclusionary rule `Evidence which is obtained as a result of a search or seizure shall not be excluded in a proceeding in a court of the United States on the ground that the search or seizure was in violation of the fourth amendment to the Constitution of the United States, if the search or seizure was undertaken in an objectively reasonable belief that it was in conformity with the fourth amendment. A showing that evidence was obtained pursuant to and within the scope of a warrant constitutes prima facie evidence of such a reasonable belief, unless the warrant was obtained through intentional and material misrepresentation. `Sec. 3509. General limitation of the exclusionary rule `Except as specifically provided by statute or rule of procedure, evidence which is otherwise admissible shall not be excluded in a proceeding in a court of the United States on the ground that the evidence was obtained in violation of a statute or rule of procedure, or of a regulation issued pursuant thereto.'. (b) The table of sections of chapter 223 of title 18, United States Code, is amended by adding at the end thereof: `3508. Limitation of the fourth amendment exclusionary rule. `3509. General limitation of the exclusionary rule. Exclusionary Evidence section in the new crime bill S3: SEC. 507. ADMISSIBILITY OF CERTAIN EVIDENCE. `Sec. 3502A. Admissibility of evidence obtained by search or seizure `(a) Evidence Obtained by Objectively Reasonable Search or Seizure: Evidence obtained as a result of a search or seizure that is otherwise admissible in a Federal criminal proceeding shall not be excluded in a proceeding in a court of the United States on the ground that the search or seizure was in violation of the fourth amendment to the Constitution. `(b) Evidence Not Excludable by Statute or Rule: Evidence shall not be excluded in a proceeding in a court of the United States on the ground that it was obtained in violation of a statute, an administrative rule, or a rule of court procedure unless exclusion is expressly authorized by statute or by a rule prescribed by the Supreme Court pursuant to chapter 131 of title 28. `(c) Rule of Construction: This section shall not be construed to require or authorize the exclusion of evidence in any proceeding.'. (2) Technical amendment: The chapter analysis for chapter 223 of title 18, United States Code, is amended by inserting after the item for section 3502 the following new item: `3502A. Admissibility of evidence obtained by search or seizure.'. (c) Illegal Search and Seizure: (1) In general: Title 28, United States Code, is amended by inserting after chapter 171, the following new chapter:

1 0

My pgp emacs code in ftp://ftp.markv.com/pub/jpp/pgpelisp/*
by jpp＠markv.com 17 Dec '03

17 Dec '03

I have been hacking yet another emacs to pgp interface for some time now. I am happy with the current state of affairs, and am releasing it for general consumption. It supports automatic decrypting, signing, signature checks and interfaces nicely with rmail.el and sendmail.el. Also it includes a set of remailer functions which parse the ping reports from Raph Levien <raph(a)CS.Berkeley.EDU> and give you a simple interface to chaining a bunch of remailers together. The code is liscense free; use it, sell it, hack it up, export it, claim it is yours, I don't care. Feel free. (How could I stop you any way? I suspect that number theory, and complexity theory *are* the real natural rights.) My code is in ftp://ftp.markv.com/pub/jpp/pgpelisp/* It is not yet very well packaged. Read 2b.emacs. I still want to clean up the remailer stuff a little before I spend time packaging. (C-C commands, reply block building, and estimates of a chain's reliability, (support for ghio and julf {pseudo, ano}nyms?)) Unfortuneately my net connection, and means of support here at markv will likely soon be gone :(... This may be the last chance I have to distribute or work on this code for a while. If the code impreses you with my ability to hack, you might want to make me a job offer :) Or point me to jobs. OTOH, if my ability to hack doesn't impress you, please be quiet until I do get another job :). j'

1 0

No Subject
by jltocher＠CCGATE.HAC.COM 17 Dec '03

17 Dec '03

From Edupage: ONLINE SPYING While you're connected to your favorite Web page, it's also connected to you, and could be copying all sorts of information off your hard drive, say industry experts. In fact, it happened last year when Central Point Software used registration software developed by Pipeline Communications, and inadvertently also gathered descriptions of the users' systems -- the type of microprocessor, the version of DOS and Windows, the type of display and mouse, and the amount of free space available on the hard drive. Customers squawked, and Central Point had Pipeline change the software. However, Pipeline reports that at least one of its clients is using the scanning feature now -- but only after getting the owner's permission. The lesson? "If you can't trust it, don't connect to it." (Forbes 2/13/95 p.186) John L. Tocher THE CITY-a bounded infinity. A labyrinth where JLTocher(a)ccgate.HAC.com you are never lost. Your private map where every PGP: CE 72 1A 11 07 47 35 block bears exactly the same number. Even if you 35 9A C1 DE EA 64 21 BC 94 lose your way, you cannot go wrong. --Kobo Abe

1 0

NYT on HR666
by John Young 17 Dec '03

17 Dec '03

Katherine Seelye writes on Page One today about House passage of the new Search and Seizure bill. It covers a parallel revision of appeals of the death penalty. And notes on abusive BATF. For email copy send blank message to <jya(a)pipeline.com> with subject: 666_zap

1 0

Re: skronk
by Perry E. Metzger 17 Dec '03

17 Dec '03

Kipp E.B. Hickman says: > Har! Besides the certificate problems, are there other problems with > PEM that have prevented its adoption? Its kind of ugly, too. The new PEM-MIME stuff should do much better, but its no longer really PEM per se. Look at the drafts if you are interested. > > I don't really blame you much. I mean TIPEM handles all the X.509 > > stuff just fine and PGP can't get out even the simplest of libraries, > > or even a partial library. > > Our implementation supports this X.509 stuff as well. We don't have a > DUA yet though... Just so you know, Kipp, there is no real support for X.500 directories over the internet, and there never will be. No one likes the things outside of fogeys in MIS departments who program in Cobol. Certificates as currently envisioned by the IETF are probably going to be stored in the DNS. .pm

1 0

PEM
by Rich Salz 17 Dec '03

17 Dec '03

> Har! Besides the certificate problems, are there other problems with > PEM that have prevented its adoption? That's it. PEM "blew it" by relying on Internet-wide X.500/X.509 deployments. They're now looking at self-signed certificates as a transition aide to work around the adoption problems, particular in face of the pressure brought by the success of PGP. /r$

1 0