daohualiuxiang
/
AspNetCore.Docs
mirror of https://github.com/dotnet/AspNetCore.Docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Correct spelling and add missing superscript.

pull/247/merge
Barry Dorrans 2015-06-02 16:14:20 -07:00
parent b7613c2893
commit 0d6eddc53b
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
aspnet/security/data-protection/implementation/subkeyderivation.rst
View File

@ -58,4 +58,4 @@ Once K\ :sub:`E` is generated via the above mechanism, we generate a random 96-b
output := keyModifier || nounce || E\ :sub:`gcm` (K\ :sub:`E`,nounce,data) || authTag
.. NOTE::
Even though GCM natively supports the concept of AAD, we're still feeding AAD only to the original KDF, opting to pass an empty string into GCM for its AAD parameter. The reason for this is two-fold. First, :ref:`to support agility <data-protection-implementation-context-headers>` we never want to use K\ :sub:`M` directly as the encryption key. Additionally, GCM imposes very strict uniqueness requirements on its inputs. The probability that the GCM encryption routine is ever invoked on two or more distinct sets of input data with the same (key, nonce) pair must not exceed 2\ :sup:`32`. If we fix K\ :sub:`E`, we cannot perform more than 232 encryption operations before we run afoul of the 2\ :sup:`-32` limit. This might seem like a very large number of operations, but a high-traffic web server can go through 4 billion requests in mere days, well within the normal lifetime for these keys. To stay compliant of the 2\ :sup:`-32` probability limit, we continue to use a 128-bit key modifier and 96-bit nonce, which radically extends the useable operation count for any given K\ :sub:`M`. For simplicity of design we share the KDF code path between CBC and GCM operations, and since AAD is already considered in the KDF there is no need to forward it to the GCM routine.
Even though GCM natively supports the concept of AAD, we're still feeding AAD only to the original KDF, opting to pass an empty string into GCM for its AAD parameter. The reason for this is two-fold. First, :ref:`to support agility <data-protection-implementation-context-headers>` we never want to use K\ :sub:`M` directly as the encryption key. Additionally, GCM imposes very strict uniqueness requirements on its inputs. The probability that the GCM encryption routine is ever invoked on two or more distinct sets of input data with the same (key, nonce) pair must not exceed 2\ :sup:`32`. If we fix K\ :sub:`E` we cannot perform more than 2\ :sup:`32` encryption operations before we run afoul of the 2\ :sup:`-32` limit. This might seem like a very large number of operations, but a high-traffic web server can go through 4 billion requests in mere days, well within the normal lifetime for these keys. To stay compliant of the 2\ :sup:`-32` probability limit, we continue to use a 128-bit key modifier and 96-bit nonce, which radically extends the usable operation count for any given K\ :sub:`M`. For simplicity of design we share the KDF code path between CBC and GCM operations, and since AAD is already considered in the KDF there is no need to forward it to the GCM routine.