Fwd: Re: Question for app developers, like Enigmail etc. - Identicons
stefan.claas at posteo.de
Tue Jun 6 01:24:43 CEST 2017
On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
> On Mon 2017-06-05 16:22:26 +0200, Stefan Claas wrote:
>>> * in the "distinguishing" model, it's not clear that any of the schemes
>>> i've seen are actually better for most humans against a dedicated
>>> attacker who crafts fingerprints to make visual identities that look
>>> similar. do you have any studies showing this capability against a
>>> motivated and technically capable attacker?
>> No, of course i have not. My thoughts as a not so-skilled GnuPG user
>> would be that it helps users detecting (assuming it's bullet-proof)
> what does "bullet-proof" mean, specifically? I ask this not for
> pedantry's sake, but because clearly stating the problem makes it
> possible to know whether a specific solution is applicable.
For me it means that the idendicons should be visually easy to read
and cryptographically secure. Sorry that i have no better explanation.
>> a proper key from a fake key more easily if they have not yet signed
>> (locally) a public key while they already exchanged a couple of
>> emails. I can speak only of Thunderbird/Enigmail wich i use now. It
>> gives a user the usual "Untrusted Good Signatur" and i have to click
>> also on the Details button to carefully verify the fingerprint from an
>> addional list to see if the key belongs to the person the signature
>> claims. An additional visual fingerprint would make that proccess for
>> me easier, if it's bullet-proof.
> It sounds to me like you're saying that you find the key verification
> and certification steps as implemented by enigmail to be
> difficult-to-use. You wouldn't be the only person who has that
> But i don't see how a graphical icon solves that problem. Isn't it a
> workflow problem, and not a visual-comparison problem? If there's a
> standard thing (comparison, lookup, verification) you expect to be able
> to do with the tool, the tool should make that thing easy and simple to
> What specifically is the thing that you're trying to do when you click
> "Details" and verify the fingerprint (from what list?)? Enigmail itself
> can compare fingerprints far better than you or i can, even if there is
> a graphical representation involved :) Maybe there's a different
> question or different interface Enigmail ought to offer in the "Details"
> view entirely?
Well, in the past, before i started using this email combination i
used web based email accounts copy and pasted the message into
a text editor and had no auto key retrival and looked up WWW
key servers to download the required key to verify the sig. I had
not often communications back then. So this was an acceptable
workflow for me.
With the current set-up it's all automatic and my understanding is
that in case i would receive a fake message my set-up would download
the fake key, display it as "Untrusted Good Signature" too, because i
have not yet locally signed the key. Therefore i click details to see the
fingerprint (which i can't memorizy) and look it up again. Maybe, as
casual user who never used this set-up before, i make a fundamentally
mistake in understanding of how the auto retrieve and verify function
works. I mean why is a Details button there to see a fingerprint which
i believe nobody can memorize in the first place? It must serve a purpose,
>>> I'd generally think that if you're looking for a tool to help people
>>> remember and recognize keys that they've seen before, then a mail user
>>> agent is in a great position to do exactly that: just tell the user
>>> explicitly what they've seen before, how often, etc. why depend on the
>>> human visual cortex or on human ability for numeric recall?
>> I could imagine that Joe user average may not always look at mail headers
>> very carefully for a little typo in the from: or reply-to: header in his
>> mail client or web-mailer.
> i agree with you that users won't look at mail headers closely, which is
> why the e-mail client (the "mail user agent", or MUA) should be the
> thing to do the comparison, and to make it very clear to the user when
> something is amiss. But that still doesn't answer the question of what
> the MUA should actually be trying to compare and what results it should
> be highlighting.
For me a MUA is passive and happily accepts what he receives, whether it's
correct content or not, so i can't answer that question, sorry.
More information about the Gnupg-users