On Wed, Sep 15, 2010 at 04:51:35AM +1200, Peter Gutmann wrote: > It would help if the OP could indicate how much CPU budget they had available > for encryption and/or authentication, just the two chapters referenced above > contain ~120 references for different mechanisms and tradeoffs.
I was just driving to work one day and wondering, "suppose you were an important public official who recorded all his activities, and you were trying to assure the public that a voluntarily-disclosed portion of a (e.g. sound) recording had not been tampered with; how would you do it?" Obviously tacking a 16-byte HMAC (or worse, digsig) to each 16-bit sample wouldn't be very space-efficient. In practice, I suppose you could just sign every second, and only disclose with one second granularity. Same principles may apply with videoconferencing, or perhaps IM. The idea of efficiency also could matter with, say, an interactive TCP session (e.g. keystrokes in SSH on TCP with Nagle algorithm), but I think you really want those fully authenticated, because a rogue keystroke could be, well, really bad (rm -fr /^Jtmp/bar). I don't think there's any clever solution to be found there, but it seems a shame to spend 56 octets overhead (TCP~=40, HMAC=16) for 1 octet of data. -- I find your ideas intriguing and would like to subscribe to your newsletter. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email [email protected] to get blacklisted.
pgpZAD5bMm2qU.pgp
Description: PGP signature
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
