- cypherpunks-legacy - lists.cpunks.org

Re: O.J. ObCrypto: Fuhrman's Folly Fans Fakery Fears...
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 23:50 8/30/95, MONTY HARDER wrote: >I recommend that anyone who will be using escrowed keys generate two >pairs: First, the signature key, including in the userid some kind of >[sig use] identifier (we should settle on a standard abbreviation for >this) follower by the encryption key. This way, when a person gets your >pubkeys, they get the encryption key =last=, which gets it searched >first whenever they PGP -e... something. > > Whatever arrangements are made for escrowing my encryption key, >=nobody= gets my signature key. If I am fired, quit, become brain >damaged or dead, my key can never be used by anyone to implicate me in >any criminal activity. > > > > Please don't mention to anyone the fact that my signature key can be >used to send me something that even the escrow agents can't read.... I do not think that PGP 2.x can easily (ie: Automatically) use one key for Signing and another for Encrypting a Message (it does both at the same time if you ask). If I "Clear Sign" a message and then Encrypt it, then I get the result but I'm not sure if doing the decrypt on such a message will automatically spot the signature and verify it (as would occur with a E+S pass). PGP3 is supposed to have the ability to have keysets that contain two keys for this purpose (ie: When you generate a key set you can ask it to generate separate Sign and Encrypt keys so that separate keys get used for each function).

2 1

Re: SSL search attack
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > I see nothing wrong with the concept of being allocated an initial chunk > and having the scan software attempt to ACK it when 50% of it has been > searched. A successful ACK would allow the releasing of a new chunk (in > response) equal in size to the returned chunk. A failure of the Server to > accept the ACK would trigger a retry at set intervals (such as 75% and 100% > or 60/70/80/90/100%) until the Server responds. Thus the scanner is always > in possession of a Full Sized Chuck to scan (so long as the Server accepts > an ACK before the 100% done mark) and temporary failures will not stop the > process of a scanner as currently happens. > The only way this can work is if the server is told it is a 50%/75%/etc size ACK, and then latter the server is ACKed for the full 100%. Why? Because what happens if the client dies immediately after doing the ACK - maybe only 51% of that space has been searched, yet the server has already seen an ACK for it. IMO - a % ACK is to much complexity and extra work on the server, which is already having trouble keeping up. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

2 1

Ames Criminal Complaint
by John Young 17 Dec '03

17 Dec '03

We've put the 39-page criminal complaint against Aldrich Ames and Rosario Ames, with arrest warrant and requests for search and seizure at: http://jya.com/ames.htm (93K) Which may be compared to those of Jim Bell, in order, as Bob Hettinga merrily portends, to ready us to ponder each our own upcoming toilet plunge. Too bad that Jim didn't get (or hasn't yet gotten) the kind of swell-solitary-cell Rick and Rosario briefly enjoyed for CIA toilet diving (a la Trainspotting).

1 0

Re: opinions on RSA Secure?
by Bill Stewart 17 Dec '03

17 Dec '03

>> The fact that the key is only 80 is *major* compromise. I would >> recommend that package to no-one. With only a 80 bit key you dont >> *need* trapdoors, granted they may be more "convenient" but the fact is >> the 80 key *can* [and certainly will] be broken... 80 is an interesting number. Clipper-sized :-) It's much less than 128, which seems to be popular for other software and works well with MD5-based random session key generators. It's also interestingly bigger than 64, which the Feds are trying to tell us is good enough for non-government work. Are RSA giving in to the Feds? Or are they trying to up the bid, at least allowing us something as good as Clipper if we can't get 128? Not my poker game. Let's look at some threat models. It's probably more than strong enough for any data you're willing to keep on a machine running MS-DOS, where serious attackers will go around it; it's about right for random "left your laptop in the airport" security, and for business use, if the police are going to confiscate your machine, they can probably subpoena the keys from somebody in your company anyway. Random hackers aren't going to be able to crack it, unlike 40-48 or maybe 56. It's big enough that the NSA probably can't break it right now, but in 10-20 years of computer speed growth they'll be able to if they want. It's probably fine for dealing with amounts less than $1-100M for maybe 10 years, and for misdemeanors and light felonies if you're not using the key escrow :-) And in 5 years, you'll be using a different operating system (even if it _is_ named "Windows"), so you'll need a new version, and you can re-encrypt your data when you move it to a decent-sized disk instead of that wimpy 9GB mechanical drive. Anybody who's got a 5-year-old dump of your system has probably stolen any secrets you care about long since anyway. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: SSL search attack
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > At 7:25 AM 9/1/95, Daniel R. Oelke wrote: > >> > >> I see nothing wrong with the concept of being allocated an initial chunk > >> and having the scan software attempt to ACK it when 50% of it has been > >> searched. A successful ACK would allow the releasing of a new chunk (in > >> response) equal in size to the returned chunk. A failure of the Server to > >> accept the ACK would trigger a retry at set intervals (such as 75% and 100% > >> or 60/70/80/90/100%) until the Server responds. Thus the scanner is always > >> in possession of a Full Sized Chuck to scan (so long as the Server accepts > >> an ACK before the 100% done mark) and temporary failures will not stop the > >> process of a scanner as currently happens. > >> > > > >The only way this can work is if the server is told it is a 50%/75%/etc > >size ACK, and then latter the server is ACKed for the full 100%. > > > >Why? Because what happens if the client dies immediately after doing > >the ACK - maybe only 51% of that space has been searched, yet > >the server has already seen an ACK for it. > > You NEVER claim to have searched space until you have actually done so. That is exactly what I was arguing against - but the first sentance of what I quoted was saying was ok. > Assuming that you are multi-threaded--- Simply run two "workers" on the > same machine. If there are delays in getting keys assigned, the two will > soon get out of phase and keep the cpu busy. > I kind of like that idea... Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

3 3

Re: FCPUNX:Getting ecash without an MTB account
by James A. Donald 17 Dec '03

17 Dec '03

On Fri, 15 Aug 1997, Mike wrote: >> Are you referring to the receiver anonymous protocol? >> >> This is how I understand that protocol, >> >> Alice wants to receive e$1 from Bob. She creates a random number, blinds >> it, and gives the blinded number to Bob. He shows the number to the >> Mint, asking for a withdrawal of e$1 with a signature on this coin >> number. Bob gives the signed and still blinded coin to Alice. She >> unblinds it and spends it, end of story. At 10:24 AM 8/15/97 -0700, Alan wrote: > Actually the coin is intercepted and spent by Mallet. Alice gets pissed > at Bob because she feels cheated by him. Mallet cannot intercept the coin, because only Alice can unblind it. Mallet cannot provide Bob with a number blinded by him, rather than Alice, because Alice signed the blinded number >> I thought that in this scenario, Bob can spend the coin before he gives >> it to Alice, No he cannot, because only Alice can unblind the coin. > My understanding of the protocol is that the identity of the purchacer is > revealed only if the coin is double spent. The identity of Bob is known by Alice and the bank. No one can ever discover the identity of Alice from the coin. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

Re: Canarypunk: Jim Bell in a coalmine
by John Young 17 Dec '03

17 Dec '03

>From the Privacy Act Online via GPO Access [wais.access.gpo.gov] [DOCID:tres_irs-99] DEPARTMENT OF TREASURY Treasury/IRS 60.001 System name: Assault and Threat Investigation Files, Inspection--Treasury/IRS. System location: Office of the Chief Inspector, National Office; Regional Inspectors' Offices; as well as offices of the District Directors. (See IRS appendix A for addresses.) Categories of individuals covered by the system: Individuals attempting to interfere with the administration of Internal Revenue laws through threats, assaults or forcible interference of any officer or employee while discharging the official duties of his position, or individuals classified as potentially dangerous taxpayers, based on verifiable evidence or information that fit the following criteria: (1) Taxpayers who physically assault an employee; (2) taxpayers who have on hand a deadly or dangerous weapon when meeting with an employee and it is apparent their purpose is to intimidate the employee; (3) taxpayers who make specific threats to do bodily harm to an employee; (4) taxpayers who use animals to threaten or intimidate an employee; (5) taxpayers who have committed the acts set forth in any of the above criteria (1) through (4), but whose acts have been directed against employees of other governmental agencies at Federal, state, county, or local levels; (6) taxpayers who are not classifiable as potentially dangerous through application of the above criteria (1) through (5), but who have demonstrated a clear propensity toward violence through acts of violent behavior to a serious and extreme degree within the five (5) year period immediately preceding the time of classification as potentially dangerous; and (7) persons who are active members in chapters of tax protest groups that advocate violence against IRS employees. ...

1 0

Key Escrow Workshop agenda & discussion paper 3
by Pat Farrell 17 Dec '03

17 Dec '03

The following message segment: ------------------------------ From: Arlene Carlton <carlton(a)micf.nist.gov> Fri, 01 Sep 1995 15:30:46 -0400 Cc: carlton(a)micf.nist.gov Subject: Key Escrow Workshop agenda & discussion paper 3 September 1, 1995 Dear Participant: Thank you for agreeing to participate in the two-day meeting on software key escrow encryption. We are anxious to work with you and other industry representatives to facilitate development of exportable key escrow encryption in software products. I look forward to the workshop being an important step in that process. [snip] --------------------------------- Was sent to the following folks. I assume that this means that these people are participants. I see Dan W from CDT, Soble from EPIC and Whitfield Diffie, on our side, plus assorted folks with stakes such as tis.com and netscape.com And of course, DERD for the other side. Blank Unicorn had posted to c'punks that he was attending. Of course, while I know what he looks like, I have no idea which nym is his. Pat List of attendees/registered participants follows: 100436.3361(a)compuserve.com, 73167.2027(a)compuserve.com, 73534.3011(a)compuserve.com, 75300.3232(a)compuserve.com, 76225.2603(a)compuserve.com, ablee(a)mitre.org, ads012(a)email.corp.mot.com, ams(a)eit.com, amte09(a)email.corp.mot.com, asteen(a)novell.com, baum(a)world.std.com, bekutz(a)aol.com, bflowe(a)mcimail.com, bill.poulos(a)oga.eds.com, bill.poulos(a)oga.eds.com, branstad(a)tis.com, bsaclu(a)aol.com, c.baggett(a)cablelabs.com, carol.donovan(a)network.com, ccrafton(a)gi.com, charlesabzug(a)acm.org, ckc(a)rfpo1.rfc.comm.harris.com, cmo(a)cohnmarks.com, coallen(a)us.oracle.com, cpadilla(a)attmail.com, cpadilla(a)attmail.com, csmith(a)steptoe.com, davery(a)grci.com, david_rose(a)ccm.fm.intel.com, ddodson(a)nist.gov, denning(a)cs.cosc.georgetown.edu, deyoung(a)rpcp.mit.edu, dinsmore(a)tis.com, djw(a)cdt.org, dkozlay(a)ire.com, dmiller(a)spa.org, Don_Sortor-ads012(a)email.corp.mot.com, ebarker(a)nist.gov, ed(a)tecsec.com, emessmer(a)world.std.com, ezzy_dabbish-amte09(a)email.corp.mot.com, flahavin(a)csmes.ncsl.nist.gov french(a)zeke.enet.dec.com, gomes(a)dockmaster.ncsc.mil, gordon(a)ipower.nsc.com, hoffman(a)seas.gwu.edu, housley(a)spyrus.com, hoydyshd(a)mcln.unisysgsg.com, i.goldsmith(a)nexor.co.uk, infocker(a)megaweb.com, jackk(a)microsoft.com, jag(a)jgvandyke.com, jaltman(a)milchev.com, jamanni(a)missi.ncsc.mil, james.hughes(a)network.com, jdrandall(a)vnet.ibm.com, jean_m_baronas(a)co.xerox.com, jeff.rulifson(a)Eng.Sun.COM, jeff(a)netscape.com, jerry(a)ods.com, jgheiner(a)aol.com, jimmy(a)ipower.nsc.com, jimn(a)calv1.cray.com, jkrauss(a)cpcug.org, john(a)ipower.nsc.com, john_pascatore(a)ivision.com, jroberts(a)cmp.com, js(a)cup.hp.com, jseiger(a)cdt.org, jwinston(a)ota.gov, jya(a)pipeline.com, jya(a)pipeline.com, kandy(a)micf.nist.gov, karen.randall(a)att.com, kawamoto(a)mitre.org, kaye(a)ix.netcom.com, kent_landfield(a)sterling.com, khrose(a)annap.infi.net, klensin(a)mci.net, lc2m(a)andrew.cmu.edu, lcarnahan(a)nist.gov, lhg(a)nrc.gov, lovornj(a)usva8.dyncorp.com, lshomo(a)hqops.hq.nasa.gov, lthrash(a)hqamc.army.mil, lydia.bell(a)tip.navsea.navy.mil, maitgmu(a)aol.com, martin.ferris(a)treas.sprint.com, mary_smolenski(a)ita.doc.gov, mbohannon(a)banyan.doc.gov, mccord(a)nosc.mil, melanie.carter-maguire(a)nt.com, mendelson(a)tis.com, mfa(a)compaq.com, michael.palgon(a)sciatl.com, mignon(a)atc.boeing.com, mikus(a)viacrypt.com, mjl(a)liii.com, mpapillo(a)snap.org, mpapillo(a)snap.org, mppulkk(a)mikropc.fi, mrainey(a)itic.nw.dc.us, murray2(a)vnet.ibm.com, natstrat(a)dgs.dgsys.com, nazario(a)csmes.ncsl.nist.gov, paradise(a)wellsfargo.com, pfarrell(a)netcom.com, pjclark(a)ix.netcom.com, po7114(a)email.mot.com, polk(a)csmes.ncsl.nist.gov, powar(a)visa.com, randy(a)mci.net, ravenis(a)novell.wd.cubic.com, rjg9324(a)glaxo.com, rjoconnor(a)aol.com, rmedlock(a)mitre.org, roberth(a)bsa.org, rolfe.doc.gov(a)micf.nist.gov, rozzie(a)iris.com, rwessman(a)us.oracle.com, sbaker(a)steptoe.com, Schneck(a)mitre.org, Schneck(a)ncsl.nist.gov, sevans(a)csn.com, shabbir(a)panix.com, simona(a)sea.org, sking(a)mitre.org, sltm(a)msg.ti.com, snouffer(a)st1.ncsl.nist.gov, sobel(a)epic.org, squires(a)arpa.mil, stuart(a)bellcore.com, stw(a)atc.boeing.com, sullivan(a)interramp.com, tajalli(a)tis.com, tec.teclgl(a)micf.nist.gov, ted_gerbracht(a)ml.com, tfuhrman(a)ostp.eop.gov, thomas_clare(a)sterling.com, trivers(a)is.ge.com, trstsc(a)tevm2.nsc.com, ttobin(a)atl.ge.com, wafranklin(a)attmail.com, walker(a)tis.com, walt(a)osf.org, walters(a)snad.ncsl.nist.gov, wford(a)bnr.ca, whitehurst(a)vnet.ibm.com, whitfield.diffie(a)Eng.Sun.COM, whpayne(a)abq-ros.com, wmcglone(a)milchev.com, wright(a)dockmaster.ncsc.mil, Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

No Subject
by A5113643667＠attpls.net 17 Dec '03

17 Dec '03

Dear Cypherpunks and Tom, The ones I've heard about are SKIP, Photurus and ISAKMP(sp?). Peace --- NOTICE: This message originally included graphics and/or sounds which can only be received by AT&T PersonaLink(sm) subscribers. You received only the text portion(s) of the message. Please contact the sender for information that was deleted. To learn how to send and receive graphics, voice and text messages via AT&T PersonaLink Services, call 1-800-936-LINK. ---------------- Received: by attpls.net with Magicmail;12 Sep 95 10:34:32 UT Date: 12 Sep 95 13:05:43 UT Sender: owner-cypherpunks(a)toad.com (owner-cypherpunks) From: owner-cypherpunks(a)toad.com (owner-cypherpunks) Subject: Re: draft key mgmt props To: peace(a)acm.org (Tom Jones) cc: cypherpunks(a)toad.com (Cypherpunks) Message-Id: <199509121024.GAA15929(a)frankenstein.piermont.com> In-Reply-To: <Your message of "Tue, 12 Sep 1995 07:15:16 -0000." <3E79EDD0>> Reply-To: perry(a)piermont.com (perry) X-X-AUTHENTICATION-WARNING: frankenstein.piermont.com: Host localhost didn't use HELO protocol X-X-REPOSTING-POLICY: redistribute only with permission Tom Jones writes: > Does anyone here feel like explaining the situation between the three > key management proposals now at the internet draft stage? Which ones are you refering to? .pm ----------------

2 1

Re: Digital Fingerprinting
by Peter Trei 17 Dec '03

17 Dec '03

> Finding the mail mixed in there is evidence that supports the "charge" > but surely can be rebutted. When I was practicing in a small town c. > 1984, people would be summoned (sent a paper telling them to show up) to > court for illegal dumping if their mail was found with other trash, old > refrigerators, etc., in a creek somewhere. Those charged could always > put on proof that Billy Bob's garbage service picked up their trash ... > The sentence was almost always to go and pick up some multiple of the > garbage found and take it to the landfill. This was Stockbridge, in MA, right :-? That's what we did, and drove back to the church, had a thanksgiving dinner that couldn't be beat, went to sleep and didn't get up until the next morning, when we got a phone call from officer Obie. Said "Kid, we found your name on an envelope at the bottom of a half a ton of garbage, and just wanted to know if you had any information bout it". I said "Yes Sir Officer Obie, I cannot tell a lie, I put that envelope under that garbage." (c) Arlo Guthrie Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

3 3