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 > impression. > > 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 > do. > > 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, or not? >>> 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. Regards Stefan _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
