On Jan 10, 2012, at 6:44 PM, <david.bl...@emc.com> <david.bl...@emc.com> wrote:
> [1] The first open issue is the absence of security guidance to ensure that
> this
> redaction technique effectively hides the redacted information. The redaction
> technique is to concatenate a secret string (called the "redaction key") to
> the
> information to be redacted, apply "any hashing/digest algorithm", convert the
> output
> to base64 and use that base64 string to replace the redacted information.
>
> There are two important ways in which this technique could fail to
> effectively hide
> the redacted information:
> - The secret string may inject insufficient entropy.
> - The hashing/digest algorithm may be weak.
>
> To take an extreme example, if the secret string ("redaction key") consists
> of a
> single ASCII character, and a short email local part is being redacted, then
> the
> output is highly vulnerable to dictionary and brute force attacks because
> only 6 bits
> of entropy are added (the result may look secure, but it's not). Beyond this
> extreme
> example, this is a potentially real concern - e.g., applying the rule of
> thumb that
> ASCII text contains 4-5 bits of entropy per character, the example in
> Appendix A
> uses a "redaction key" of "potatoes" that injects at most 40 bits of entropy -
> is that sufficient for email redaction purposes?
>
> To take a silly example, if a CRC is used as the hash with that sort of short
> input,
> the result is not particularly difficult to invert.
>
> I suggest a couple of changes:
> 1) Change "any hashing/digest algorithm" to require use of a secure hash, and
> explain what is meant by "secure hash" in the security considerations
> section.
Simply saying "any hash algorithm listed in [FIPS180-3]" is precise and
sufficient.
> 2) Require a minimum length of the "redaction key" string, and strongly
> suggest
> (SHOULD) that it be randomly generated (e.g., by running sufficient
> output
> of an entropy-rich random number generator through a base64 converter).
Proposal: "The redaction key SHOULD be based on at least 64 bits of
pseudo-random input that is converted to base64".
> [2] The second open issue is absence of security considerations for the
> redaction
> key. The security considerations section needs to caution that the redaction
> key
> is a secret key that must be managed and protected as a secret key.
> Disclosure
> of a redaction key removes the redaction from all reports that used that key.
Agree.
> As part of this, guidance should be provided on when and how to change the
> redaction key in order to limit the effects of loss of secrecy for a single
> redaction key.
Disagree, given that we have absolutely no idea how systems that use this will
work operationally. Simply telling them "if it is no longer secret, you're
hosed" is sufficient.
--Paul Hoffman
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
