Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1671652
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Problem with new X.509 is_hash_blacklisted() interface |
| Date | 2017-06-21 14:50 +0200 |
| Message-ID | <tUNf4-682-21@gated-at.bofh.it> (permalink) |
| References | <tUMVH-61A-7@gated-at.bofh.it> <tLLvP-5El-5@gated-at.bofh.it> <tUtT5-2pP-39@gated-at.bofh.it> <tUMVH-61A-7@gated-at.bofh.it> |
| Organization | Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > This can be told to skip a particular algorithm for when the caller
> > has one precalculated. The precalculated hash can be passed to
> > is_hash_blacklisted(). This would typically be the case for a signed
> > X.509 message.
>
> This last part seems a premature optimization to me. Is there a
> performance concern preventing us from using (4) only?
Crypto stuff is relatively slow - and in the case of X.509 and PKCS#7 the
caller will already have calculated a hash. The most likely situation
currently, I think, is that we will only have sha256 hashes in the blacklist,
and whatever we're checking will have a sha256 hash also.
Possibly, I could just pass the precalculated hash into is_data_blacklisted()
and so avoid having to call is_hash_blacklisted() from outside.
> In any case, the approach and the code look sound to me, although I
> think adding a hash of a type that we don't know how to calculate
> deserves a warning at least.
There are two issues with that:
(1) We don't know what hashes are available without checking to see what
modules are available. However, to do this would involve loading the
hash algorithm module - but we might not be in a position to do this yet
(the blacklist is loaded before we start userspace).
(2) A module implementing a hash algorithm might be blacklisted by the hash
that we've been given to add to the blacklist. I think this is a more
general problem - and might require us to restrict blacklisting to hash
algorithms that are built in.
David
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Problem with new X.509 is_hash_blacklisted() interface David Howells <dhowells@redhat.com> - 2017-06-20 18:10 +0200
Re: Problem with new X.509 is_hash_blacklisted() interface Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-06-21 14:30 +0200
Re: Problem with new X.509 is_hash_blacklisted() interface David Howells <dhowells@redhat.com> - 2017-06-21 14:50 +0200
Re: Problem with new X.509 is_hash_blacklisted() interface Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-06-21 15:10 +0200
csiph-web