OneEyed: PsychoticBoy: that's not the point - Goat may be a scammer, but GLBSE could have handled it much more gracefully for the investors

OneEyed: jurov: he already has this kind of information on Ce, it's not a big deal to double the storage for it, it's only a few bytes per message

OneEyed: And I did my PhD thesis a long time ago on distributed systems, and worked for a long time on trust issues in those systems (including protection against replay attacks, byzantine failures, dos, …)

OneEyed: mircea_popescu: no, I have just read the FAQ, 20 BTC would eat much more than what I would gain, since I don't have much to trade (I just bought a couple hundreds BTC to play with)

OneEyed: Sure, but you insist on security, and that's a good thing. This would add security through forced trust (ability to produce individual messages) without any drawback.

OneEyed: (and protect you against false accusations of having replayed a message if the customers submits several times the same Cs)

OneEyed: Ok, so you identify Ce for uniqueness (with a checksum or whatever), to avoid replay, right?

OneEyed: Yes, but an attacker might get Ce. Let's assume I intercept Ce via a man-in-the-middle attack.

OneEyed: mircea_popescu: so how do you distinguish between two identical orders and a replayed order then?

OneEyed: (a day later might be one second later if I were really an attacker)

OneEyed: Or, as an attacker, intercept such a message, then resubmit it a day later, then again, then again, causing the original customer to buy 30 foobar instead of the intended 10?

OneEyed: You mean I can't sign a message containing "BUY|foobar|10|1", submit it, then submit it again a day later?

OneEyed: mircea_popescu: as far as security is concerned, I haven't seen anything against replay attack. Maybe the attacker should have the possibility to add a "serial" or "uid" extra field, to ensure a signed message cannot be submitted again without being regenerated (it would require a new UID).

OneEyed: Only a keyring file, which is public information, would be transmitted

OneEyed: mircea_popescu: what I had in mind, was a "gpg --refresh-keys" on an internet-connected server, then send the updated keyring to the non-internet machine, and have gpg merge both keyrings (keys being in append-only mode, this cannot remove any information or inject any bogus unsigned information, especially if no new keys are imported during the merge)

OneEyed: And even a revocation would only happen if the key was really compromised

OneEyed: My point was that key update can be hijacked, that wouldn't do any harm except mark a compromised key as compromised

OneEyed: (there is no risk in being fed invalid/bogus/attacker data, that's why people can trust keyservers, the only thing they can do is refuse to serve a key)

OneEyed: mircea_popescu: it gets fed the PGP signed orders in some way (serial link? private Ethernet connection? whatever), so the key updates could enter the same way. Anyway, I was just curious about it, I'm not requesting a change :)

OneEyed: mircea_popescu: the only risk is a DOS, since you cannot remove anything from a key, only add to it - and if someone manages to sign a revocation certificate for someone else, well, that someone else will be happy to have the revocation added to his key!

OneEyed: mircea_popescu: out of curiosity, why don't you offer the possibility to update a key (expiration date, revocation)? It could be transferred the same way orders are, and that would make the system only more secure, wouldn't it?