December 2003 - cypherpunks-legacy

Re: A problem with anonymity
by Bill Stewart 17 Dec '03

17 Dec '03

Scott Brickner's example has fairly close analogies today. Corporations, cash, and assets with variable value are already useful. Alice is the dying parent who runs a business or has a good credit-rating. Bob is the irresponsible kid, Carol is the about-to-be unlucky creditor. Alice borrows lots of money from Carol, tells Bob that it's in the mattress / numbered Swiss Bank Account / collection of $$$$ artwork at home. Alice dies, and Bob absconds with the money (probate isn't needed for Swiss bank accounts or unrecorded stuff in mattresses) or sells the paintings to the highest bidder of Dave, Eve, and Freddie (with a bribe to all of them, and a kickback from Dave when he finally sells the painting for its real value.) (Or maybe it's not bribery and kickbacks, he's just a major shareholder in the Glorkspitz corporation, which is a major shareholder in their businesses.) Carol is stuck trying to get money out of The Alice Estate, which turns out to be surprisingly broke. If she lent the money to The Alice Company (which looks more creditworthy than Chronologically Challenged Widow Alice), Alice would have had to leave Bob the yellow-sticky with the store safe combination instead of leaving the cash in her mattress. Now, one reason we have probate courts is to try to stop this sort of fraud, making sure creditors get paid and heirs get their shares. Another reason, of course, is to make sure "Uncle" Sammy gets to inherit part of it, even though he's not a relative. (That's of course one of the reasons for having Swiss bank accounts you didn't remember to mention on your tax forms, fireproof mattresses, foreign corporations, and friends in the art dealer business :-) Does good anonymity make this easier? Sure. And if all the heirs are cooperative, they can conspire to rip off their parents' creditors, if they're dishonest, or at least to avoid taxes, if they're not tax-believers. Of course, if they're dishonest, they'll have plenty of opportunities without having anybody die, and that'll probably affect bankruptcy law and increase Federal self-justification for watching the money supply long before anonymous estate ripoffs become common. #--- # 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: Phil Zimmermann/Amnesty International?
by rudy (r.) rawlins 17 Dec '03

17 Dec '03

In message "Phil Zimmermann/Amnesty International?", rrothenb(a)ic.sunysb.edu writes: > > > > I was wondering if the Zimmermann case would be a proper concern of > > Amnesty International. [snip] > > > I've heard that A.I. does not discuss political persecution as much in > the countries that are doing it, since they do not want to offend the > powers-that-be in that country, though they will note a case in another > country. (In other words, if A.I. did note the PRZ case they'd only > discuss it outside the United States.) > > This is just speculation though... > You're right on the speculation; A.I. has no such policy. As a matter of fact, they will meet face to face with government officials to seek the release of 'prisoners of conscious' - which is a possible category for Phil Z. Though Phil, despite what we may think, is not a prisoner, yet..

1 0

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

TestTest
by Anonymous 17 Dec '03

17 Dec '03

Test

1 0

No Subject
by Pasquale Piombino 17 Dec '03

17 Dec '03

Hi all, I am searching PGP software. Does anyone know where I can download it? Thanks for answers. -+-+------------------->->--------------------------------:-Q------------ ° Pasquale Piombino | | Via Colombo, 35 Email: mr.xxx(a)ce.flashnet.it ° ° I-81100 CASERTA Phone - Fax: 0039 823 329152 | | ITALY ° +-+-------------8-)---------------------:-))-----------------:-o---------

1 0

Re: Some details on RSA Secure
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:48 AM 8/31/95 PST, "baldwin" <baldwin(a)RSA.COM (Robert W. Baldwin)> wrote: >Here are my biased comments on RSA Secure. They are biased by >the fact that I an a techie who works for RSA Data Security. >Neatest Features: >- It is integrated with the File Manager on Windows and the > Finder on Mac System 7. It's an interesting approach - simpler than installing as a file system (I'm not using SecDrv because it needs a separate partition), but so far it seems relatively useable. On the other hand, since there are file types it refuses to encrypt, like DLLs, there are some things it can't protect (like DLLs with passwords embedded in them.) >- A settable list of files can be automatically decrypted (or > encrypted) on system startup (or shutdown). I've got mixed feelings about this - since my password has normally timed out by the time I shut down, it demands a password before shutting down, and if I had any large amount of data there, I assume it would take a while to reencrypt on my 386-box. (Laptops are generally slower than similar-age desktops, and you often want to shut them down quickly, even when they aren't shutting themselves down to save power.) I haven't tried powering it off during this process, but I assume that at best the files would be unencrypted and at worst there'd be one half-decrypted and sitting in limbo to be trashed the next time the system starts up? >Technical Features: >- The user's passphrase unlocks a master key that is used to unlock > the file encryption key for each file. Since the documentation mentions 512-bit and 1024-bit RSA keys, I'd guess that each file has a separate random RC4 key which is stored in the file header, encrypted with the user and escrow RSA keys plus the MD5 hash, plus the encrypted real filename? (The alternative would be that the userpref.!!! file contains an RC4 key encrypted with RSA, which is used to encrypt the file keys, but that would lead to much shorter headers, and cracking that master RC4 key would then allow cracking of all documents on the system, so I'm guessing that's not the approach used.) >Request for Improvements: 1) The "Emergency" menu item in the File Manager is annoying. Could it be combined with the RSA menu item, eliminated, or at least have the option of abbreviating the name? 2) Can keys and files be shared between multiple machines, i.e. the same user keys on a desktop and laptop, so that individual encrypted files can easily be moved back and forth? #--- # 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: 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

Re: SSL search attack
by rkw＠dataplex.net 17 Dec '03

17 Dec '03

I wrote >>> 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... > To which Piete Brooks replied: >I thought of that, but: >1) for the same server load, it doubles the number of unACKed segments >2) if process A is lagging process B, then when process B finishes and is idle > waiting for the server, process A will run faster and thus reduce the lag. > This will make the processes drift into phase. > I'm not convinced one way or the other. But you forgot that when process A finishes, process B will run faster and re-establish its lead. The real question is what is the parameter that we need to minimize? Assuming that the key is distributed in the keyspace with a uniform probability, then what we need to minimize is the expectation that two or more workers are searching the same keyspace. As long as we never reach the point that all of the keys have been distributed, it does not matter how many or in what method they are assigned. (The "fairness" WRT a prize being ignored) The assignments only become important as we exhaust the space and must prepare to make another pass. Note that we never got to that point on challenge 2. The assignment of the block containing the key was processed on its first pass and the key was found. In this regard, it is probably "best" to first attempt to identify those space assignments that have been lost. If we associate with each key, either explicitly, or by inference, an expected completion time, those segments which are most overdue are certainly good candidates for having been lost. Based on our previous try, and the assumption that we would not have extremely different resources available, the master allocator would not NEED to get reports back for the first say 12 hours. That is not to imply that reports should be delayed that long, but only that there is considerable opportunity to have a hierarcy of intermediate collectors that have plenty of time to adjust their allocation algorithms to match the ability of their workers. Later, more rapid response would be needed. When the required response becomes too small for the "little guys", they could be sloughed off on the next problem, leaving the "big boys" to clean up the last pieces. Of course, the "next" problem might be to resolve the same problem because the correct answer was incorrectly reported as not found. As I see it, except for perhaps the fastest of machines there is little reason to allocate to the workers more than one segment at a time. Their supervisor can quickly respond to requests for work and consolidate the results to be passed up the chain. The only reason that I can see to separate the acks from the assignments is to be able to have "memory-less" nodes. This is certainly unnecessary if there is a web of supervisor servers. I have a lot more thoughts that I will defer to the next missive. Gotta' run... ---- Richard Wackerbarth rkw(a)dataplex.net

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