- cypherpunks-legacy - lists.cpunks.org

Re: java security & the cypherpunk agenda
by Rich Salz 17 Dec '03

17 Dec '03

>From what I have seen of the CV's of the Java team (at least those who have/had home pages on the various Sun java servers), none of them were particularly security-aware. /r$

1 0

Re: Certificate proposal
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:46 AM 10/9/95 -0700, Hal wrote: >>This doesn't necessarily eliminate certificates - while you have a signed >>statement from Alice's key that she uses Bank Account X, and a signed statement >>from Alice's key authorizing transfer of $D from Bank Account X to Bank >>Account Y, >>the Bank, or a customer, may refuse to accept the request unless there's >>a signed statement from the Bank's key that Alice's key uses Account X. >>None of these need Alice's name, or for that matter the Bank's, as long as >>there's >>also a signed attribute statement from the Bank's key that it's a bank, etc. >>The meaning of the certificates changes a bit, but there's still a certificate >>from the bank binding Alice's Key to Alice's Bank Account. > >I can see using keys with attributes in this way, for credentials or as >other forms of authorization. But what about for communications privacy? >What is the attribute that tells you that using this key will prevent >eavesdropping? What I was trying to get at with this post was that the assertion that key- centered communications probably won't require certificates is incorrect. As far as privacy goes, this set of keys and certifications lets you create private communications (using signed DH, etc.) with the entity that owns the private key for Bank Account X. No, you don't know if that entity is really Alice or really MITM; in fact you don't know Alice's name, if it's done right. You just know that the Bank says it will honor requests for money from Bank Account X (assuming you know where to find the Bank, which is a separate but similar problem.) So assuming you're selling politically correct widgets and not pharmaceuticals or financial privacy consulting services, you probably don't care too much about who's on the other end - the person who's giving you the money is the person you want to be talking to. I'm not trying to define away the MITM problem - I think there _are_ times you want to know for sure who you're talking to - but I think there are also a lot of times that you really don't care, as long as you have continuity and access to reputations of long-persisting identities, where the key is often enough identification. In the case of the Bank, the reason you trust the Bank isn't that you know them physically (though it was interesting when I started dealing with a local bank where the tellers knew me by name after only two or three visits); knowing your local Savings and Loan by name doesn't guarantee you can get any money out of them if there's a bank run, nor does it really guarantee that they won't embezzle the funds and head for Argentina. The reason you trust them is that they (in this case the "they" identified by their key) are doing business dealings with a lot of people and it's more profitable not to abscond. And the reason you know it's really the Bank and not MITM is that they've always identified themselves by their key from the beginning. Just like the credit card who's owner we've been calling Alice has. And because you've successfully withdrawn money from the Bank before, and because you're clearing Alice's credit card transaction reasonably promptly. Checks and credit cards are especially good examples for this - the current systems need your name on them, because your name and signature are the closest they have to an authentication system. However, with digital signatures, the fact that you can sign a document verifiable by the public key is all the authentication that's needed; your name isn't. If the card has an account number for convenience, and Alice substitutes Carol's account number for hers on a statement, her signature won't match the public key the bank wants on the request, and it'll bounce. (In this case, the certificate from the bank would probably include the account number as well as the key, but it's not critical for on-line systems, just more efficient.) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

[NOISE] was Re: java security concerns
by Frank Stuart 17 Dec '03

17 Dec '03

This is a bit off-topic, but hopefully interesting. Rather than trying to prove a program to be correct (which I agree is doomed to failure for the forseeable future for all but trivial programs), perhaps it would be useful to have an automated therom-prover to try to deduce "interesting things" about certain programs such as "this program always bounds-checks its input", "this program allows writes to arbitrary files on lines x, y, and z", "this program halts". (:>) Obviously (as the last example illustrates), this isn't perfect because something can be true without being provable. Further, it's likely that assumptions must be made about system calls, libraries, and the ways in which they interact. There's also the problem of "who proves the prover". However, I think such a tool would be useful because it may quickly point out things not obvious to (most) humans and getting some idea of what can't be deduced and why would be instructive. | (Douglas) Hofstadter's Law: Frank Stuart | It always takes longer than you expect, even fstuart(a)vetmed.auburn.edu | when you take into account Hofstadter's Law.

2 1

Re: Certificate proposal
by jbaber＠mi.leeds.ac.uk 17 Dec '03

17 Dec '03

Hal <hfinney(a)shell.portal.com> writes: >The POV I am really arguing against is the one that defines identity to >be a key, that states that in communicating with a key you are by >definition communicating with the person you have in mind. The man in >the middle attack does not exist because from your point of view the >entity at the other end of the communication channel is just the MITM >plus the person you think you are talking to. This idea has been >expressed many times by other people in this discussion, and it is this >which I think is fundamentally flawed and even dangerous because it >encourages the use of untested keys. In fact it seems to define away >the question of whether a key is real or fake. It defines away the question of whether a key is real or fake because the key itself can not be fake. Assuming strong encryption anything that you send to the key can only be read by the key and anyone that he/she choses to pass it on to (something that can not be stopped). The only thing that can be fake about the key is the attributes associated with it - whether the attributes concerned are true names or the ability to use a bank account. Having a man in the middle when no attributes are concerned is simply the same as talking to someone who passes all of your messages on to a friend and then expresses the friends opinion rather than his/her own back to you... something that I can think of no possible way to stop. So although you are talking talking to A the opinions expressed are those of B, and there is no way of telling - in the same way as a man in the middle attack (B may not even know that his/her arguments are being used by A against you). This argument reduces the problem to 'how do you validate key attributes' as you can be sure that you are communicating securely with the key (key's owner) but nothing else. With PGP currently the only attribute that a key (X) may have is a name (true/pseudo) and this attribute can be signed as valid by another key (Z). If you accept the signature all you are doing is saying that you accept the signing key's certification - ie an attribute signed by this key (Z) is true. Eventually you have to just trust a key to have taken reasonable care to ensure that any attribute that it has signed is true - whether you are using a Web of Trust model or a more centralised model such as accepting VeriSign certificates (or your own - knowing exactly how much care you have taken to ensure that the attribute that you have certified (signed) is true). I believe that this is more removing a special case (treating the true name differently from any other attribute) than defining away the problem - even though the (MITM) problem does cease to exist. Jon jbaber(a)mi.leeds.ac.uk http://www.chem.surrey.ac.uk/~ch02jb/

1 0

Re: netscape mail starts java attachments upon get new mail...
by Rich Salz 17 Dec '03

17 Dec '03

> Java applets can't read /etc/passwd, and can't issue NIS requests unless > they were downloaded from an HTTP server running on the NIS server Oh, you mean like a mirror or local cache? (Sure, Rocky, never happen...) > (actually, they can't do UDP at the moment, so that's out as well) Even with TIRPC NIS is still UDP-only? Has NIS+ fixed this? /r$

2 1

Re: Basic Flaws in Internet Security and Commerce
by pjb＠ny.ubs.com 17 Dec '03

17 Dec '03

A fine piece of work. The ideas expressed in this paper should scare the hell out of everyone who uses NFS for any serious applications, which for a fact includes most banks and all investment banks and brokage houses. In this particular area I KNOW what is at risk. Again, I congratulate the authors on a first-class effort. cheers, paul > From owner-cypherpunks(a)toad.com Tue Oct 10 03:15:15 1995 > From: gauthier(a)espresso.CS.Berkeley.EDU (Paul_A Gauthier) > To: cypherpunks(a)toad.com, bugtraq(a)crimelab.com > Cc: gauthier(a)cs.Berkeley.EDU, brewer(a)cs.Berkeley.EDU, iang(a)cs.Berkeley.EDU, > daw(a)cs.Berkeley.EDU, fur(a)netscape.com > Subject: Basic Flaws in Internet Security and Commerce > Date: Mon, 09 Oct 1995 14:26:06 -0700 > Sender: owner-cypherpunks(a)toad.com > Content-Length: 10235 >

1 0

William S. Powell in front of Congress Oct 11, 10:30 AM
by fc＠all.net 17 Dec '03

17 Dec '03

William S. Powell is the person who firs patented an electronic money system (almost 15 years ago now), and he will be testafying before the congressional subcommittee tomorrow - Oct. 11, 1995 at 10:30 AM (scheduled). If you really want to know about electronic cash and how our society has treated it over the last 15 years, you might want to watch this. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

My Last Message
by Duncan Frissell 17 Dec '03

17 Dec '03

Oops! My last message was a letter to the editor of the Economist. I forgot to mention that. DCF

1 0

Re: java security concerns
by cman＠communities.com 17 Dec '03

17 Dec '03

Simon Spero wrote: >In my previous message, I left out some fundamental parts of the run-time >that need to be looked at carefully. The garbage collection needs to be >examined carefully. Normally GC algorithms are formally derived, so it's >the implementation that needs to be checked for. holes in the GC may be >too unpredictable to exploit for anything but core-dumping, especially since >java uses a mark-sweep conservative collector. > FWIW, we had some ideas about how to attack the GC from untrusted code, involving resurrection of objects during finalization. This turned out not to work -- the Javoids apparently anticipated this problem in their design.

1 0

Re: PC disk wipe software
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Responding to msg by bdavis(a)dg.thepoint.net (Brian Davis) on Tue, 10 Oct 10:47 AM >FYI the Justice Department requires degaussing a hard >drive before it can be declared surplus ... ----- The Washington Post, Oct 9, 1995. E-Mail That Comes Back And Bites. Even Deleted Messages Can Be Recovered for Court [excerpts] Computer sleuth John Jessen dredges computer files for electronic embarrassments that their authors thought were long gone. "Deleted" e-mail messages can pile up like little time bombs until someone such as Jessen arrives, carrying a court order and a stack of blank memory cartridges. "Can you really delete e-mail? Sure," Jessen said. "Does it happen as a common practice? No." Jessen is the founder of Electronic Evidence Discovery Inc., a Seattle company that since 1987 has been going after computer evidence in civil lawsuits. The nation's 25 million to 40 million users of e-mail are growing more comfortable with the medium. And more attorneys are recognizing e-mail's potential as a source of unguarded information about the companies they're suing. "People are very candid talking around the coffee machine." attorney Michael Patrick of Palo Alto, Calif., said. "They seem to behave the same way on the computer system. "They think they're speaking confidentially, so they're off the cuff," he said. "They're very often insulting. What they don't realize is it's all being recorded, and often those recordings are stored for a very long time. When you send a message, you lose control over where it goes." Many workers think their e-mail is private. It's not. Federal law allows employers to monitor employees' e-mail, and even if they don't, e-mail is fair game in lawsuits. When someone sues a company, the rules of discovery demand that the company produce all relevant business records. "The fact that they live in a computer rather than a file cabinet doesn't make any difference to the court," said Joan Feldman at Computer Forensics, another Seattle firm that specializes in this work. Often files retrieved include e-mail thought to have been erased long ago. It survives because the diligent computer system manager makes backup tapes of everything on the system every night, then stores those tapes for years. And so the files persist and multiply, aided by technological advances that continually add more storage capacity, more automatic backups and more redundancies to safeguard data from accidental erasure. "The computer is like a file cabinet tbat can open its own drawer, put a file on the copy machine and then slip the copy into another cabinet," Jessen said. "Sometimes I think it's alive." Jessen and Feldman augment their high-tech detective work by advising companies how to become less vulnerable to computer snoops like themselves: They recommend regular purges of old data, and they offer tips for avoiding e-mail blunders in the first place. Rule No. 1: Don't put anything on e-mail that you wouldn't want a jury to see. -----

4 5