Re: Yahoo releases internet standard draft for using DNS as public key server
Russell Nelson [EMAIL PROTECTED] writes:
Peter Gutmann writes:
STARTTLS
If Alice and Cathy both implement STARTTLS, and Beatty does not, and Beatty
handles email which is ultimately sent to Cathy, then STARTTLS accomplishes
nothing. If Uma and Wendy implement DomainKeys, and Violet does not, and
Violet handles email which is ultimately sent to Wendy, then Wendy can check
Uma's signature.
Since none of Uma, Wendy, or Violet implement DomainKeys or even know what
they are, DomainKeys accomplishes nothing. OTOH if their { ISP, company,
whatever } has STARTTLS enabled, they're getting their email encrypted without
even knowing about it and are having better-than-average security applied to
their POP/IMAP mail account, again without even knowing about it (I suspect
the latter is far more of a selling point to users than encryption. No-one
would want to read their mail anyway so they're not worried about that, but if
it stops those nasty hackers from breaking into their account, it's a good
thing).
If, instead, Perry had a list of PGP keys and email addresses, he wouldn't
*need* to compare the email address on the incoming email.
He'd instead need to spend even more time mucking around with keyrings and
updating keys and writing scripts to handle all the checking and wondering why
it all has to be so complicated, and maybe he should just ask people to fax in
submissions.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Ed Gerck wrote: No -- DomainKeys has nothingf to do with 'email cryptography'. They are S/MIME and PGP/MIME. I wouldn't say PGP/MIME (as opposed to pgp inline) was a widely enough used standard to be considered one of two options - pgp (both methods) certainly, but not pgp/mime exclusively. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Peter Gutmann wrote: The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages. What you're saying is that based on only *two* bits of information (e.g., SSH=1 and SSL=0) for a given mail sender, the message could be authenticated well-enough to be useful in the operational context. I agree with this and that's why I think that conventional digital signatures with 1024-bit keys are an overkill for common email. If the ugly blob of base64 rubbish is small enough, it should be tolearable. The problem with asymmetric keys, though, is that faking short signatures is too trivial for current cryptosystems. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
I see that you are not interested in discussing the relative merits of
STARTTLS vs. DomainKeys, but instead are just trying to push
STARTTLS. I hope that Perry will see through your sales job, and will
return your email to you, just as he will return this one to me.
-russ
[Moderator's note: No such luck for you I'm afraid. However, I'd
prefer if both of you tried to stay away from being personal. --Perry]
Peter Gutmann writes:
Russell Nelson [EMAIL PROTECTED] writes:
Peter Gutmann writes:
STARTTLS
If Alice and Cathy both implement STARTTLS, and Beatty does not, and Beatty
handles email which is ultimately sent to Cathy, then STARTTLS accomplishes
nothing. If Uma and Wendy implement DomainKeys, and Violet does not, and
Violet handles email which is ultimately sent to Wendy, then Wendy can check
Uma's signature.
Since none of Uma, Wendy, or Violet implement DomainKeys or even know what
they are, DomainKeys accomplishes nothing. OTOH if their { ISP, company,
whatever } has STARTTLS enabled, they're getting their email encrypted without
even knowing about it and are having better-than-average security applied to
their POP/IMAP mail account, again without even knowing about it (I suspect
the latter is far more of a selling point to users than encryption. No-one
would want to read their mail anyway so they're not worried about that, but if
it stops those nasty hackers from breaking into their account, it's a good
thing).
If, instead, Perry had a list of PGP keys and email addresses, he wouldn't
*need* to compare the email address on the incoming email.
He'd instead need to spend even more time mucking around with keyrings and
updating keys and writing scripts to handle all the checking and wondering why
it all has to be so complicated, and maybe he should just ask people to fax in
submissions.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A National ID
R. A. Hettinga wrote: If we're going to move to a national identification card, we can't afford to do it badly. Now is the time to figure out how to create a card that helps identify people but doesn't rob them of a huge swath of their civil liberties in the process. Just watch how the british do it - then don't do it that way. I am still trying to figure out how over a decade of terrorist bombings in mainland UK didn't justify introducing a national ID card - but the americans wanting biometric passports for visitors does. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Software Helps Rights Groups Protect Sensitive Information
R. A. Hettinga wrote: To prevent loss or theft, the data is backed up automatically and redundantly on dedicated Martus servers in Manila, Toronto, Seattle and Budapest. Nobody can read the files without access to the original user's cryptography key and password -- with the exception of sophisticated code-cracking organizations such as the U.S. National Security Agency or China's Public Security Bureau. I might be missing something here but - exactly how does a system insecure enough that interested governments can crack it help protect people who are releasing information concealed by those governments? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Software Helps Rights Groups Protect Sensitive Information
This reminds me of a question I've been meaning to ask for a while. Has there been any research done on encryption systems which encrypt two (or n) plaintexts with n keys, producing a joint ciphertext with the property that decrypting it with key k[n] only produces the nth plaintext? In the particular scenario that the article describes, activists need to protect their information from people that probably have little respect for the Geneva convention and would possibly find any evidence of encrypted information as proof enough that there is illegal activity going on. This, in turn, might lead to the police beating the key out of them. Now, if a solution such as Apple's FileVault or PGP's PGPDrive offered an interleaved drive system where one file stored multiple encrypted disks, and which one is accessed depended on which key you provided, perhaps things can be changed a bit. Password A unlocks a drive with mild dissidence information to appear credible. Password B unlocks a drive with the truly secret data. If captured, after some hours of a (probably highly unpleasant) interrogation, the dissident gives password A, interrogators try it, it works, they find nothing of tremendous use and dissident walks. If people have written on this before, I'd appreciate a few references. As for Zimmerman's comment about keyloggers - I'd hope the software offered a point-and-click method of entering the password. This can still be defeated with a custom-tailored piece of spyware, but it can be made much more difficult for the attackers to do so (depending on how well it's coded, it might actually require TEMPEST or the breaking of kneecaps to extract the password). Cheers, Ivan. R. A. Hettinga wrote: SOFTWARE HELPS RIGHTS GROUPS PROTECT SENSITIVE INFORMATION [snip] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Library talk on cryptography begins technology series
http://www.zwire.com/site/news.cfm?newsid=11830032BRD=1091PAG=461dept_id=425695rfi=6 NEWS SEARCH The Princeton Packet Library talk on cryptography begins technology series By: Jennifer Potash , Staff Writer 06/01/2004 Expert promises a nontechnical approach. No decoder rings are needed for an upcoming talk about the science of computer cryptography at the Princeton Public Library, but curious minds will be welcome. The library kicks off the summer series of its popular Tuesday Technology Talks program at 7 p.m. today with a lecture by Brian Kernighan, a professor at Princeton University's Computer Science Department. Mr. Kernighan, who often gives talks for nontechnical audiences, will lead an examination of how modern cryptography works, where it is used, some of the places where it hasn't worked well and a bit of cryptopolitics. Janie Herman, a reference librarian and founder of the series, said cryptography has come a long way since the days when Julius Caesar encoded messages by shifting the alphabet over a few places and when the British decoded the German Enigma machine during World War II. Today, cryptography is at the heart of security for our computers at home and at work, she said. It lets us buy and sell securely over the Internet and it's relied on by both the good guys and bad guys to keep their secrets safe. Ms. Herman said she's thrilled to have a speaker of Dr. Kernighan's stature as a guest for the series - he played key roles in the development of the Unix and C computer languages, and authored numerous books about programming in various computer languages. But don't call him an expert on cryptography - he claims to cringe when he saw that word used in another article promoting his library talk. My interest in cryptography is more of a dilettante interest, he said with a laugh. His talk, stripped of the jargon and tech speak found in his classroom lectures, will be split between a historical perspective on the cryptography used by the Romans on clay tablets to the codes used by spies in World War II and ending with the modern uses. Basically, the difference between cryptography then and now is the size of the numbers used for the encoding - in the premedieval days cryptography might be more a matter of shifting letters around while today the numbers are big, but not infinitely so, Dr. Kernighan said. The mathematics used in the encoding process were developed back in the 18th century and largely remain unchanged today, he said. Cryptography works by arranging information in a series of coded numbers accessible only to users with the correct key, he said. In practical terms, a user typing in a credit card number to make a purchase at an online business would have the sensitive information encoded to keep it safe from any unauthorized users, he said. While the early days of Internet sales brought tales of thefts of customers' credit card numbers, today the enterprise is much safer, Dr. Kernighan said. The problems with credit card number theft are more of a bricks-and-mortar problem. It's like sending your credit card number in an armored truck to a cardboard box, he said. Cryptography has also turned up in popular culture such as the Matrix movies and the best selling novel The Da Vinci Code. The novel didn't appeal to Dr. Kernighan. I thought the writing was horrible, he said. Also, the study of smaller codes based on letters is really not what he researches. Dr. Kernighan, who received his doctorate from Princeton University in 1969, worked for Bell Labs in the computing science research center in Murray Hill until 2000. After a few stints as an adjunct professor at Princeton and Harvard universities, Dr. Kernighan decided to take up teaching full time. It's a great place to have a second childhood, said Dr. Kernighan, who resides in Princeton Borough with his wife. Princeton Public Library is at 65 Witherspoon St. in Princeton Borough. Special assistance is available for library customers with disabilities. Those with special needs should contact the library 48 hours before any program to arrange for accommodations. Call (609) 924-9529. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A National ID
On Mon, 31 May 2004, R. A. Hettinga wrote: in most European countries, people carry national ID's as a matter of course. And pressure is mounting in America for some kind of security card. Similarly, there is a push for ID cards in the UK at the moment. See http://www.stand.org.uk/ and http://www.no2id.net/ for more detail. No doubt the same arguments for and against apply on both sides of the Atlantic, and it would be good if activists were to share information. Note that the real danger is not the cards but the database for which they are a unique key. See just about every issue of RISKS for ways in which big national databases can go wrong. Pete -- Peter Clay | Campaign for _ _| .__ | Digital / / | | | Rights! \_ \_| | | http://www.ukcdr.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Colossus reconstruction at Bletchley Park is finished.
(I had the privilege, along with a few other folks on this list, of seeing the reconstructed Colossus a couple of years ago up close while it was in an earlier phase of the work. The fact that the job is now finished is quite cool.) Return of Colossus marks D-Day By Jo Twist BBC News Online technology staff Colossus Mk2, a wartime code-breaker hailed as one of the first electronic computers, has been rebuilt and reunited with Bletchley Park veterans. http://news.bbc.co.uk/1/hi/technology/3754887.stm -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Dave Howe wrote: Peter Gutmann wrote: It *is* happening, only it's now called STARTTLS (and if certain vendors (Micromumblemumble) didn't make it such a pain to set up certs for their MTAs but simply generated self-signed certs on install and turned it on by default, it'd be happening even more). TLS for SMTP is a nice, efficient way to encrypt the channel. However, it offers little or no assurance that your mail will *stay* encrypted all the way to the recipients. That's correct. But, the goal is not to secure email to the extent that there is no risk, that's impossible, and arguing that the existence of a weakness means you shouldn't do it just means that we should never use crypto at all. See those slides that Adi Shamir put up, I collected the 3 useful ones in a recent blog: http://www.financialcryptography.com/mt/archives/000147.html I'd print these three out and post them on the wall, if I had a printer! The goal is to make it more difficult, within a tight budget. Using TLS for SMTP is free. Why not do it? (Well, it's free if self-signed certs are used. If CA-signed certs are used, I agree, that exceeds the likely benefit.) Most of us (including me most of the time) are in the position of using their ISPs or Employer's smarthost to relay email to its final destination; in fact, most employers (and many ISPs) actually enforce this, redirecting or blocking port 25 traffic. If my employer or isp accept TLS traffic from me, but then turn around and send that completely unprotected to my final recipient, I have no way of preventing or even knowing that. Sendmail's documentation certainly used to warn this was the case - probably still does :) a) Once a bunch of people send mail via TLS/SMTP, the ISP is incentivised to look at onward forwarding it that way. b) It may be that your local threat is the biggest, if for example you are using 802.11b to send your mail. The threat of listening from the ISP onwards is relatively small compared to what goes on closer to the end nodes. c) every node that starts protecting traffic this way helps - because it boxes the attacker into narrower and narrower attacks. It may be that the emails are totally open over the backbone, but who cares if the attacker can't easily get there? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Software Helps Rights Groups Protect Sensitive Information
This reminds me of a question I've been meaning to ask for a while. Has there been any research done on encryption systems which encrypt two (or n) plaintexts with n keys, producing a joint ciphertext with the property that decrypting it with key k[n] only produces the nth plaintext? See the Steganographic File System: http://www.mcdonald.org.uk/StegFS/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Dave Howe wrote: Ian Grigg wrote: Dave Howe wrote: TLS for SMTP is a nice, efficient way to encrypt the channel. However, it offers little or no assurance that your mail will *stay* encrypted all the way to the recipients. That's correct. But, the goal is not to secure email to the extent that there is no risk, that's impossible, and arguing that the existence of a weakness means you shouldn't do it just means that we should never use crypto at all. No - it means you might want to consider a system that guarantees end-to-end encryption - not just first link, then maybe if it feels like it That doesn't mean TLS is worthless - on the contrary, it adds an additional layer of both user authentication and session encryption that are both beneficial - but that *relying* on it to protect your messages is overoptimistic at best, dangerous at worst. This I believe is a bad way to start looking at cryptography. There is no system that you can put in place that you can *rely* upon to protect your message. (Adi Shamir again: #1 there are no secure systems, ergo, it is not possible to rely on them, and to think about relying will take one down false paths.) In general terms, most ordinary users cannot rely on their platform to be secure. Even in specific terms, those of us running BSD systems on laptops that we have with us all the time still have to sleep and shower... There are people out there who have the technology to defeat my house alarm, install a custom key logger designed for my model of laptop, and get out before the hot water runs out. For that reason, I and just about everyone else do not *rely* on tech to keep my message safe. If I need to really rely on it, I do what Adolf Hitler did in November of 1944 - deliver all the orders for the great breakout by secure courier, because he suspected the enigma codes were being read. (He was right.) Otherwise, we adopt what military people call tactical security: strong enough to keep the message secure enough so that most of the time it does the job. The principle which needs to be hammered time and time again is that cryptography, like all other security systems, should be about risk and return - do what you can and put up with the things you can't. Applying the specifics to things like TLS and mail delivery - yes, it looks very ropey. Why for example people think that they need CA-signed certs for such a thing when (as you point out) the mail is probably totally unprotected for half the journey is just totally mysterious. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Software Helps Rights Groups Protect Sensitive Information
At 16:08 2004-05-31 -0400, Ivan Krstic [EMAIL PROTECTED] wrote: This reminds me of a question I've been meaning to ask for a while. Has there been any research done on encryption systems which encrypt two (or n) plaintexts with n keys, producing a joint ciphertext with the property that decrypting it with key k[n] only produces the nth plaintext? In the particular scenario that the article describes, activists need to protect their information from people that probably have little respect for the Geneva convention and would possibly find any evidence of encrypted information as proof enough that there is illegal activity going on. This, in turn, might lead to the police beating the key out of them. Now, if a solution such as Apple's FileVault or PGP's PGPDrive offered an interleaved drive system where one file stored multiple encrypted disks, and which one is accessed depended on which key you provided, perhaps things can be changed a bit. Password A unlocks a drive with mild dissidence information to appear credible. Password B unlocks a drive with the truly secret data. If captured, after some hours of a (probably highly unpleasant) interrogation, the dissident gives password A, interrogators try it, it works, they find nothing of tremendous use and dissident walks. BestCrypt (http://www.jetico.com/) claims to do this for N = 2: BestCrypt v.7 also allows the creation of hidden containers - containers not evident to an intruder. You can simply create another (hidden) container inside already existing (shell) container. Data stored inside shell and hidden containers can be completely different, passwords for the containers are also different, and it is not possible to determine whether the shell container has a hidden container inside it, or not. Version 7 help documentation contains detailed information on the creation and management of hidden containers. --Mark - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
On Mon, May 31, 2004 at 08:27:49PM -0700, bear wrote: The point of an automated web of trust is that the machine is doing the accounting for you. Does it? If there were meaningful reputation accounting You got fooled by the present tense. If there was such an architecture, I wouldn't have written that message. The distributed tamper-proof cryptographic p2p store should have been a dead giveaway. happening, we'd be getting feedback and value judgements from the system on the people we were corresponding with. Have you ever seen any? No, of course. See above. Has there been *ANY* instance of negative consequences accruing to someone who signed the key of an entity which later defected? Machine-moderated or not, the web of trust fails. The web of trust sure fails, dunno about machine-moderated. There's no such animal yet. Have you seen any web-of-trust implementation that even *considers* the trustworthiness of the key servers? Have you seen any web-of-trust implementation that works to cut out defectors, but couldn't be autospammed to cut out anyone you didn't like? If you don't have their key, you can't pretend to sign the spambots'. If you sign the spambots', you burn whatever little prestige you have happened to start out with, and drained the mana of whatever hapless warm body signed your keys. Sorry; but the fact is no web-of-trust implementation to date works, or even comes close to working. Web of trust is useless, if Johnny User is supposed to do the checking. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpPzt821GHi8.pgp Description: PGP signature
Re: Yahoo releases internet standard draft for using DNS as public key server
At 10:14 PM 5/30/2004, Peter Gutmann wrote: The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages. this may or may not be my KISS authentication thread. mid-90s, some number of financial institutions retrenched from x.509 identity certificates to simple relying-party-only certificates ... because of enormous privacy issues regarding blanketing the world with privacy information contained in identity certificates. however, they were still looking at taking a 60-80 bytes payment message, attaching a 128byte digital signature, and then attaching a 4k byte to 12k byte relying-party-only certificate ... and sending it back to the financial institution that issued the certificate. this is not counting any ASN.1 encoding that might have been done which then possiby includes a bunch more bytes. note that standard payment message message has been around some 30 years carefully crafted as simple 7bit ascii w/o any addition encoding requirements. the purpose of the certificate was to carry the account number ... which was also included in the signed payment message ... and the public key ... which was stored in the account record back at the financial institution that was receiving the transmission and had originally issued the relying-party-only certificate. so the financial institution receives this new payment object, retrieves the account number from the (signed) payment message and uses the public key in the account record to verify the signature ... w/o ever resorting to the certificate. So we have a payload bloat of one hundred times ... in order to carry a certificate that is redundant and superfluous and never used. so x9.59 was fairly carefully crafted to add a 42byte ECC signature to a standard 60-80byte payment message. any special encoding to carry 42byte ecc 8bit in 7bit transmission at worst doubled the signature payload size. http://www.garlic.com/~lynn/index.html#x959 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Ian Grigg wrote: Dave Howe wrote: No - it means you might want to consider a system that guarantees end-to-end encryption - not just first link, then maybe if it feels like it That doesn't mean TLS is worthless - on the contrary, it adds an additional layer of both user authentication and session encryption that are both beneficial - but that *relying* on it to protect your messages is overoptimistic at best, dangerous at worst. This I believe is a bad way to start looking at cryptography. There is no system that you can put in place that you can *rely* upon to protect your message. No, there are plenty that you can rely on to protect your message while still in transit. If you can ensure that the only possible points of vulnerability are at the two endpoints, then you and your correspondent take control of your security - it won't be perfect, as you point out - but you won't be reliant on the goodwill and efforts of some third party whose most economic option is to accidentally or deliberately neglect TLS between your local smart host and your correspondent's email spooler, or indeed, to supply minimal security to the email spools at smarthost or destination. (Adi Shamir again: #1 there are no secure systems, ergo, it is not possible to rely on them, and to think about relying will take one down false paths.) Secure systems exist - but are rarely worth the effort involved. Many PDAs can handle PGP or S/Mime traffic these days - certainly, you could offload your message (already encrypted) to flash media, insert into sending host, receive (from email spool) at the destination and transfer to flash media, then insert into decoding PDA. To compromise either PDA would require access - so if you keep it about your person (and within sight when you bathe), you should be safe against anything but a midnight intrusion with sleeping gas But regardless - the level of defence required is proportional to the likely threat. It is entirely possible that it would be worthwhile for some hacker to compromise a router between your ISP's mail server and your correspondent's spool, or that spool itself. It is less likely that it would be worth someone's while to break into your home with exquisite timing and tracelessly alter software on your trusted airgapped machine while you shower (and if that *is* your threat model, I envy the income you must get to justify being in such a position or bow to the value of your information to some repressive regime) Otherwise, we adopt what military people call tactical security: strong enough to keep the message secure enough so that most of the time it does the job. Indeed so. The principle which needs to be hammered time and time again is that cryptography, like all other security systems, should be about risk and return - do what you can and put up with the things you can't. Again, true. I suspect we differ in what we consider an acceptable risk - I don't consider any setup where the security of the channel is against the best interests of the people controlling that channel acceptable - especially where I have no way to discover if that channel was compromised. I have what I hope is an acceptably secure system at home - and I also hope my correspondents do likewise. If our messages are compromised (not that they contain anything worth stealing) then it is my fault or theirs - not an admin at the isp, or some minimum-wage employee on a helpdesk bribed to let someone take a peak at my mailspool. This extra security comes free, gratis, not a penny does it cost - beyond the effort of learning how to use it - and while I was used to hotkeying my way into the current window, my recent switch to Enigmail means I don't even have to do that. Why would I settle for less? Applying the specifics to things like TLS and mail delivery - yes, it looks very ropey. Why for example people think that they need CA-signed certs for such a thing when (as you point out) the mail is probably totally unprotected for half the journey is just totally mysterious. And indeed I had a conversation with someone who was interested in a secure mailing list only a few days ago. I suggested he not bother and just set up a HTTPS website with any one of a dozen BBoard systems and local certificate support - because that was free and all the complexity (and most of the vulnerabilites) are at the server side - while setting up a secure email burster would be almost impossible and would rely on not only training the end users, but ensuring they have the right software installed. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
