Philipp Gühring wrote:
Hi,
I would suggest to use http://www.cacert.at/random/ to test the
randomness of the DNS source ports. Due to the large variety of
random-number sources that have been tested there already, it's useful
as a classification service of unknown randomly looking numbers.
Yo
,
code/silicon inspection probably suffices.
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." -
Pierre-Evariste Dagand wrote:
I doubt you can get a large enough sample in any reasonable time.
Indeed.
I don't see the point of evaluating the quality of a random number
generator by statistical tests.
Which is entirely my point.
I fear I was not clear: I don't see what is wrong in evalu
Pierre-Evariste Dagand wrote:
But just how GREAT is that, really? Well, we don'
t know. Why? Because there isn't actually a way test for randomness. Your
DNS resolver could be using some easily predicted random number generator
like, say, a linear congruential one, as is common in the rand() li
I thought this list might be interested in a mini-rant about DNS source
port randomness on my blog: http://www.links.org/?p=352.
Ever since the recent DNS alert people have been testing their DNS
servers with various cute things that measure how many source ports you
use, and how "random" they
ticular, part 2 explains DNSSEC
http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/
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 g
Steven M. Bellovin wrote:
On Wed, 09 Jul 2008 11:22:58 +0530
Udhay Shankar N <[EMAIL PROTECTED]> wrote:
I think Dan Kaminsky is on this list. Any other tidbits you can add
prior to Black Hat?
Udhay
http://www.liquidmatrix.org/blog/2008/07/08/kaminsky-breaks-dns/
I'm curious about the detai
Paul Hoffman wrote:
First off, big props to Dan for getting this problem fixed in a
responsible manner. If there were widespread real attacks first, it
would take forever to get fixes out into the field.
However, we in the security circles don't need to spread the "Kaminsky
finds" meme. Take
Arshad Noor wrote:
Ben Laurie wrote:
Arshad Noor wrote:
I may be a little naive, but can a protocol itself enforce proper
key-management? I can certainly see it facilitating the required
discipline, but I can't see how a protocol alone can enforce it.
I find the question difficu
eaning to dissect to see what's inside
them. I wonder where I put it?
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
ensure their applications are using "verified" libraries
on the client devices, so their polices are not subverted.
Ha ha. Like that's going to work. Even if we assume that libraries are
verified (fat chance, IMO), how are you going to stop, for example,
cut'n'pa
Ed Gerck wrote:
Ben Laurie wrote:
But doesn't that prove the point? The trust that you consequently
place in the web server because of the certificate _cannot_ be copied
to another webserver. That other webserver has to go out and buy its
own copy, with its own domain name it it.
A co
says.
But doesn't that prove the point? The trust that you consequently place
in the web server because of the certificate _cannot_ be copied to
another webserver. That other webserver has to go out and buy its own
copy, with its own domain name it it.
Cheers,
Ben.
--
http://ww
Scott G. Kelly wrote:
Ben Laurie wrote:
Scott G. Kelly wrote:
Here's another approach to password authenticated key exchange with
similar security claims. The underlying mechanism is under
consideration for inclusion in by the 802.11s group in IEEE:
http://www.ietf.org/internet-drafts/
Scott G. Kelly wrote:
Here's another approach to password authenticated key exchange with
similar security claims. The underlying mechanism is under
consideration for inclusion in by the 802.11s group in IEEE:
http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-01.txt
Hmmm. I don't s
http://grouper.ieee.org/groups/1363/passwdPK/submissions/hao-ryan-2008.pdf
At last.
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." -
Steven M. Bellovin wrote:
On Sat, 24 May 2008 20:29:51 +0100
Ben Laurie <[EMAIL PROTECTED]> wrote:
Of course, we have now persuaded even the most stubborn OS that
randomness matters, and most of them make it available, so perhaps
this concern is moot.
Though I would be interested to kn
w persuaded even the most stubborn OS that
randomness matters, and most of them make it available, so perhaps this
concern is moot.
Though I would be interested to know how well they do it! I did have
some input into the design for FreeBSD's, so I know it isn't completely
awful, but h
Florian Weimer wrote:
* Ben Laurie:
I must confess that I said that because I did not have the energy to
figure out the other routes to adding entropy, such as adding an int
(e.g. a PID, which I'm told still makes it in there).
The PID dependency is there because of the need for fork
su
Paul Hoffman wrote:
At 10:25 AM +0100 5/15/08, Ben Laurie wrote:
Paul Hoffman wrote:
I'm confused about two statements here:
At 2:10 PM +0100 5/13/08, Ben Laurie wrote:
The result of this is that for the last two years (from Debian's
"Edgy" release until now), anyone d
Paul Hoffman wrote:
I'm confused about two statements here:
At 2:10 PM +0100 5/13/08, Ben Laurie wrote:
The result of this is that for the last two years (from Debian's
"Edgy" release until now), anyone doing pretty much any crypto on
Debian (and hence Ubuntu) has been us
Jonathan S. Shapiro wrote:
On Wed, 2008-05-14 at 10:34 +0100, Ben Laurie wrote:
Jonathan S. Shapiro wrote:
Ben: I'm idly curious. Was this exceptionally unusual case where use of
uninitialized memory was valid properly commented in the code?
Well. Kinda. It didn't really explain why
Jonathan S. Shapiro wrote:
Ben: I'm idly curious. Was this exceptionally unusual case where use of
uninitialized memory was valid properly commented in the code?
Well. Kinda. It didn't really explain why:
i=fread(buf,1,n,in);
if (i &
Peter Gutmann wrote:
Ben Laurie <[EMAIL PROTECTED]> writes:
I must confess that I said that because I did not have the energy to figure
out the other routes to adding entropy, such as adding an int (e.g. a PID,
which I'm told still makes it in there).
So just to clarify, does
Steven M. Bellovin wrote:
On Tue, 13 May 2008 23:27:52 +0100
Ben Laurie <[EMAIL PROTECTED]> wrote:
Ben: I haven't looked at the actual code in question -- are you
saying that the *only* way to add more entropy is via this pool of
uninitialized memory?
No. That would be fantastic
Steven M. Bellovin wrote:
On Tue, 13 May 2008 23:00:57 +0100
Ben Laurie <[EMAIL PROTECTED]> wrote:
Steven M. Bellovin wrote:
On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie <[EMAIL PROTECTED]> wrote:
Debian have a stunning example of how blindly fixing "problems"
pointed
Steven M. Bellovin wrote:
On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie <[EMAIL PROTECTED]> wrote:
Debian have a stunning example of how blindly fixing "problems"
pointed out by security tools can be disastrous.
I've blogged about it here: http://www.links.org/?p=327
[Moderator's note: A quick reminder: please use ASCII except if you
need Unicode to spell your name right. Microsoft's proprietary quote
marks are not a standard and don't look right on non-Microsoft
displays. I edited them out of this by hand. --Perry]
Debian have a stunning example of how blind
Perry E. Metzger wrote:
Ben Laurie <[EMAIL PROTECTED]> writes:
I think that's blatantly untrue. For example, if I look at an AND
gate, I can be absolutely sure about its security properties.
An AND gate isn't Turing Equivalent.
Nor are most algorithms.
Rice's t
e about its security properties.
Rice's theorem says you can't _always_ solve this problem. It says
nothing about figuring out special cases.
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
the IPSEC stack,
but that's a deficiency of the OS, not a fundamental problem.
It seems to me there's no real difference between the two cases.
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 f
Scott Guthery wrote:
Those interested in predicate encryption might also enjoy
Group Authentication Using The Naccache-Stern Public-Key Cryptosystem
http://arxiv.org/abs/cs/0307059
which takes a different approach and handles negation.
A group authentication protocol authenticates pre-defin
es in a row before you are locked out for a time-
out period)
You forgot:
* stronger passwords
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 cr
Dave Howe wrote:
James A. Donald wrote:
From time to time I hear that DNSSEC is working fine, and on
examining the matter I find it is "working fine" except that
DNSSEC is "working fine" as a technology. However, it is worth
remembering that it works based on digitally signing an entire
[EMAIL PROTECTED] wrote:
On Sat, Mar 22, 2008 at 03:52:49PM +, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do
ocessor, a keyboard and a
screen, and must be portable and secure.
One day we'll stop concluding this and actually do something about it.
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
[EMAIL PROTECTED] wrote:
On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names. Some narrow
implementations have assumed that there
[EMAIL PROTECTED] wrote:
Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names. Some narrow
implementations have assumed that there will only be a single
data element and this myth - that PTRs only point to a singl
zones with CERT-rr's would not be a bad
thing. In fact, thats what we are testing .
Who is "we" and what exactly are you testing?
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 g
be extended to cover
more. RFC 4255 gives you SSH host keys, too.
If you want to do something ad hoc, then there are always TXT records,
though I guarantee this will make the DNS people hate you forever.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.links.org/
"
Dirk-Willem van Gulik wrote:
So I'd argue that while x509, its CA's and its CRL's are a serious pain
to deal** with, and seem add little value if you assume avery diligent
and experienced operational team -- they do provide a useful
'procedural' framework and workflow-guide which is in itself v
[EMAIL PROTECTED] wrote:
So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs. Obviously this is bad.
You only think this is bad because you believe CAs add some value.
SSH keys aren't signed and don't expire. Is that bad?
--
http://www.apac
Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does the
realtime authentication part of the market ...
It's not rocket
On 10/01/2008, Florian Weimer <[EMAIL PROTECTED]> wrote:
> Has anybody read the original column/editorial/whatever in the Sunday
> Times and can tell whether Mr Clarkson has, in fact, claimed that he
> actually lost money?
Yes, a standing order for £500 per month to a charity, IIRC.
-
Alex Pankratov wrote:
>> I want to make this distinction because I'd like to talk
>> about secret keys, which have to be rather larger than 4
>> kbits to have 4kbits of entropy for modular arithmetic stuff.
>
> Are you referring to RSA-like secrets that involve prime
> numbers, which are therefo
Alex Pankratov wrote:
> Say, we have a random value of 4 kilobits that someone wants
> to keep secret by the means of protecting it with a password.
It would assist understanding, I feel, if we thought about 4 kilobits of
entropy, rather than a 4 kilobit value. I want to make this distinction
be
our choosing.
Easy to implement, hard to get wrong, somewhat understood security
properties.
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."
OpenSSL Security Advisory [12-Oct-2007]
OpenSSL Vulnerabilities
---
Vulnerability A
---
Andy Polyakov discovered a flaw in OpenSSL's DTLS implementation which
could lead to the compromise of clients and servers with DTLS enabled.
DTLS is a datagram variant of TLS
Peter Gutmann wrote:
> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>> On Mon, 18 Jun 2007 22:57:36 -0700 "Ali, Saqib" <[EMAIL PROTECTED]> wrote:
>>> US Government has select 9 security vendors that will product drive
>>> and file level encryption software.
>> Out of curiousity, are any open so
Peter Gutmann wrote:
> For people who don't read LKML (or get interesting bits forwarded to them),
> there's a wonderful quote by Linus Torvalds about the difference between OS
> scheduler design and security design:
>
> "Schedulers can be objectively tested. There's this thing called
> 'perfo
Ian G wrote:
> 1. blinded money demo programs: there is magic money, in C and in
> Java. Also I think Ben Laurie wrote another one demo'd at EFCE. These
> demos are generally around 1-4kloc.
Lucre. There was also a project, lucrative, to make it into a usable
platform. It fi
Damien Miller wrote:
> OTOH Racoon/ipsec-tools would benefit from the extra sanity checks
> that Ben Laurie added to OpenSSL for the 0.9.8a release[3], assuming
> it was compiled against that version or later.
I have to say that Nick Mathewson should get all the credit for this, I
was
tacker to cause key leakage. If they are
prepared to cooperate then they can leak the key anyway, and no amount
of testing of public keys will prevent this.
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
[EMAIL PROTECTED] writes:
> So, when you find a particularly obnoxious dilettante going on about
> his bone-headed unbreakable scheme, please forward it to me and I'll
> see about breaking it, and then publish the schemes and the results on
> a web site for publicly "educating" them. Honestly, th
I recently wrote a layman's introduction to selective disclosure which
I thought might interest members of this list:
http://www.links.org/files/selective-disclosure.pdf
Cheers,
Ben.
-
The Cryptography Mailing List
Unsubs
the need to trust
> a single root key.
Indeed, and I already wrote an I-D for it:
http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-01.html.
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 fa
Allen wrote:
> Hi gang,
>
> On recent consulting gig, I came across what I think is a potential
> vulnerability and wanted to see how crazy my thinking is.
>
> Without mentioning the exact place or piece of software because of NDAs,
> here is the basic scenario.
>
> The tool stores the hex versi
Adam Back wrote:
> Related to this announcement, credentica.com (Stefan Brands' company)
> has released "U-Prove", their toolkit & SDK for doing limited-show,
> selective disclosure and other aspects of the Brands credentials.
>
> http://www.credentica.com/uprove_sdk.html
>
> (Also on Stefa
Ian G wrote:
> Steven M. Bellovin wrote:
>> On Mon, 12 Feb 2007 17:03:32 -0500
>> Matt Blaze <[EMAIL PROTECTED]> wrote:
>>
>>> I'm all for email encryption and signatures, but I don't see
>>> how this would help against today's phishing attacks very much,
>>> at least not without a much better trus
lysis that triggered the
> concern over collisions?
Google is your friend:
http://grouper.ieee.org/groups/1619/email/msg00558.html
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 h
Peter Gutmann wrote:
> Ben Laurie <[EMAIL PROTECTED]> writes:
>
>> While we're at it, an amusing fact I learnt about FIPS-140 while I was
>> implementing it for OpenSSL is that some of the Monte Carlo tests have output
>> that's independent of the input.
&g
ve. I guess it might be
possible to re-insert it outside the boundary, I'm not sure that
occurred to us at the time. I seem to remember there was some obstacle
to this, though, but I can't remember what it was.
While we're at it, an amusing fact I learnt about FIPS-140 while I was
imple
:-)
This kind of service has been discussed here before, of course. The
usual verdict: so much better for attackers, especially if they work for
Yuzoz.
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 c
Travis H. wrote:
> On 9/9/06, Adam Back <[EMAIL PROTECTED]> wrote:
>> IGE if this description summarized by Travis is correct, appears to be
>> a re-invention of Anton Stiglic and my proposed FREE-MAC mode.
>> However the FREE-MAC mode (below described as IGE) was broken back in
>> Mar 2000 or mayb
James A. Donald wrote:
> --
> James A. Donald wrote:
>>> Code is going wrong because ASN.1 can contain
>>> complicated malicious information to cause code to go
>>> wrong. If we do not have that information, or simply
>>> ignore it, no problem.
>
why you'd single out
ASN.1 as the cause of this problem: once the designers of the protocol
decided you needed parameters, the door was opened to the attack.
Implementations can incorrectly ignore the extraneous parameters no
matter how you encode them.
Not that I'm a fan of ASN.1, but i
Kuehn, Ulrich wrote:
>
>
>> From: Ben Laurie [mailto:[EMAIL PROTECTED]
>>> Do I understand correctly? You do want that nobody is able to
>>> authenticate a message, however, it shall not be intelligible if
>>> manipulated with?
>> Correct. Mi
Kuehn, Ulrich wrote:
>
>
>> -Original Message----- From: Ben Laurie
>> [mailto:[EMAIL PROTECTED] Sent: Samstag, 9. September 2006 22:39
>> To: Adam Back Cc: Travis H.; Cryptography; Anton Stiglic Subject:
>> Re: IGE mode is broken (Re: IGE mode in OpenSSL)
&g
Thierry Moreau wrote:
>
>
> Jostein Tveit wrote:
>
>> Ben Laurie <[EMAIL PROTECTED]> writes:
>>
>>
>>> ...thought this might interest people here.
>>
>>
>> Anyone got a test key with a real and a forged signature to test
>> o
James A. Donald wrote:
> --
> James A. Donald wrote:
>> > What is the penetration of Secure DNS?
>
> Ben Laurie wrote:
>> Anyone who is running any vaguely recent version of
>> BIND is DNSSEC enabled, whether they are using it now
>> or not.
>
>
James A. Donald wrote:
> --
> Ben Laurie wrote:
>> Subject:
>> [dnsop] BIND and OpenSSL's RSA signature forging issue
>> From:
>> Ben Laurie <[EMAIL PROTECTED]>
>> Date:
>> Fri, 08 Sep 2006 11:40:44 +0100
>> To:
>>
Adam Back wrote:
> On Sat, Sep 09, 2006 at 09:39:04PM +0100, Ben Laurie wrote:
>>> There is some more detail here:
>>>
>>> http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st
>> Interesting. In fact, Gligor et a
Adam Back wrote:
> Hi Ben, Travis
>
> IGE if this description summarized by Travis is correct, appears to be
> a re-invention of Anton Stiglic and my proposed FREE-MAC mode.
> However the FREE-MAC mode (below described as IGE) was broken back in
> Mar 2000 or maybe earlier by G
live, allegedly.
Side benefit:
You all get to test emergency key roll! Start your motors, gentlemen!
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&#
modes that do integrity and encryption at the same time;
> does this offer and advantage over them, and if so how?
Its cheap. However, my main interest is in biIGE, since any change to
the ciphertext changes all of the plaintext, which is useful for some
protocols, in particular, Minx (http://www
I've added IGE mode to OpenSSL - it should be in the next release (0.9.8c).
More info here: http://www.links.org/?p=131. Including test vectors!
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
I'm implementing AES in IGE and biIGE mode. AFAIK, there are no other
implementations or test vectors, but perhaps one of you knows different?
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 ca
smart cards it seems to be mostly smoke and
> mirrors.
>
> (As an extension of this, the lack of access to a TPM's RNG isn't really any
> great loss. If it's there, you can mix it opportunistically into your own
> RNG, but I wouldn't rely on it).
+1.
Cheers,
Ben.
David Wagner <[EMAIL PROTECTED]> writes:
> The specification is secret and confidential. It uses the SMS4
> block cipher, which is secret and patented. [*]
"Secret" and "patented" are mutually exclusive.
--
Ben Pfaff
email: [EMAIL PRO
"Perry E. Metzger" <[EMAIL PROTECTED]> writes:
> http://www.ucomics.com/tomtoles/2006/05/18/
Here's one that got my attention:
http://www.workingforchange.com/comic.cfm?itemid=20803
--
"A computer is a state machine.
Threads are for people who cant [sic] program state machines."
--Alan
bear wrote:
>
> On Sat, 8 Apr 2006, Ben Laurie wrote:
>
>>> Well the other kind of disincentive was a credit card number. My
>>> suggestion was to use a large denomination ecash coin to have
>>> anonymous disincentives :) ie you get fined, but you are not
Adam Back wrote:
> On Sat, Apr 08, 2006 at 07:53:37PM +0100, Ben Laurie wrote:
>> Adam Back wrote:
>>> [about Brands credentials]
>>> I think they shows are linkable, but if you show more than allowed
>>> times, all of the attributes are leaked, includi
Christian Paquin wrote:
> Adam Back wrote:
>> On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
>>> Brands actually has a neat solution to this where the credential is
>>> unlinkable for n shows, but on the (n+1)th show reveals some secret
>>> in
Adam Back wrote:
> On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
>>> This illustrates a problem with multi-show credentials, that the holder
>>> could share his credential freely, and in some cases even publish it,
>>> and this would allow non-authorize
ertificates enjoy the multi-show
> property.
If I have understood your description correctly it seems to me that this
is defeated if, rather than sharing the master certificate, the bad guy
allows their friend to proxy to them for whatever proofs are required.
That way they never have to giv
Hal Finney wrote:
> Ben Laurie writes:
>> It is possible to use blind signatures to produce anonymity-preserving
>> credentials
>>
>> It seems to me quite obvious that someone must have thought of this
>> before - the question is who? Is it IP free?
>
>
” signature (obviously this would need
to be unlinkably transformed for each member of the key family).
Permalink: http://www.links.org/?p=88
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
stdin was ignored. Something like:
dd if=/dev/zero bs=32k count=1024 | openssl enc -aes-128-cbc > /dev/null
is probably what you want (untested).
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
Alex Alten wrote:
> At 05:58 AM 3/3/2006 +0000, Ben Laurie wrote:
>> [EMAIL PROTECTED] wrote:
>> >> [EMAIL PROTECTED] wrote:
>> >>>> Alex Alten wrote:
>> >>>>> At 05:12 PM 2/26/2006 +, Ben Laurie wrote:
>> >>>>
[EMAIL PROTECTED] wrote:
>> - Original Message -
>> From: "Ben Laurie" <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use
>> Date: Thu, 02 Mar 2006 10:16:55 +
>>
>>
>>
[EMAIL PROTECTED] wrote:
>> 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
&
Alex Alten wrote:
> At 05:12 PM 2/26/2006 +0000, 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 loo
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
Alex Alten wrote:
> At 02:59 PM 2/24/2006 +0000, 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 u
Victor Duchovni wrote:
> On Fri, Feb 24, 2006 at 01:44:14PM +0000, Ben Laurie wrote:
>
>> Ed Gerck wrote:
>>> Paul,
>>>
>>> Usability should by now be recognized as the key issue for security -
>>> namely, if users can't use it, it doesn'
Ed Gerck wrote:
> Ben Laurie wrote:
>> Really? I just write "Ed Gerck" on an envelope and it gets to you? I
>> doubt it. Presumably I have to do all sorts of hard and user-unfriendly
>> things to find out and verify your address.
>
> Perhaps I wasn't c
ons).
> 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 sign mail not because I can't be bothered, but because it is my
policy to not sign mai
Ed Gerck wrote:
> Ben Laurie wrote:
>> Ed Gerck wrote:
>>> This IS one of the sticky points ;-) If postal mail would work this way,
>>> you'd have to ask me to send you an envelope before you can send me
>>> mail.
>>> This is counter-intuitive to u
Ed Gerck wrote:
> Ben Laurie wrote:
>> Ed Gerck wrote:
>>> Paul,
>>>
>>> Usability should by now be recognized as the key issue for security -
>>> namely, if users can't use it, it doesn't actually work.
>>>
>>> And what I h
h key management) don't use it often.
>
> BTW, just to show that usability is king, could you please send me an
> encrypted email -- I even let you choose any secure method that you want.
Sure I can, but if you want it to be encrypted to you, then you need to
publish a key.
Che
101 - 200 of 387 matches
Mail list logo
