Re: issuing smartcards is likely to be cheap [Was: electronic ballots]
Hmmm, I have a "voter registration card" and I believe that is the case across the USA. It is not. /r$ [True enough. --Perry]
Re: Historical PKI resources
Here's the BibTeX entry for the paper that apparently "started it all".. The D-H paper is the public start of public-key crypto. The scientific American article by Gardner explained, pre-patent-issuance, RSA to the world. The start of PKI is an MIT Master's Thesis that created certificates. Sorry, no references to any of the above. Should not be hard to find. The adoption by X.509 for use as authentication in X.500 got us common technology, and is probably the only reason anyone will ever have to learn ASN.1 and DER. :) The old IETF PEM project gave us "---BEGIN" lines :) and showed empirically that global X.500 deployment is a non-starter. RSA's version, which became the IETF's S/MIME showed how to do it practically. I'll stop now before I get too cynical. :) /r$
Re: Historical PKI resources
R sent me a nice note pointing out that it was actually a bachelor's
thesis, supervised by A. Apparently unpublished.
/r$ (not S, and certainly not *that* S :)
@unpublished{Kohnfelder78,
author = {Kohnfelder, Loren M.},
title ={Towards a Practical Public-Key Cryptosystem},
year = 1978,
month =May,
note = {B.S. Thesis, supervised by L. Adleman}
}
Hush Communications gets silly patent
"DUBLIN, Ireland--(BUSINESS WIRE)--Jan. 8, 2001-- Hush Communications (www.hush.com), a leading global provider of managed security solutions and encryption key serving technology, today announced it has been granted a patent for its revolutionary key pair management technology that enables personal computer users to send and receive fully encrypted electronic communications. Hush Communications, the category leader in key pair management technology, now has the exclusive intellectual ownership of its core technology, the Hush Encryption Engine(TM). " Full PR in http://biz.yahoo.com/bw/010108/hush_commu.html US Patent 6154543. It seems to be nothing more than store the private key on a server, give it out when the user presents the hash of their initial passphrase. Similar technology was part of DCE in 1996, cf http://www.opengroup.org/rfc/mirror-rfc/rfc94.1.txt Sigh... /r$
Re: IBM press release - encryption and authentication
No word, of course, on how the thing actually works, or whether they intend to patent it. Not so. Search your nearest IETF internet-drafts repository for draft-jutla-ietf-ipsec-esp-iapm-00.txt And in there you will find 5. Intellectual Property Issues IBM has filed U.S. patents on this mode and its vari- ants in April, 2000. Ennui has its places, this just wasn't one of them. :) /r$
Re: Java binding to OpenSSL?
SWIG (www.swig.org) is a scripting-interface generator; it reads C/C++ header files and generates stubs for python,java(bleeding edge),tcl,perl. m2crypto (http://www.post1.com/home/ngps) is a nice swig'd set of openssl header files. oriented for python, it should work with java too. /r$
Re: Lots of random numbers
Thanks, all, for the review; I greatly appreciate it. The overall system will be online, and on the net, generating keys 24x7. I can follow best practices to firewall the network, and physical access by an adversary is impossible (I now this is a strong statement, but it *is* outside of my threat model). The keygen machines would periodically grab some entropy over the local net and mix it into their own; this is to help reduce costs of requiring custom hardware everywhere. The idea for outside entropy is to have an auditable (evidentiary) event that adds to the strength of the generated keys. Thanks again for (continued) commentary. /r$
Lots of random numbers
I'm putting together a system that might need to generate thousands of RSA keypairs per day, using OpenSSL on a "handful" of Linux machines. What do folks think of the following: take one machine and dedicate it as an entropy source. After 'n' seconds turn the network card into promiscuous mode, scoop up packets and hash them, dump them into the entropy pool. Do this for 'm' seconds, then go back to sleep for awhile. The sleep and wake times are random numbers. Other systems on the newtwork periodically make an SSL connection to the entropy box, read bytes, and dump it into their /dev/random device. Is this a cute hack, pointless, or a good idea? /r$
Re: Malign SSL server attacks
The only time the client signs something is when the server requests client auth. In TLS, the client signs MD5 and/or SHA1 hashes of the TLS handshake messages that have passed between the client and server at that point in the protocol. In SSLv3, it signs an MD5 and/or SHA1 HMAC-like (nested hash with pads) of the same handshake messages. Thanks for the detailed reply. So the question now becomes to what extent can the badguy control the hash, by sending fixed nonce data, silly no-op packets, etc... Hmm.
Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]
the OpenSSL project was not accepting code from US sources. Has this policy changed? Yes. The various members of the openssl-core team either agree that the current regulations remove their concern; or feel that even though there are issues it's not worth dealing with now US contributions can be submitted. They just have to be good enough to be accepted. :) Multiple interoperable implementations are usually a good thing. But when the talent pool is so small, and the (perceived? :) importance of the product is so great, I agree that the open source community is best served by rallying around a single implementation. Simpson's original note, asking for reviewers of the NSS code, can be seen as a proof point of this. There are plenty of closed-source SSL/TLS/etc implementations for interop testing. Flogging one of my own personal horses, the integration of CDSA and OpenSSL (being started by Intel) will be a very good thing. /r$
Re: Using signature-only certs to authenticate key exchanges
This effectively exempts things like signature-only smartcards and similar tokens. I would not want to risk things on strict technical interpretation. I would go solely by intent, which often seems obvious. "I don't know what cryptography is, but I know it when I see it." /r$
Re: Ridding IP of logic, reason, and law
It doesn't seem intuitively like the federal government ought to need a special financial incentive to disclose its research. But maybe I'm missing something. This is probably what's called a defensive patent. It's common practice to patent something so that nobody else can lock you out, or so that you have something to trade. Previously the semantic stuff was probably of limited interest or could be squashed or was "born secret." But it's a different world now, so the government has to be concerned about lock-out. Or perhaps it's a form of advertising, not uncommon among (applied :) research labs. Here's a slightly-related example (physical security) of what is probably a defensive patent: Method of maintaining security in a common output means and system for maintaining security Inventors: Nezu; Mitsumasa (Kawasaki, JP). Assignee:Fujitsu Limited (Kanagawa, JP). Appl. No.: 789,964 Filed: Jan. 31, 1997 Abstract A common output unit such as a print server maintains security when an output request unit, serving as a client, sends a job to be processed to the output unit. The output unit accepts and puts the job in queue. The output unit then creates a collation key that is sent back to the output request unit, which stores the collation key in a storage medium. The output unit searches the storage medium for the collation key and processes the queued job corresponding to the collation key. The print server includes a locked stacker and an ordinary stacker to minimize the output waiting time of the print job.
Re: A proposal for secure videoconferencing and videomessaging over the Internet
I do not understand what is meant by "provably secure". An unfortunate admission for a would-be cryptographer. For what it's worth, this is a mark against your credibility and might mean that fewer real crypto types will look at your work. (And no, I don't qualify as a crypto type.) /r$
Re: Electronic Signatures Yield Unpleasant Surprises
Their "speciality" in this case is making laws. If they are not capable of or willing to make an effort to comprehend that which they are legislating, then they are negligent in their duties. That seems a little disingenuous. My specialty is computers, yet I can't fix my modem driver. "Making laws" is an equally broad area. /r$
Re: outlook certs - solved
I now believe you've decoded the below incorrectly because the leading bit is set, making this a signed number Then it should have a leading zero byte. This appears to be a widespread bug within Microsoft products. /r$
Arcot
Any comments on Arcot, www.arcot.com?
Re: Automatic passphrase generation
proposed it but I think the example passphrase given was "the happy duck slowly kisses the yellow book". A la Chomsky: "Colorless green ideas sleep furiously." :) For a bit of whimsy, I posted a program in 1989 to comp.sources.games that generated sonnets. Might be of interest. You can find it at ftp.uu.net/usenet/comp.sources.games/volume6/sonnet/part0[12].Z No funk effete plebian France of stun Obscure avoirdupois no Job petite Hysterical success impromptu sun Recessive friends the stun environ heat Pronto the pile without beplastered food Mouthpiece ambitious midrange kernel sponge Computer jaundiced brushoff fire collude Machismo epitaph excessive plunge Romance robotic twilight zone and chirp Appeal with huge reversion memo fruit Abhorred cantata foreign frowzy twerp Intrinsic brilliance jimson footwork cute Incestuous exemplify of dull Immense ambitious products hideous null
Ultimate statement on the new regulations
It used to be that giving export control advice consisted of helping clients to comprehend unbelievably ridiculous statements in the present tense. Giving such advice now largely consists of helping clients to comprehend unbelievably ridiculous statements in the future conditional subjunctive. That's some kind of progress. -- Eben Moglen voice: 212-854-8382 Professor of Law Legal Historyfax: 212-854-7946moglen@ Columbia Law School, 435 West 116th Street, NYC 10027 columbia.edu General Counsel, Free Software Foundation http://emoglen.law.columbia.edu
Re: starting up servers that need access to secrets
Is there a good solution to the problem of starting up a network server that needs access to an encrypted database? (They also give you the option of having the server store the pass phrase on disk, although they warn you that this is completely insecure.) Is it really? That's not clear, to me. Do you trust the local machine, or not? Have you locked it down, or not. You are worried about someone "breaking in" and being able to read the passphrase. But you are not worried about someone "breaking in" and replacing software? Are you sure that's a realistic distinction to make? /r$
Re: starting up servers that need access to secrets
Your comments about locking down the server host are correct. I think the distinction becomes realistic in a worst case scenario. I disagree, but that's what makes a horse race. :) If the private key is ondisk, then the adversary can snarf it and try various passphrases at their leisure until their snarfed copy of the database decrypts. I believe better protection would be to keep private keys on external tamper-evident hardware. At least then you can know if someone has (attempted to) snarf the public key. (E.g., the way some PC systems say "Alert! The cover has been opened" at powerup time.) If you assume that even a locked down server may be broken in to, if the pass phrase to your encrypted database isn't on disk then you're better off. Agreed. But again I feel that "assume they can break in and read" is essentially the same as "assume they can break in and modify" for a reasonably-locked-down system. I.e., one in which there are basically no user accounts. If you're running tripwire then you should be able to detect altered software and reload it, and your secret is still safe as long as you used a strong encryption algorithm. Only if you know that tripwire itself -- or other parts of the system such as various shared libraries -- haven't been altered. My concerns and threat model might be more than you need. But you should know what you're explicitly ruling out and document it, if only to CYA (cover your a..). Another approach would be to double the number of systems that the adversary must compromise. HostA will run the service, but only when HostB sends it startup info. At boot A pings B. B "calls back" over over an SSL link and sends the passphrase using something like S/Key perhaps. Hope this helps. /r$
Re: Thawte SuperCerts
unless, of course, there's a built-in list of trusted CAs. That's exactly what it is. Patching the list is apparently pretty easy for Netscape Navigator -- instructions are included in the mod_ssl Apache patch -- but it's not currently known what needs to be done to make IE add a trusted CA. /r$
