On Jan 16, 2012, at 3:44 PM, Murray S. Kucherawy wrote: > One of the security area directors has placed a DISCUSS on the above draft. > The working group needs to talk about the issue raised and determine how to > proceed. > > The specific issue is that a simple hash over a key prepended to the data to > be redacted is not a strong security measure. Although we've mentioned that > this isn't much of a concern in our case in the proposed new text, the > complaint has reappeared. For example, the simple key-hash solution is > susceptible to a few simple recovery attacks. > > Among other things, the concern is that doing something like this on the > standards track might lead future efforts to believe this mechanism is > sufficient for arbitrary data protection when it is not. > > The proposals going forward appear to be: > > a) Instead of a hash of key + data, replace the algorithm with HMAC, as > defined in RFC2104. > > b) Add even more explanatory text so that the reader has it clear that we are > not attempting to completely secure something here, and acknowledge fully > that there are weaknesses in our algorithm. (The Wikipedia page for HMAC > gives a pretty good description of the comparison and attacks.) > > c) Attempt to argue that it's good enough as it is, and that's how we want it. > > Comments, please.
b, kinda. I'd like to add an alternative hash with the following algorithm: 1. ROT13 2. Suffix with a semicolon That way "[email protected]" would translate to "fgrir;@blighty.com" That makes the email address illegal, so it cannot be mailed accidentally, and also means it can't be unthinkingly copied and pasted into a message (or made usefully clickable by a zealous MUA or...). For many purposes, that is a strong enough hash. For this particular purpose it might be considered a better choice than SHA* by some participants, simply because it is reversible and so will allow the recipient of a report to take action that they might not otherwise be able to do. OK, it's a slightly frivolous suggestion, but clarifying that the encoding used only needs to be as strong as the entity redacting the message wants it to be might avoid all the concerns about security. The only thing that's required for the redaction not to break incident aggregation workflow - and hence be better than xxxxxx@ - is for it to be a 1:1 encoding. Beyond that, the choice of strength of encoding - on the spectrum between the identity hash ("steve" -> "steve") and an arbitrary mapping maintained privately by the report generator ("steve" -> "4783256") - is a policy choice made by the report generator. Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
