I'm going to respond to a few points that I already know my answer to. I might not actually have all that much interesting to say about the more complicated points, though...
> But what do you mean by 'deprecated for server use'? I meant that GnuPG 1.4 is not deprecated for server use. By which I mean it is pretty much advised against for desktop use. I didn't mean that GnuPG 2.x was deprecated for anything at all :-). > which is only about a more complex deployment, not about security risks. It does say "targeted to the desktop", by the way. > In my view crypto software that leaks information, for example caches > passphrases for unauthorized access, doesn't qualify for any kind of > use. That's because it is assumed that if someone can access your ordinary agent socket, that would mean they have full access to your user account and are thus qualified to use it. It doesn't leak any information if it is simply handing that information to the user. It's just that your definition of "user" is quite different than the definition that was used in the design of the agent! (I kinda thought we had established this by now...) > Initial problems with new software are okay as long as they can be fixed > when they arise. I'm not talking about /problems/, I'm talking about /design/. I atrociously hate car analogies in IT, so I'm going to do one. If you compete with a lorry in the 24 hours Le Mans, and you finish last, would you say this is an "initial problem" in the design of your new lorry? And if you tried to deliver a load of 50 liter beer kegs to a bar in the center of a city with a lot of speedbumps, using a Le Mans Prototype racing car, would you then complain that it seems not to work altogether that brilliantly? I'm not even saying that the agent is incapable of handling a large amount of keys. I'm just saying that since it is possible that the agent was designed for use by a single human with a usual amount of keys, you could run into unforeseen problems when you use it in a totally different way. Such as that the agent doesn't have the required bottom clearance to go over speed bumps. > I now added --try-secret-key to all asymmetric decoding calls, which > made processing a bit faster and possibly counters the passphrase cache > weakness with asymmetric decryption. I really don't think it will prevent a cached passphrase from being used! Also, I doubt it serves any purpose without hidden recipients. > That's only critical with a common secret key depository. But this is what you're doing right now with GnuPG 2.1, right? AIUI, you have one agent and multiple public keyrings. This is similar to one secret keyring and multiple public keyrings in GnuPG 1.4. > Who would use a single secret keyring with different public keyrings? Erm... see above? :-) Apart from that, it's actually something people do use. It's why you need --no-default-keyring if you don't want to use multiple keyrings with --keyring. If everybody only ever used one public keyring at the same time, --no-default-keyring would be implied. >> I am assuming you kill an agent when a user logs off. > > No, I don't, as a user can hold multiple nym accounts and WME related > addresses, which e.g. with a POP3 download are processed in common. First of all, I'm saying "in this scenario of how you could solve it, I'm assuming part of the way you solve it is by killing the agent when a user logs off". So "No, I don't" is not an answer I'd expect, I'd then expect "No, I would not". Furthermore, I don't understand. When this user logs off why would it be bad to kill their agent? They've sent "QUIT" to your POP3 server and closed the TCP/IP connection: they've logged off your proxy! You can just restart the agent when they log back in. It has no relation with how many nym accounts this user has whatsoever, that's a non-sequitur to me. > With your interpretation of 'holder' gmail is the holder of all the mail > accounts hosted there. No, I said this correctly, I think. I used two different words, owner and holder. GMail is the /owner/ of all the e-mail accounts. If they decide to go bankrupt, you can balk all you want, you won't get your <itsa...@gmail.com> name back to use it. It's gone together with its owner, GMail / Google. You don't have any rights to the gmail.com name. The /holder/ is the one who has the passphrase. And since a nym account is not protected by a passphrase but by an OpenPGP keypair, the one holding the private key is the holder. And your proxy has the private key. Not your user. You yourself say they don't even need to know the key's ID, let alone its private key. If I know your GMail passphrase, and I log in and change that passphrase, I've taken your account. Would you say you still hold that account? By rights you perhaps should, but you *don't*. If you decide you quite like being the pseudonym <m...@nyma.com> and take it from your user, would you say they still hold that account? That's the crux of the matter. Your users know that the server operator of nyma.com can just say to them "Hey, it's my server, I don't want you to use <m...@nyma.com> anymore". They need to know this goes for your proxy as well. > Of course users have to know that only the route between the proxy and > the nym server is secured. I hope you mean "of course I need to inform them", not "of course users should figure this out", because it's slightly ambiguous the way you say it :-). > Delay on the way to the recipient is a > bothersome though extremely important characteristic of anonymous > delivery. But delay at the sender is more of a hindrance than a help. I'm saying you should delay delivery sign delay delivery deliver to first remailer it delays delivery .... Don't delay the action of sending, delay the action of delivery. > I think we are agreed that delay in a conversation, though indispensable > for anonymity, can't be infinite. Delay in a conversation serves no purpose at all. What the people doing conversation see: (TCP/IP connection from client to proxy) 12:00 C> Please send my message 12:00 P> Alright, please accept a delay... 12:05 P> Okay, I'm done pondering the great truths, deliver! 12:05 C> <My message> 12:05 P> Thanks and (TCP/IP connection from proxy to first remailer) 12:05 P> Got a message for ya 12:05 R> Go ahead 12:05 P> <Message> 12:05 R> Thanks What an observer sees: TCP/IP connection to proxy, originating at client: 12:00 C> <Encrypted> 12:00 P> <Encrypted> 12:05 P> <Encrypted> 12:05 C> <Encrypted> 12:05 P> <Encrypted> TCP/IP connection from proxy to first remailer: 12:05 P> <Encrypted> 12:05 R> <Encrypted> 12:05 P> <Encrypted> 12:05 R> <Encrypted> The temporal connection between the two is glaringly obvious! You know when the client sent this message! Delay in a conversation doesn't help. You need to put a delay /between/ conversations. I can agree that delays shouldn't be infinite. Kinda goes without saying, although this would be a *very* secure system. > And remember, without a faked timestamp, no matter how long you wait, > your signature still unveils that you had access to a computer at the > time you signed the message. It only reveals that your computer was running if your proxy is running at the client. If the proxy is on a server, you could use the delay tactic and it would severely limit the use of knowing the timestamp. But when the proxy is on the client, then I think that a faked timestamp is useful. Also when you don't want to change your whole design. But how do/did you handle timestamps with GnuPG 1.4? > I hope I gave convincing reasons now. Yes. Also; when I didn't reply to things you said earlier in the discussion, that was sometimes because I agreed so had nothing interesting to say about. This tactic does make it seem like I only have counterpoints and never agree with anything, so I should probably be more aware of this effect... > But I do, as there's no other way to tell the proxy account holder > whether local message processing succeeded. This depends on the intelligence of the proxy. If it depends on the first remailer to do checks and report success, then it won't work. But if it can check the sanity of the message without doing any connections to the outside world, it can do all of those checks and only delay the signing. And I already said that I see no reason to use the user's password to encrypt the private key, so signing can't fail due to a wrong passphrase. > You're at the client site, where it's only about forwarding messages as > fast and convenient as possible without revealing any important > information. This seems to presume the proxy runs at the client. I've already said above that the delay tactic only makes sense when the proxy runs on a server, so I agree. > After all that discussion you still think suppressing the true timestamp > of a message is 'abuse', possibly even fraud? No, I said using --faked-system-time to fake a signature timestamp is abuse of functionality. The man page says "This option is only useful for testing", and that's not what you're using it for. Please read what I say. I said: I think this distinction is important: *It's not a feature in any GnuPG* *version*. That you can abuse things to do what you want does not make it a supported feature! Deconstruction: do what you want -> fake signature timestamps abuse things -> use an option that says "for testing only" You said "worth to be backported to 1.4". This seemed to imply to me you thought the worth was in faking signature timestamps, but a backport implies that we're talking about an actual feature. To which I say: *it's not a feature*. > I have to thank all of you to render projects like mine possible. Heh, well, I can't take credit for that, so I'll happily pass these thanks on to the people that do :-). Oops, this mail has gotten so much larger than I intended... HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
