-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 20 March 2011 at 6:31:49 PM, in
, Ben McGinnes wrote:
> On 20/03/11 1:52 PM, MFPA wrote:
>> Whether on a keyserver or on your local keyring, I see
>> little difference.
> Which just shows how your use differs with that of
> others.
On 20/03/11 1:52 PM, MFPA wrote:
> On Sunday 13 March 2011 at 4:39:49 PM, in
> , Ben McGinnes wrote:
>>
>> That too is an understandable argument. Especially when it comes
>> to searching the keyservers, but less easy to maintain in relation
>> to searches of a local keyring
>
> Whether on a keys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 13 March 2011 at 4:39:49 PM, in
, Ben McGinnes wrote:
> On 14/03/11 12:32 AM, MFPA wrote:
>> Fair enough but I believe a person's desire to
>> withhold their own personal information outranks
>> another person's desire to make use of
On 16/03/11 2:04 PM, Doug Barton wrote:
>
> I do, occasionally, get spam directed to addresses that I am sure
> were harvested from they keyservers.
How long ago would those addresses have been harvested from the
keyservers?
> However at the far outside of the range it's no more than 10/month,
>
On 03/15/2011 16:15, Ben McGinnes wrote:
I think that if spammers were harvesting addresses from the keyservers
then you would have received some by now.
I do, occasionally, get spam directed to addresses that I am sure were
harvested from they keyservers. However at the far outside of the ran
On 16/03/11 9:54 AM, MFPA wrote:
> On Monday 14 March 2011 at 1:06:26 AM, in
> , Ben McGinnes wrote:
>
>> Anyway, out of curiosity, did you ever receive spam by that address
>> and prove it had been harvested from the keyservers? I still think
>> harvesting addresses from the keyservers is too mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Monday 14 March 2011 at 1:06:26 AM, in
, Ben McGinnes wrote:
> Anyway, out of curiosity, did you ever receive spam by
> that address and prove it had been harvested from the
> keyservers? I still think harvesting addresses from
> the keyse
MFPA:
>> Trust is not transitive. If A trusts B and B trusts C,
>> there is no requirement that A trusts C.
>
> In real life, true. But what about the GnuPG default of trusting a key
> that carries certifications from 1 fully trusted or 3 marginally
> trusted keys. Unless you manually inspect each
On 14/03/11 11:44 AM, MFPA wrote:
> On Sunday 13 March 2011 at 5:02:52 PM, in
> , Ben McGinnes wrote:
>
>> I'd hardly call it "flashing lights" just to be listed on the
>> keyserver, especially when the same data source also contains a
>> large amount of effectively useless data in which any key o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 13 March 2011 at 5:02:52 PM, in
, Ben McGinnes wrote:
> Ah, I'm still using the 1.4.x branch, so I haven't seen
> any of that.
Nor have I; it is just my understanding from descriptions and answers
to questions that I have read.
>
On 14/03/11 1:12 AM, MFPA wrote:
> On Sunday 13 March 2011 at 7:58:36 AM, in
> , Ben McGinnes wrote:
>
>> So, my question, how would you enable a user to display those keys
>> with known names or identities without searching for a specific key
>> belonging to a particular person?
>
> My understan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 13 March 2011 at 2:47:23 PM, in
, Robert J. Hansen wrote:
> On 3/13/2011 8:37 AM, MFPA wrote:
>> of information unless it is known that somebody is
>> actively looking for the information. In my world...
> So at this point you're sa
On 14/03/11 12:32 AM, MFPA wrote:
> On Sunday 13 March 2011 at 5:48:55 AM, in
> , Ben McGinnes wrote:
>
> I'm assuming a short descriptive paragraph in the gpg.man file plus
> some good info becoming available over time in various "start up
> guides" etc. by searching the web or mailing list archi
On 3/13/2011 8:37 AM, MFPA wrote:
>> If nobody's looking for people's email addresses, then
>> there's no need to not publish email addresses.
>
> That assumes that there is no need to obscure a piece of information
> unless it is known that somebody is actively looking for the
> information. In m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 13 March 2011 at 7:58:36 AM, in
, Ben McGinnes wrote:
> So, my question, how would you enable a user to display
> those keys with known names or identities without
> searching for a specific key belonging to a particular
> person?
M
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 13 March 2011 at 5:48:55 AM, in
, Ben McGinnes wrote:
> I think you're assuming a level of innate understanding
> of what can be done with every part of a UID by every
> user when they create a key. This is most definitely
> not the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Saturday 12 March 2011 at 11:06:14 PM, in
, Robert J. Hansen wrote:
> If nobody's looking for people's email addresses, then
> there's no need to not publish email addresses.
That assumes that there is no need to obscure a piece of informa
On 13/03/11 5:32 PM, John Clizbe wrote:
> Ben McGinnes wrote:
>>
>> Thanks. I think I might have to play around with installing a local
>> server. I don't have a big enough link to run a public server, but
>> running a local one would probably serve as an interesting exercise.
>
> I think that's
On 13/03/11 6:37 AM, MFPA wrote:
>
> Whatever you do with user IDs is optional, since they are just a
> free-text field. And of course a user wanting to make their key
> match more searches could include extra UIDs with additional
> hashes. For example John Smith could
> include hashes of example
On 13/03/11 7:22 AM, Robert J. Hansen wrote:
> On 3/12/2011 1:05 PM, MFPA wrote:
>> How does the WoT idea require me to know the names or email addresses
>> associated with the keys in the trust path? The text strings in User
>> IDs do not feature in the trust calculation.
>
> Yes, in fact, they d
Ben McGinnes wrote:
> On 12/03/11 6:26 PM, John Clizbe wrote:
>>
>> That's the SKS implementation of the key database. On top of the
>> keys, there are several other tables. Within each table there is
>> also empty space, most commonly space left at the end of a page.
>>
>> The present size of ju
On 12/03/11 6:26 PM, John Clizbe wrote:
>
> That's the SKS implementation of the key database. On top of the
> keys, there are several other tables. Within each table there is
> also empty space, most commonly space left at the end of a page.
>
> The present size of just the raw keys -- like you
On 13/03/11 6:37 AM, MFPA wrote:
>
> Whatever you do with user IDs is optional, since they are just a
> free-text field. And of course a user wanting to make their key
> match more searches could include extra UIDs with additional
> hashes. For example John Smith could
> include hashes of example
On 3/12/2011 7:41 PM, Hauke Laging wrote:
> No. You just control who can make the next step: Mapping keys to UIDs.
Yes. Like I said, you want an ORCON system. If you control how people
can use data, then you've entered ORCON.
As soon as you invent an ORCON system, I would love to revisit this
c
Am Freitag 11 März 2011 14:54:57 schrieb Robert J. Hansen:
> On 3/10/2011 3:09 PM, Hauke Laging wrote:
> > That's the technical situation today. But it is no use to announce
> > that to the whole world.
>
> (Did you mean "not necessary" instead of "no use"?)
I meant "not useful".
> It is useful
On 03/12/2011 15:06, Robert J. Hansen wrote:
This scheme offers the illusion of security instead of actual security:
and I feel selling people an illusion is a deeply corrupt act.
+1
I'm hoping that this discussion is going to draw to a close soon, having
already lived through it and drawn ro
Am Sonntag 13 März 2011 00:06:14 schrieb Robert J. Hansen:
> I mean, really, is that what you want to sell? Or should this be taken
> as a, "the idea of blinded UIDs is a good one, but this idea is
> inadequate and should be taken back to the drawing board"?
Your arguing pretends that somebody i
On 3/12/2011 5:25 PM, MFPA wrote:
> A desire to not publish my email addresses (but still have somebody
> who knows any of my addresses find my key on a server) does not equate
> to an assumption that somebody wants to harvest email addresses from
> servers.
Yes, it does.
If nobody's looking for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Saturday 12 March 2011 at 8:24:34 PM, in
, Robert J. Hansen wrote:
> On 3/12/2011 3:10 PM, MFPA wrote:
>> After generating the list of possible email addresses, why would a
>> spammer generate the hashes and search for keys instead of simpl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Saturday 12 March 2011 at 8:22:06 PM, in
, Robert J. Hansen wrote:
> On 3/12/2011 1:05 PM, MFPA wrote:
>> How does the WoT idea require me to know the names or email addresses
>> associated with the keys in the trust path? The text strings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Saturday 12 March 2011 at 8:14:34 PM, in
, Robert J. Hansen wrote:
> Product liability is civil, not criminal.
OK, balance of probabilities rather than beyond reasonable doubt.
> Regardless,
> it doesn't matter: for all that judges tell
On 3/12/2011 3:10 PM, MFPA wrote:
> After generating the list of possible email addresses, why would a
> spammer generate the hashes and search for keys instead of simply
> blasting out messages to the whole lot?
Beats me. You're the one who's assuming someone wants to harvest email
addresses. I
On 3/12/2011 1:05 PM, MFPA wrote:
> How does the WoT idea require me to know the names or email addresses
> associated with the keys in the trust path? The text strings in User
> IDs do not feature in the trust calculation.
Yes, in fact, they do.
In my past, there's an ex-CEO whom I'll just call
On 3/12/2011 11:55 AM, MFPA wrote:
> Determining whether it has been proven beyond reasonable doubt that
> the defendant is guilty as charged has nothing to do with the
> apportionment of blame.
Product liability is civil, not criminal. Regardless, it doesn't
matter: for all that judges tell juri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 9 March 2011 at 1:39:35 PM, in
, Robert J. Hansen wrote:
> 3. Deploying this scheme means:
> (a) people can no longer do fuzzy searches for
> email addresses ("show me all user IDs that
> look like th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 10 March 2011 at 2:58:32 AM, in
, Ben McGinnes wrote:
> I have. Many, many times. There's no point doing it
> for a free email service provider's domain (e.g.
> gmail.com), but sometimes there are advantages in
> checking for key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 9 March 2011 at 1:46:53 PM, in
, Hauke Laging
wrote:
>If you want to validate a key by its signatures
> and see a signature of an unknown key then there is
> (IMHO) no reason why you should know who has certified
> this key. This
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 10 March 2011 at 1:34:13 PM, in
, Robert J. Hansen wrote:
> A public certification is intended as an
> announcement to the world: "Hey, world! I am [name]
> and I vouch for this certificate!"
Which most people will hear as "Hey, w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 11 March 2011 at 1:54:57 PM, in
, Robert J. Hansen wrote:
> It is useful to quite a lot of people. Look at how
> many people map out webs of trust for entirely innocent
> purposes. In fact, mapping out webs of trust is
> necessary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 10 March 2011 at 1:18:36 PM, in
, Robert J. Hansen wrote:
> Remember that a jury trial is often not so much about
> the law as it is about blame: if something bad happens
> the jury wants to be able to point at someone and say,
> "
Ben McGinnes wrote:
> On 12/03/11 12:33 AM, Robert J. Hansen wrote:
>> On 3/11/2011 1:07 AM, Ben McGinnes wrote:
>>> Out of curiosity, how big is that now?
>>
>> My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large.
>
> That's smaller than I would have thought, but a *lot* large
Ben McGinnes wrote:
> On 11/03/11 12:10 AM, Robert J. Hansen wrote:
>>
>> Not at all. Every few days the keyserver network posts complete dumps
>> of all the certificates in the system. (Or, more accurately, various
>> people within the network do.) This exists so that new volunteers who
>> wan
On 3/11/11 2:48 PM, Johan Wevers wrote:
> How much of that is repeated automated signatures from the pgp
> keyserver?
Don't know, but it would be an interesting thing to test.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/ma
On Mar 11, 2011, at 8:33 AM, Robert J. Hansen wrote:
> On 3/11/2011 1:07 AM, Ben McGinnes wrote:
>> Out of curiosity, how big is that now?
>
> My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large.
That's the on-disk SKS database format, and so contains a good bit of non-key
da
On 11-03-2011 14:33, Robert J. Hansen wrote:
> My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large.
How much of that is repeated automated signatures from the pgp keyserver?
--
Met vriendelijke groet,
Johan Wevers
___
Gnupg-users
On 12/03/11 12:33 AM, Robert J. Hansen wrote:
> On 3/11/2011 1:07 AM, Ben McGinnes wrote:
>> Out of curiosity, how big is that now?
>
> My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large.
That's smaller than I would have thought, but a *lot* larger than the
last time I checked
On 3/10/2011 3:09 PM, Hauke Laging wrote:
> That's the technical situation today. But it is no use to announce
> that to the whole world.
(Did you mean "not necessary" instead of "no use"?)
It is useful to quite a lot of people. Look at how many people map out
webs of trust for entirely innocent
On 3/11/2011 1:07 AM, Ben McGinnes wrote:
> Out of curiosity, how big is that now?
My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-
On 11/03/11 7:44 AM, Daniel Kahn Gillmor wrote:
>
> If you want to keep the fact that one keyholder has verified another
> keyholder's identity secret, you cannot solve that by obscuring the
> User IDs.
>
> The right way to solve that is with non-exportable OpenPGP
> certifications, which must be
On 10/03/11 9:23 PM, Hauke Laging wrote:
> Am Donnerstag 10 März 2011 06:17:25 schrieb Robert J. Hansen:
>
>> while you could conceivably come up with an email address with high
>> enough entropy, it's easier to just use anonymous services and
>> dead-drop emails.
>
> Of course, you can create a
On 11/03/11 12:10 AM, Robert J. Hansen wrote:
>
> Not at all. Every few days the keyserver network posts complete dumps
> of all the certificates in the system. (Or, more accurately, various
> people within the network do.) This exists so that new volunteers who
> want to contribute their servi
If one really wanted to overthrow the "People's Republic of Berkeley," using
obfuscated e-mail addresses with the proposed methods outlined in this
thread would be akin to inventing a solution for a problem that doesn't
exist. There are already numerous methods for off-the-record encrypted
commun
On 03/10/2011 03:09 PM, Hauke Laging wrote:
> You have validated my key (among others) and I (among others) have validated
> Ben's. Now you want to validate Ben's key indirectly. Ben's key has ten
> signatures, the one by my key is the only one usable for you. The next person
> who tries to vali
Am Donnerstag 10 März 2011 14:34:13 schrieb Robert J. Hansen:
> On 3/10/2011 5:23 AM, Hauke Laging wrote:
> > ]Those people who just want to protect their
> > social connections by signing other keys without revealing their identity
> > to those who don't know it already have no need to cover their
On 10-03-2011 2:12, Jeffrey Walton wrote:
> Imagine you are Tunisian or Libyan or some other nationality where
> disagreeing with the regime might get you killed. Would you want your
> name and email associated with another's keyring?
I would not sign any key in that case. Even more, I would not
On 3/10/2011 5:23 AM, Hauke Laging wrote:
> ]Those people who just want to protect their
> social connections by signing other keys without revealing their identity to
> those who don't know it already have no need to cover their target addresses
> because the marketing people and "just curious"
On 3/10/2011 4:57 AM, Hauke Laging wrote:
> A little practical advantage: If gpg had such a feature then the
> documentation may mention everything that is needed additionally
> (depending on the targetet opponent: spammers, facebook-alikes,
> secret police) or useful.
Someone would have to be
On 3/10/2011 5:23 AM, Hauke Laging wrote:
> You made a brute force calculation. Why should keyservers allow brute force
> searches for hash IDs? If you use millions of remotely controlled idiot PCs
> simultaneously for that then it may be hard to track them but then we are
> close to a DoS, aren
On 10/03/11 12:46 AM, Hauke Laging wrote:
>
> There are several advantages:
>
> 1) You don't reveal the social connections by signing keys. If you
> want to validate a key by its signatures and see a signature of an
> unknown key then there is (IMHO) no reason why you should know who
> has certif
Am Donnerstag 10 März 2011 06:17:25 schrieb Robert J. Hansen:
> while you could conceivably come up with an
> email address with high enough entropy, it's easier to just use
> anonymous services and dead-drop emails.
Of course, you can create a key with UIDs without name and email only but such
Am Donnerstag 10 März 2011 04:42:25 schrieb Ben McGinnes:
> Which brings us back to creating a pseudonym, using Tor (or other
> anonymising services), getting a disposable mail drop (or using
> alt.anonymous.messages) and going from there. At the bare minimum.
A little practical advantage: If gp
On 10/03/11 4:17 PM, Robert J. Hansen wrote:
> On 3/9/2011 10:42 PM, Ben McGinnes wrote:
>> Which brings us back to creating a pseudonym, using Tor (or other
>> anonymising services), getting a disposable mail drop (or using
>> alt.anonymous.messages) and going from there. At the bare minimum.
>
On 10/03/11 4:20 PM, Robert J. Hansen wrote:
>> Some people think they're going to take over the People's Republic of
>> Berkeley in a military coup
>
> Idiom note for non-Americans: the University of California at Berkeley
> is often called, tongue-in-cheek, "the People's Republic of Berkeley."
>
> Some people think they're going to take over the People's Republic of
> Berkeley in a military coup
Idiom note for non-Americans: the University of California at Berkeley
is often called, tongue-in-cheek, "the People's Republic of Berkeley."
This is a (hopefully humorous) reference to having a m
On 3/9/2011 10:42 PM, Ben McGinnes wrote:
> Which brings us back to creating a pseudonym, using Tor (or other
> anonymising services), getting a disposable mail drop (or using
> alt.anonymous.messages) and going from there. At the bare minimum.
Which brings us back to the elephant in the middle o
On 10/03/11 2:10 PM, Robert J. Hansen wrote:
>
> I think it should also be noted that if I was serious about trying to
> overthrow a government, I'd create a bare certificate without a name or
> an email address on it. I'd also use it as infrequently as possible and
> try to avoid any technology
On 3/9/2011 10:01 PM, Ben McGinnes wrote:
>> Imagine you are Tunisian or Libyan or some other nationality where
>> disagreeing with the regime might get you killed. Would you want
>> your name and email associated with another's keyring? Or would you
>> prefer anonymity?
>
> Another perfectly good
On 10/03/11 12:12 PM, Jeffrey Walton wrote:
>
> Imagine you are Tunisian or Libyan or some other nationality where
> disagreeing with the regime might get you killed. Would you want
> your name and email associated with another's keyring? Or would you
> prefer anonymity?
Another perfectly good re
On 10/03/11 11:03 AM, Hauke Laging wrote:
> Am Mittwoch 09 März 2011 14:39:35 schrieb Robert J. Hansen:
>
> As we all know you love anecdotal evidence, here's mine: You are
> probably right but consider two points:
>
> 1) Today there is no use in obeying the (2) rules. If such a feature
> is impl
On 10/03/11 12:39 AM, Robert J. Hansen wrote:
>
> 4. My suspicion is the number of users covered by (2) is pretty
> small.
Very probably, at least at the moment (for the reasons Hauke
mentioned).
> My suspicion is the number of users impacted by (3) is pretty large.
Almost certainly.
> My sus
On 10/03/11 12:24 AM, Robert J. Hansen wrote:
>
> It seems like this is really close to asking for private stream
> searching, which would be the next logical step -- some way for the
> client to query the database for a record in such a way there is no
> way for the database to know what was quer
On Wed, Mar 9, 2011 at 8:11 AM, Ben McGinnes wrote:
> On 9/03/11 2:44 AM, Johan Wevers wrote:
>> MFPA schreef:
>>
> Something that would not be necessary if the
> underlying openPGP implementations could handle hashed
> user IDs.
>>>
Isn't it much easier to use the key ID / signat
Am Mittwoch 09 März 2011 14:39:35 schrieb Robert J. Hansen:
> 2. To really gain benefit from this scheme, you must:
>
> (a) have a non-trivially-brute-forceable email address
> (b) want to be able to hide your email address
> 3. Deploying this scheme means:
>
> (a) peo
Am Mittwoch 09 März 2011 14:11:16 schrieb Ben McGinnes:
This discussion has been there before (initiated once by me).
> This would allow someone to use a single key for multiple identities
> or pseudonyms, without the information about those identities being
> learned by different groups. Well,
On 3/9/2011 8:11 AM, Ben McGinnes wrote:
> * Anyone trawling through keys on a public server or downloading
> random keys cannot see who owns that key or what their email address
> is, but anyone who knows Joe or his email address can search the
> keyservers for that data because the hash can
On 3/9/2011 8:11 AM, Ben McGinnes wrote:
> Personally, I think it's an interesting idea and I can see the value
> in it, but I'm not sure there are enough people really pushing for it
> (yet). With things like the data retention legislation being pushed
> in Europe, Australia and other countries,
On 9/03/11 2:44 AM, Johan Wevers wrote:
> MFPA schreef:
>
Something that would not be necessary if the
underlying openPGP implementations could handle hashed
user IDs.
>>
>>> Isn't it much easier to use the key ID / signature for
>>> that? You already have that.
>>
>> I don't unders
MFPA schreef:
>>> Something that would not be necessary if the
>>> underlying openPGP implementations could handle hashed
>>> user IDs.
>
>> Isn't it much easier to use the key ID / signature for
>> that? You already have that.
>
> I don't understand.
Use the keyID / signature as the hashed user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 3 March 2011 at 12:33:27 AM, in
, Robert J. Hansen wrote:
> It's not a tangent at all, and for almost the exact
> reason you cite. You would say "it can easily be done."
> I would say, "it can easily be enforced." I'm not
> seeing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 3 March 2011 at 8:30:13 AM, in
, Johan Wevers wrote:
> Op 2-3-2011 20:25, MFPA schreef:
>> It is also much easier to create new email addresses
>> than it is to change phone numbers. And more practical
>> to have multiple or short
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 3 March 2011 at 8:36:36 AM, in
, Johan Wevers wrote:
> Op 3-3-2011 1:21, MFPA schreef:
>> Something that would not be necessary if the
>> underlying openPGP implementations could handle hashed
>> user IDs.
> Isn't it much easier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 3 March 2011 at 8:32:00 AM, in
, Johan Wevers wrote:
> Op 2-3-2011 21:14, Daniel Kahn Gillmor schreef:
>> You'd still need to do the work of changing, say, MUAs
>> to re-think their key-selection criteria to include
>> keys withou
Op 3-3-2011 1:21, MFPA schreef:
> Something that would not be necessary if the underlying openPGP
> implementations could handle hashed user IDs.
Isn't it much easier to use the key ID / signature for that? You already
have that.
--
Met vriendelijke groet,
Johan Wevers
--
Met vriendelijke gr
Op 2-3-2011 21:14, Daniel Kahn Gillmor schreef:
> You'd still need to do the work of changing, say, MUAs to re-think their
> key-selection criteria to include keys without e-mail addresses (maybe
> just based on the human-readable part of the To: header?)
That can be done much easier: upload a ve
Op 2-3-2011 20:25, MFPA schreef:
> It is also much easier to create new email addresses than it is to
> change phone numbers. And more practical to have multiple or
> short-life email addresses than is the case with phone numbers.
Not really, here I can get a new (mobile) phone number by buying a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 2 March 2011 at 8:14:08 PM, in
, Daniel Kahn Gillmor wrote:
> it sounds to me like you've simply made it difficult
> for people to correspond with you over long periods of
> time because your e-mail address isn't likely to
> conti
On 3/2/11 7:37 PM, Ben McGinnes wrote:
> More seriously, I've been through this discussion with MFPA before and
> I can see some circumstances where his idea might have merit, so I'd
> be willing to help test too.
Same here. I am deeply skeptical, but not unwilling to be proven wrong.
IMPOSSIBLE
On 1/03/11 1:20 PM, Grant Olson wrote:
>
> I wouldn't mind testing to help out, but I'm not throwing away my
> current key anytime soon.
Ah ha! Another hint about the scav hunt. ;)
More seriously, I've been through this discussion with MFPA before and
I can see some circumstances where his ide
On 3/2/11 6:34 PM, MFPA wrote:
> You are going off at a tangent. The mechanism for preventing the phone
> number being obtainable from a query of the phone book or directory
> enquiry services is not relevant; just the fact that it can easily be
> done.
It's not a tangent at all, and for almost th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 2 March 2011 at 8:27:50 PM, in
, Robert J. Hansen wrote:
> The analogy continues to break down. "Binding," in the
> context of the analogy, means "if someone breaks this
> instruction, they will be hurt." Maybe the government
>
On 3/2/11 2:25 PM, MFPA wrote:
> Once, maybe. But for quite a few years (in the UK at least) there have
> been many competing directory enquiries services, and more recently
> the online versions as well. Choosing to be ex-directory is a
> binding instruction to your telephone company not to releas
On 03/02/2011 02:25 PM, MFPA wrote:
> For somebody who uses the same email address to communicate with many
> contacts and keeps the same email address for a long time, that is
> true. For somebody like me who uses various different email addresses
> and replaces some of them on a regular basis it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 2 March 2011 at 4:07:19 AM, in
, Robert J.
Hansen wrote:
>> The benefits of your phone number being ex-directory
>> are the benefits that derive from it being harder for
>> people to obtain your phone number without your
>> permis
> The benefits of your phone number being ex-directory are the benefits
> that derive from it being harder for people to obtain your phone
> number without your permission, harder to link the number to your
> name/address, and impossible to find your address or phone number by
> looking in the phon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 2 March 2011 at 1:43:45 AM, in
, Daniel Kahn Gillmor wrote:
> On 03/01/2011 08:05 PM, MFPA wrote:
>> My analogy, admittedly not a direct comparison, would be having a
>> phone number that is ex-directory. It is no defence against
On 03/01/2011 08:05 PM, MFPA wrote:
> My analogy, admittedly not a direct comparison, would be having a
> phone number that is ex-directory. It is no defence against random
> dialling, nor against your number being recorded from outgoing calls
> if you don't take steps such as withholding the CLI,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Tuesday 1 March 2011 at 1:54:25 AM, in
, Daniel Kahn Gillmor wrote:
> However, i'm quite serious about the flaws paralleling
> the failures of NSEC3 to prevent DNS zone enumeration.
> the problem space is slightly different, but i think
> t
On 02/28/2011 08:54 PM, Daniel Kahn Gillmor wrote:
> On 02/28/2011 07:44 PM, Grant Olson wrote:
>
> You can pull a copy of a stalled/never-submitted Internet-Draft from here:
>
> git://lair.fifthhorseman.net/~dkg/openpgp-hashed-userids
>
> If anyone wants to push this further, please let me kn
On 02/28/2011 07:44 PM, Grant Olson wrote:
> I think something similar could be done with hashed emails. Just some
> (non)standard like:
>
> hashed_uid://$SHA1_OF_EMAIL/$RIPEMD_OF_EMAIL
>
> But using something better than my obviously naive hash-collision
> prevention algorithm.
this is (very r
99 matches
Mail list logo
