Re: NPR : E-Mail Encryption Rare in Everyday Use
* Ed Gerck <[EMAIL PROTECTED]> [2006-02-25 13:11 -0800]: > Finally, the properties of MY public-key will directly affect the > confidentiality > properties of YOUR envelope. For example, if (on purpose or by force) my > public-key > enables a covert channel (eg, weak key, key escrow, shared private key), > YOUR > envelope is compromised from the start and you have no way of knowing it. > This is > quite different from an address, which single purpose is to route the > communication. > > That's I said the postal analogue of the public-key is the envelope. I don't agree with that analogue. An paper envelope does not prevent anybody from opening it (you can open it without any tools and with nearly no effort). The encryption should make it impossible for anybody to see the contents. The recipient might detect that the envelope was opened or replaced, but you must trust that he will detect this (you can't check it yourself). Nicolas -- http://www.rachinsky.de/nicolas - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Sat, Feb 25, 2006 at 07:33:38PM +0100, Ian G wrote: > areas. The fact is that SSH came in with a solution > and beat the other guy - Telnet secured over SSL. It > wasn't the crypto that did this, it was the key management, > plain and simple. Very few people I knew at the time moved to SSH because it was "more secure" and because "passwords weren't in plaintext". Most of the people moved because of the things you could do with SSH above and beyond telnet (port forwarding, X11 forwarding etc). In fact, the latter is the main reason I moved - it dated before i started taking an interest in security. Not to say that there weren't *any* who had the security reasons for moving, but then kerberized telnet existed too at that point in time. Cheers, MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/ (Please use this address to reply) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Alex Alten wrote: > At 02:59 PM 2/24/2006 +, Ben Laurie wrote: >> Ed Gerck wrote: We have keyservers for this (my chosen technology >> was PGP). If you liken their use to looking up an address in an >> address book, this isn't hard for users to grasp. > > I used PGP (Enterprise edition?) to encrypt my work emails to a > distributed set of members last year. We all had each other's public > keys (about a dozen or so). > > What I really hated about it was that when [EMAIL PROTECTED] sent me > an email often I couldn't decrypt it. Why? Because his firm's email > server decided to put in the FROM field "[EMAIL PROTECTED]". > Since it didn't match the email name in his X.509 certificate's DN it > wouldn't decrypt the S/MIME attachment. This also caused problems > with replying to his email. It took us hours, with several > experimental emails sent back and forth, to figure out the root of > the problem. > > No wonder PKI has died commercially and encrypted email is on the > endangered species list. I trust you don't think this is a problem with PKI, right? Since clearly the issue is with the s/w you were using. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
* Ben Laurie: > I don't use PGP - for email encryption I use enigmail, and getting > missing keys is as hard as pressing the "get missing keys" button. A step which has really profound privacy implications. I couldn't find a PGP key server operator that committed itself to keeping logs confidential and deleting them in a timely manner (but I didn't look very hard, either). Of course, since PGP hasn't progressed as faster as our computing resources, I'm nowadays in a position to run my own key server, but this is hardly a solution to that kind of problem. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
"Travis H." <[EMAIL PROTECTED]> writes: > On 2/24/06, Alex Pankratov <[EMAIL PROTECTED]> wrote: >> Tero Kivinen wrote: >> >> Secondly I cannot find where it >> >> authenticates the crypto suite used at all (it is not included in the >> >> signature of the AUTH message). >> >> Crypto suite is essentially just a protocol number. It requires >> no authentication. If the server side responds with HELO.OK, it >> means that it can comprehend specified protocol revision. Similar >> to what happens during the SSH handshake. > > In SSL, the lack of authentication of the cryptosuite could be used to > convince a v3 client that it is communicating with a v2 server, and > the v3 server that it is communicating with a v2 client, causing them > to communicate using SSL v2, which is called the "version rollback > attack". This isn't quite accurate. SSLv2 didn't do any kind of downgrade protection at all, for the version number, cipher suite, or anything else. SSLv3 used a MAC across the entire handshake. The tricky problem is to protect downgrade from SSLv3 to SSLv2, which obviously can't be done with the SSLv3 mechanisms. The trick that SSLv3 used was that when falling back to SSLv2, SSLv3-capable clients would pad their RSA PKCS#1 blocks in a special way that SSLv3 servers would detect. If they detected it, that meant there had been a downgrade. Unfortunately, not all clients correctly generate this padding and the check wasn't universally implemented correctly: http://www.openssl.org/news/secadv_20051011.txt -Ekr - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 5:59 PM -0500 2/24/06, John Kelsey wrote: What we ultimately need is encryption and authentication that are: a. Automatic and transparent. b. Add some value or are bundled with something that does. c. Don't try to tie into the whole horrible set of PKI standards in terms of uniquely identifying each human and bit in the universe, and getting them to sign legally binding messages whose full interpretation requires reading and understanding a 30-page CPS. We have the preamble and (a) already; the problem is that the preamble is insufficient. What we ultimately need is encryption and authentication *and validation of the authentication* that match at least (a). Currently, it is the validation of the authentication that makes most users uninterested. When you get a message from Bob that comes with a warning that says "I cannot tell whether or not Bob really sent this", but you are sure that Bob actually sent that (due to some out-of-band knowledge), you lose faith in the system. When Bob has the same problem with your messages, you give up. For signed personal mail, (b) and (c) may be mutually exclusive. Why sign your messages if you don't want to be held liable for their contents? How can you get the reward of integrity without the cost of responsibility? Given those two hurdles, my hopes for authenticated mail near zero. I have some hopes for authenticated syndicated messages through Atom or RSS, but not this year. The hardest part there will be (c), but there are many environments where signing one-way mail is quite appropriate, particularly in replacing paper messages. The demand for encryption of personal email is perpetually low. Without a legal requirement, it will probably always be a small niche market. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Ed Gerck wrote:
Ben Laurie wrote:
I totally don't buy this distinction - in order to write to you with
postal mail, I first have to ask you for your address.
We all agree that having to use name and address are NOT the problem,
for email or postal mail. Both can also deliver a letter just with
the address ("CURRENT RESIDENT" junk mail, for example).
The problem is that pesky public-key. A public-key such as
[2. application/pgp-keys]...
is N O T user-friendly.
True enough about public keys. Not so true about key fingerprints - a
20-char fingerprint is probably not much harder to manage than the usual
sorts of contact info (email, postal, & IM addresses, phone numbers, etc.).
Of course, a fingerprint won't let you encrypt an email without
supporting infrastructure for key lookups. However, it *will* let you
authenticate a session (e.g., IM, VoIP, SSH) if your parter presents his
public key in the handshake.
Perhaps this is further support for Iang's contention that we should
expect newer, interactive protocols (IM, Skype, etc.) to take the lead
in communication security. Email-style "message encryption" may simply
be a much harder problem.
Trevor
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
At 05:12 PM 2/26/2006 +, Ben Laurie wrote: Alex Alten wrote: > At 02:59 PM 2/24/2006 +, Ben Laurie wrote: >> Ed Gerck wrote: We have keyservers for this (my chosen technology >> was PGP). If you liken their use to looking up an address in an >> address book, this isn't hard for users to grasp. > > I used PGP (Enterprise edition?) to encrypt my work emails to a > distributed set of members last year. We all had each other's public > keys (about a dozen or so). > > What I really hated about it was that when [EMAIL PROTECTED] sent me > an email often I couldn't decrypt it. Why? Because his firm's email > server decided to put in the FROM field "[EMAIL PROTECTED]". > Since it didn't match the email name in his X.509 certificate's DN it > wouldn't decrypt the S/MIME attachment. This also caused problems > with replying to his email. It took us hours, with several > experimental emails sent back and forth, to figure out the root of > the problem. > > No wonder PKI has died commercially and encrypted email is on the > endangered species list. I trust you don't think this is a problem with PKI, right? Since clearly the issue is with the s/w you were using. I place the blame squarely on X.509 PKI. The identity aspect of it is all screwed up. No software implementation can overcome such a fundamental architectural flaw. - Alex -- - Alex Alten - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Alex Alten <[EMAIL PROTECTED]> writes: >What I really hated about it was that when [EMAIL PROTECTED] sent me an email >often I couldn't decrypt it. Why? Because his firm's email server decided >to put in the FROM field "[EMAIL PROTECTED]". Since it didn't match >the email name in his X.509 certificate's DN it wouldn't decrypt the S/MIME >attachment. This also caused problems with replying to his email. It took us >hours, with several experimental emails sent back and forth, to figure out >the root of the problem. Something's getting lost in this description. What does the value in the "From" field have to do with you decrypting a message? OTOH the mention of an "attachment" indicates a detached S/MIME signature, which doesn't have anything to do with encryption. If it is a signature, then the software should verify it with the included cert and display that as the signer. Please correct and resubmit. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Florian Weimer wrote: > * Ben Laurie: > >> I don't use PGP - for email encryption I use enigmail, and getting >> missing keys is as hard as pressing the "get missing keys" button. > > A step which has really profound privacy implications. > > I couldn't find a PGP key server operator that committed itself to > keeping logs confidential and deleting them in a timely manner (but I > didn't look very hard, either). Of course, since PGP hasn't > progressed as faster as our computing resources, I'm nowadays in a > position to run my own key server, but this is hardly a solution to > that kind of problem. OK, I buy the problem, but until we do something about the totally non-anonymising properties of the 'net, revealing that I want the public key for some person seems to be quite minor - compared, for example, to revealing that I sent him email each time I do. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
Alex Alten wrote: > At 05:12 PM 2/26/2006 +, Ben Laurie wrote: >> Alex Alten wrote: >>> At 02:59 PM 2/24/2006 +, Ben Laurie wrote: Ed Gerck wrote: We have keyservers for this (my chosen technology was PGP). If you liken their use to looking up an address in an address book, this isn't hard for users to grasp. >>> >>> I used PGP (Enterprise edition?) to encrypt my work emails to a >>> distributed set of members last year. We all had each other's >>> public keys (about a dozen or so). >>> >>> What I really hated about it was that when [EMAIL PROTECTED] sent >>> me an email often I couldn't decrypt it. Why? Because his >>> firm's email server decided to put in the FROM field >>> "[EMAIL PROTECTED]". Since it didn't match the email name >>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME >>> attachment. This also caused problems with replying to his email. >>> It took us hours, with several experimental emails sent back and >>> forth, to figure out the root of the problem. >>> >>> No wonder PKI has died commercially and encrypted email is on the >>> endangered species list. >> >> I trust you don't think this is a problem with PKI, right? Since >> clearly the issue is with the s/w you were using. > > I place the blame squarely on X.509 PKI. The identity aspect of it > is all screwed up. No software implementation can overcome such a > fundamental architectural flaw. OK - I'll bite - why does the sender's identity have any impact on the recipient's ability to decrypt? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
On Sat, Feb 25, 2006 at 07:33:38PM +0100, Ian G wrote: > Hence, IM/chat, Skype, TLS experiments at Jabber, as > well as the OpenPGP attempts. > > There are important lessons to be learnt in the rise of > IM over email. Likewise the rise of the telephone over paper mail, but the phone does not obviate the need for paper mail. > Email is held back by its standardisation, chat seems to overcome spam quite nicely. Where's Gaddi Evron when you need him? This is just not true, the spam volume is rising for both blogs and IM. > Email is hard to get encrypted, but it didn't stop Skype from doing > encryped IMs "easily." Likewise I have secured email communications with my wife via a single key exchange, so what? Skype has not "easily" created an interoperable federated system that secures all IM communications end-to-end, and many of the issues in doing that are non-technical. > The competition between the IM systems is what is driving > the security forward. As there is no competition in the > email world, at least at the level of the basic protocol > and standard, there is no way for the security to move > forward. > IM is "islands of automation", luckily email works globally. > Phishing is possible over chat, > but has also been relatively easy to address - because > the system owners have incentives and can adjust. This is naive, IM will become federated and decentralized and abuse issues will be the same as for email. You can't fence the bad guys out of the network. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: hamachi p2p vpn nat-friendly protocol details
Tero Kivinen wrote: > Alex Pankratov writes: > There might be (I am not sure whether AUTH packet is encrypted and MACed) a MAC over it, but the MAC key is not yet authenticated as it is generated from the anonymous Diffie-Hellman. That might give it some protection, but I am not sure if that is enough. >> >> >>A protection against what kind of attack ? >> [snip] > > So the identity is authenticated because the server uses the identity > given by the client to search the public key from his database and > then uses that public key to check the signature? Yes. > I think that should be enough, but I wasn't sure how the server > works with the public keys, i.e. what kind of registration is done, > and how it makes sure there is no duplicate identities created for > different public keys etc. Actually it is not clear what purpose the > identity itself has. If the only purpose is to identify the public key > already stored in the server, then hash of the public key would be > better, but if that ID is assigned by the server on the first > registration, then it is probably ok. It's assigned on the first contact. The protocol is also tied to use SHA1. >> >>If you are referring to HMAC-SHA1 for authentication hashes, it >>is a part of a crypto suite (protocol revision) spec. > > > Yes, it is part of the crypto suite, and that is not authenticated. > I.e. if / when the SHA1 is completely broken, in a way that also > HMAC-SHA1 is broken, then only way to change it is to put out new code > that supports new crypto suite (with some other hash/mac) and as the > crypto suite is not authenticated, then attacker can cause downgrading > attacks forcing client and server to use the broken crypto suite. Should switching to new crypto suite be required, new revision will authenticate suite ID, and this should prevent downgrading attacks. This will work because the suite is not negotiated, but rather pre-selected by the client. All in all I agree that both Identity and Suite should be included into the hash. We'll make the change to a protocol. > Looking at the latest development of the breaking of the hash > algorithms, it would be better to make sure that the algorithm > designed now would be crypto agile, i.e. make sure they do allow > different crypto algorithms, and allows easy adding of new algorithms. Well, if one want to avoid *binary* upgrade in the event of a suite being rendered useless, the binary needs to support all known cipher/digest/mac algorithms and the protocol needs to allow for defining suites dynamically. I am not aware of any protocol that has this property. Which means that should HMAC-SHA1 gets broken, all existing binaries would still require an upgrade regardless of whether how hard it is to add/replace the algorithms. In our case all crypto resides in a single module behind generic interface. Swapping it for an implementation that uses different algorithms is a matter of minutes. >>This is the second revision of Hamachi system. First revision >>was using SSL for cli-srv and IKE/ESP for p2p security. It was >>a prototype and it soon become obvious that both SSL and IKE >>were overkills for our purposes. We did not need certificate >>authentication of SSL, we did not want to run our own auth >>protocol over SSL/AnonDH, which would've increased the number >>of packets per login sequence. We didn't need the flexibility >>(ie complexity) of IKE either. >> >>After stripping down IKE (ie removing SA negotiation, reworking >>ID payloads and not doing quick mode), we essentially ended up >>with a protocol that was also fit for securing cli-srv session. >>It was further tweaked and replaced SSL. > > > Now there is the IKEv2 which is much bigger improvement over IKEv1, > especiallty if profiling it suitably (i.e. use raw RSA keys instead of > certificates etc). I looked at IKEv2 and JFK when we just started. It was a couple of years ago, IKEv2 was still pretty much in a discussion phase, so it was as good of an option as a custom protocol. It's RFC'd now, I will give it another read. As a side note I want to add that there're no illusions that given two versions of the system - one based on a custom protocols and one based on a standard ones - the second one is a better choice for many reasons. We had our reasons to go with a custom protocol for the first version and it seems to have worked out to be reasonably good. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
DHS: Sony rootkit may lead to regulation
DHS: Sony rootkit may lead to regulation U.S. officials aim to avoid future security threats caused by copy protection software News Story by Robert McMillan FEBRUARY 16, 2006 (IDG NEWS SERVICE) - A U.S. Department of Homeland Security official warned today that if software distributors continue to sell products with dangerous rootkit software, as Sony BMG Music Entertainment recently did, legislation or regulation could follow. "We need to think about how that situation could have been avoided in the first place," said Jonathan Frenkel, director of law enforcement policy for the DHS's Border and Transportation Security Directorate, speaking at the RSA Conference 2006 in San Jose. "Legislation or regulation may not be appropriate in all cases, but it may be warranted in some circumstances." Last year, Sony began distributing XCP (Extended Copy Protection) software in some of its products. The digital rights management software, which used rootkit cloaking techniques normally employed by hackers, was later found to be a security risk, and Sony was forced to recall millions of its CDs. The incident quickly turned into a public relations disaster for Sony. It also attracted the attention of DHS officials, who met with Sony a few weeks after news of the rootkit was first published, Frenkel said. "The message was certainly delivered in forceful terms that this was certainly not a useful thing," he said. While Sony's software was distributed without malicious intent, the DHS is worried that a similar situation could occur again, this time with more-serious consequences. "It's a potential vulnerability that's of strong concern to the department," Frenkel said. Though the DHS has no ability to implement the kind of regulation that Frenkel mentioned, the organization is attempting to increase industry awareness of the rootkit problem, he said. "All we can do is, in essence, talk to them and embarrass them a little bit," Frenkel said. In fact, this is not the first time the department has expressed concerns over the security of copy protection software. In November, the DHS's assistant secretary for policy, Stewart Baker, warned copyright holders to be careful of how they protect their music and DVDs. "In the pursuit of protection of intellectual property, it's important not to defeat or undermine the security measures that people need to adopt in these days," Baker said, according to a video posted to The Washington Post Web site. Despite the Sony experience, the entertainment industry's use of rootkits appears to be an ongoing problem. Earlier this week, security vendor F-Secure Corp. reported that it had discovered rootkit technology in the copy protection system of the German DVD release of the American movie Mr. and Mrs. Smith. The DVD is distributed in Germany by Kinowelt GmbH, according to the Internet Movie Database. Baker stopped short of mentioning Sony by name, but Frenkel did not. "The recent Sony experience shows us that we need to be thinking about how to ensure that consumers aren't surprised by what their software is programmed to do," he said. Sony BMG officials could not immediately be reached for comment. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
bear wrote: > > On Fri, 24 Feb 2006, Peter Saint-Andre wrote: > > >> Personally I doubt that anything other than a small percentage of email >> will ever be signed, let alone encrypted (heck, most people on this list >> don't even sign their mail). >> > > I don't think I've said anything here that I will later want to be > able to prove incontrovertibly was said by me. > > In general, signing your mail has a downside in this age of litigous > potential mail recipients, and except when your mail regards the > disposition of assets, no upside. > > In the long run, I think the population of people who want to sign > their mail is about the same as the population of people who want to > post on usenet with their real name and put their street address > and phone number at the bottom of every post. > > Why give the anonymous cowards who are collecting information with > robotic trawlers, whether for spam lists or any other reason, proof > of exactly who you are? The short answer to your unstated question is: anonymity is not high in my scale of values. The long answer will require some reflection on my part, which I won't post here but at my blog when I have the time. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: NPR : E-Mail Encryption Rare in Everyday Use
* Greg Black <[EMAIL PROTECTED]> wrote: > On 2006-02-24, Peter Saint-Andre wrote: > > Personally I doubt that anything other than a small percentage of > > email will ever be signed, let alone encrypted (heck, most people > > on this list don't even sign their mail). My personal experience differs. The people that have set up some kind of encryption to protect their privacy will use it at best and advertise such a possibility at the very least. Be it via kludges, email headers, footers, inline signatures, word of mouth (websites). The important fact is they do something. I did a little research on my email of the past month, both public mailinglists and private mail. The vast majority of private email was signed (and encrypted with both sender and recipient being part of the WoT), with public mailings showing a slightly increasing number of signed mailings. I realize that's far from being representative, but that's really the way it should be. > That's at least partly because too many mailing lists either reject > signed messages out of hand or, worse, have subscribers who use > providers that reject signed messages and then spam you with their > idiotic bounce messages. That's too true. Emails with signatures as attachements are often blocked (or with attachements removed altogether) because of the omnipresent virus-hype; I strongly believe that coping with possible virus threats is definitely not the job of a mailinglist software. But there's still the possibility of inline signatures. As to the ISP issue, it would make perfect sense to me to switch ISPs because of such bounce messages. However, I personally know of some that are better not mentioned by name, and sadly don't regret their practice. Net-neutrality has to be existent! Back to topic; e.e. both mutt, and its recent offspring mutt-ng, easily allow to adapt, as do other mail user agents out there. I strongly recommend to use such features if present. In the past I've seen forged signatures added to SPAM mails, so it's about time to sharpen the public's view on the matter. On a sidenote: From what I've heard, most banks don't bother much with encryption and solely focus on message integrity. Well, even if one shares the rather naive viewpoint of having nothing to hide (but still doesn't run naked; I wonder why...) it just can't hurt of having integrity added to ones own messages. I'm going to repeat soon: It doesn't have to be the full package right from the start. And with phishing attacks becoming more and more sophisticated it's only a matter of time until the public has to deal with the whole issue of integrity. > Keeping track of which lists allow signed email and which don't is > impractical if you subscribe to hundreds of lists, so the simple > thing is to tick the "don't sign" box on list messages. Sad but true. However, IMHO, that's also equal to "I give up " and clearly the wrong path one could possibly choose. Nonetheless, I guess it's safe to assume the ordinary user to have only a handful of mailinglists subscribed; granted, some people receive tens of mailinglists, but hundreds? Let's don't forget the time involved. I subscribed to 30 mailinglists, and to my licking there is not a single one lacking the more or less occasional signed mailings. One could argue with the list admins to allow signatures; that's usually an up-hill battle that still can be won by inline signatures. Of course, it's a hassle in terms of getting a working setup but it is far worse to leave the battlefield to the enemy. By doing so one gives the masses a wrong impression of the actual ease, once locally implemented, of being able to add integrity to one's messages. And that's only one step short of the actual much needed privacy, imho. Veryfing the integrity of a message lies at the receiving end, after all. That's where one has to start. It doesn't have to be the whole thing about encryption, message signing, WoT, etc. right from the start, curiosity will do the rest. In essence: A barbeque about such a topic will suffice. In my experience I can proudly point to some bowling/poker events that did the trick for some people. "It's not wrong, it's a start..." > In this case, since Peter's message was signed, I know this list > allows signatures. So I'll sign this message. Add me to the list (and forgive the pun please). Even if this list would not, with the sig added as attachement, I would do so via inline signature. So, why not always sign messages to a list that permits signatures? > But the signature will be of limited utility, as not one of the > several email addresses on my signature is a match for the email > address I am sending this from. Again, lists being what they are, > I use a different address for most lists and my PGP key would > become absurd if I added several hundred addresses to it. That's why I use a sole key for mailinglists and related encrypted mailings, additionally to my private and work keys. Works like a
What's the easiest way to crack an RSA key?
Answer: Use google. http://johnny.ihackstuff.com/index.php?module=prodreviews&func=showcontent&id=246 yields just under *four thousand* OpenSSL private key files. Admittedly some of these are test keys, but it looks like many of them aren't. (I doubt this is restricted to OpenSSL. If there was a way to search for registry keys via Google, I'm sure we'd find a vast mass of IIS and whatnot keys as well). Peter (thanks to anon for the info). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NPR : E-Mail Encryption Rare in Everyday Use
I have to chime in on a number of points. I'll try to keep commercial plugs to a minimum. * An awful lot of this discussion is some combination of outdated and true but irrelevant. For example, it is true that usability of all computers is not what it could be. But a lot of what has cruised by here is similar to someone saying, "Yes, usability is atrocious -- here, look at this screenshot of Windows 3.1." Someone else pipes up, "You think that's bad, let me show you this example from the Xerox Alto. What*ever* were they thinking?" And then someone else says, "Yeah, and if you think that's bad, look at what 'ls' did in Unix V6!" Then when someone else says, "Y'know, I'm using the latest version of Firefox, and it's actually pretty good" the next message says, "But what about the Y2K issues, and what happens when in 2038?" I swear, guys, this thread is the crypto version of the Monty Python "Luxury" sketch. * Whitten and Tygar is a great paper, but it was written ages ago on software that was released in 1997. Things aren't perfect now, but let's talk about what's out there now. Even at the time, one of Whitten's main points is how hard it is to apply usability to security, because of how odd it is. As a very quick example, in most forms of user design, you let exploration take a prominent place. But it doesn't work in security because you can't click undo when you do something you didn't intend. * There are new generations of crypto software out there. I produce the PGP products, and PGP Desktop and PGP Universal are automatic systems that look up certs use them, automatically encrypt, and even does both OpenPGP and S/MIME. They're not perfect, and lead to other amusing issues. For example, an hour ago, I was coordinating with someone that I'm meeting at a conference. I got a reply saying, "I'm at the airport and can't decrypt your message from my phone." I hadn't realized that I *had* encrypted my message, because my system and my colleague's system had been doing things for us. I habitually send most of my email securely, but I don't think about it. My robots take care of it for me. I tune policies, I don't encrypt messages. If you don't want to use my products, as Ben Laurie pointed out, there's a very nice plugin for Thunderbird called Enigmail that makes doing crypto painless. * There are also new generations of keyservers out there that work on the issues of the old servers to trim defunct keys, and manage other issues. I have out there the PGP Global Directory. Think of it as a mash-up of a keyserver along with Robot CA concepts and user management goodness adapted from modern mailing list servers like Mailman. * A number of us are also re-thinking other concepts such as using short-lived certificates based on the "freshness" model to constrain lifecycle management issues. * There are many challenges remaining. Heck, the fact that people here apparently have not updated their knowledge any time this century is part of the problem. But let me tell you that email encryption is growing, and growing strongly. However, most of the successes are not happening where you see them. They're happening in business, where communities of partners decide they need to do secure email, and then they do. This is another place where things have changed radically. A decade ago, we thought that security would be a grass-roots phenomenon where end-users and consumers would push security into those stodgy businesses. What's happening now is the exact opposite -- savvy businesses are putting together sophisticated security systems, and that's slowly starting to get end-users to wake up. I'd be happy to discuss at length where things are getting better, where they aren't, and where some issues have been shuffled around. But we do need to talk about what's going on now, not ten years ago. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
