Don't store an HMAC key for longer than we need#10747
Don't store an HMAC key for longer than we need#10747mattcaswell wants to merge 1 commit intoopenssl:masterfrom
Conversation
The HMAC_CTX structure stores the original key in case the ctx is reused without changing the key. However, HMAC_Init_ex() checks its parameters such that the only code path where the stored key is ever used is in the case where HMAC_Init_ex is called with a NULL key and an explicit md is provided which is the same as the md that was provided previously. But in that case we can actually reuse the pre-digested key that we calculated last time, so we can refactor the code not to use the stored key at all. With that refactor done it is no longer necessary to store the key in the ctx at all. This means that long running ctx's will not keep the key in memory for any longer than required. Note though that the digested key *is* still kept in memory for the duration of the life of the ctx. Fixes openssl#10743
|
A very nice fix. Thank you! |
t8m
left a comment
There was a problem hiding this comment.
As this provides code cleanup, security hardening and even (minor) performance improvement due to lowering the HMAC_CTX memory footprint I think it is perfectly fine for 1.1.1.
paulidale
left a comment
There was a problem hiding this comment.
Looks fine.
I think 1.1.1 is appropriate too.
| int rv = 0; | ||
| int i, j, reset = 0; | ||
| int rv = 0, reset = 0; | ||
| int i, j; |
There was a problem hiding this comment.
Kind of odd moving this up a line.
There was a problem hiding this comment.
It looked more odd before the change. Now there are two zero-initialized local variables in line 21 and two uninitialized counter variables in line 22.
There was a problem hiding this comment.
I'm not suggesting it gets changed back, I agree it's better this way. I just thought it odd to make a non-essential change.
There was a problem hiding this comment.
At one point during developing this change I removed the reset variable altogether. I later realised I still needed it so put it back again. Inadvertently it went to a slightly different place. But since everyone seems ok with it, and even to prefer it this way, I'll leave it.
The HMAC_CTX structure stores the original key in case the ctx is reused without changing the key. However, HMAC_Init_ex() checks its parameters such that the only code path where the stored key is ever used is in the case where HMAC_Init_ex is called with a NULL key and an explicit md is provided which is the same as the md that was provided previously. But in that case we can actually reuse the pre-digested key that we calculated last time, so we can refactor the code not to use the stored key at all. With that refactor done it is no longer necessary to store the key in the ctx at all. This means that long running ctx's will not keep the key in memory for any longer than required. Note though that the digested key *is* still kept in memory for the duration of the life of the ctx. Fixes #10743 Reviewed-by: Tomas Mraz <[email protected]> Reviewed-by: Paul Dale <[email protected]> (Merged from #10747)
|
Pushed to master. The 1.1.1 version apparently needs a slight adjustment. I'll raise a new PR for that. |
The HMAC_CTX structure stores the original key in case the ctx is reused
without changing the key.
However, HMAC_Init_ex() checks its parameters such that the only code path
where the stored key is ever used is in the case where HMAC_Init_ex is
called with a NULL key and an explicit md is provided which is the same as
the md that was provided previously. But in that case we can actually reuse
the pre-digested key that we calculated last time, so we can refactor the
code not to use the stored key at all.
With that refactor done it is no longer necessary to store the key in the
ctx at all. This means that long running ctx's will not keep the key in
memory for any longer than required. Note though that the digested key
is still kept in memory for the duration of the life of the ctx.
Fixes #10743
Note: It is debatable whether this should come under the "bug" rules or not, and therefore be eligible for backport to 1.1.1. Since it provides no user visible features, and is a security hardening measure I have flagged it for 1.1.1.