Re: [pkcs11] intro and proposals

[Stefan Marsiske <oasis@ctrlc.hu>]

Dear Daniel, all,

On Tue, Jan 16, 2018 at 06:17:19PM +0000, Daniel Minder wrote:
> Chacha:
> 
> Chacha20 in the IETF variant has been standardized in RFC7539.
> For the original version, there is DJB's paper. However, for Xchacha20 there is nothing but some implementations and, therefore, I doubt we should include it.

the xchacha20 variant is the most robust and secure of the 3 variants, and i
consider them all the same mechanism, just with different security parameters,
as such i would like to keep it in the proposal. some more details on the 3
variants below, you can simply skip reading these until the -------------
marker i included for your convenience.

there's as you also note 3 variants of chacha20, all use the same underlying
crypto algorithm the only thing they differ in is the size of the nonce+block
counter. the size of the nonce impacts nonce generation safety, and the block
counter impacts the maximum size that can be encrypted safely with the same
key/nonce.

block counter size impact:

unlike the original chacha20 and the xchacha20 (both use 64 bit block
counters) which handle maximum messages of size 512bit * 2^64 (18.45 exabytes) per
same nonce/key pair. the ietf variant can only handle ciphertexts with a
maximum size 64*(2^32)-64 bytes (approximatively 256 GB).

the reason for only doing 32bits of block counters are stated in rfc7538:

>1.  The amount of encrypted data possible in a single invocation is
>    2^32-1 blocks of 64 bytes each, because of the size of the block
>    counter field in the ChaCha20 block function. This gives a total
>    of 247,877,906,880 bytes, or nearly 256 GB. This should be
>    enough for traffic protocols such as IPsec and TLS, 
>    but may be too small for file and/or disk encryption. For such uses, we
>    can return to the original design, reduce the nonce to 64 bits, and use
>    the integer at position 13 as the top 32 bits of a 64-bit block counter,
>    increasing the total message size to over a million petabytes
>    (1,180,591,620,717,411,303,360 bytes to be exact).

nonce size impact:

the original chacha20 uses 64 bit nonces and the ietf variant 96 bit nonces
which prohibit safely using randomly generated nonces. the recommended safe
way to use these variants is to randomly generate a nonce *once* and then
increment it for each new message to be encrypted. this means both variants
mandate maintaining state. only the xchacha20 variant uses nonces (192 bits)
big enough to avoid a birthday paradox and to operate in a non-stateful
manner. And xchacha20 is also the only able to construct a nonce-reuse
resistant scheme as simple as `Hk(random ‖ m)`

summa sumarum i believe all three variants are the same mechanism, but with
different nonce/block counter parameters, affecting the overall security and
robustness of this mechanism. the ietf variant is the least robust/secure of
the three in this matter, because it is both stateful and has a limited
maximum message size, while the original salsa only has the limitation of
being stateful, and xchacha20 having none of the limitations. the only setting
that can be considered the least of a standard is xchacha20, but it is also
the strongest of the three variants.

---------------------------------------------------------------
end of technical details re chacha20 nonce/blockcounte variants
---------------------------------------------------------------

> I see two different approaches for the IETF and DJB variant since struct CK_CHACHA20_PARAMS is not different from struct CK_CHACHA20_IETF_PARAMS:
> 
> 1. CK_CHACHA20_PARAMS already includes field ulIvLen. Thus, the two variants could simply be distinguished by using this field, and the mechanism can always be called CKM_CHACHA20.

i'm sorry, i'm a naive newbie here, so i have to ask this: how does a cryptoki
consumer distinguish between the variants? when querying the available
mechanisms from a cryptoki provider only returns the mechanism, not their
"quirks". or does a consumer infer this implicitly by recognizing the tokens
"vendor/type/version".

> 2. Mechanisms are distinguished by their name. However, I would name the IETF version CKM_CHACHA20 since I assume that this will be more widely adopted (e.g. in TLS, RFC7905). DJB's version could be named CKM_CHACHA20_ORIGINAL (or _DJB). Field ulIvLen can be removed from CK_CHACHA20_PARAMS but we should clarify in the description of the other fields that different lengths must be used depending on the selected algorithm.

i would keep the ietf prefix in there. wide adoption is currently in favor of
the original considering the openssh/linux kernel also use the original
variant. furthermore chacha20 is the original, while the ietf variant is one
designed specifically for network traffic, and - unlike the original variant -
thus not a generic solution. 

> For both approaches, CK_CHACHA20_IETF_PARAMS would not be needed at all.

agreed.

> If prefer the first approach.

agreed. if consumers are able to distinguish which variants are supported.

> Salsa:
> 
> Same comment as for Chacha applies to the CK_SALSA20_PARAMS and CK_XSALSA20_PARAMS structs.

agreed.

> Section 1.2.6 not needed here in Salsa section.

yeah, i figured i have to change chacha to salsa in this section to make sense. i have
already an updated version of this.

> Reference [SALSA] is missing in the proposal.

ack. fixed.

please not that this salsa20/chacha20 proposal is bound to change to actually
propose also a joint [latin dance]/poly1305 aead mechanism.

> Blake2:

i reordered some of your comments, as the answer is the same:

> Since table for Key Derivation Functions is only extended explanations for CKD_SHA1_KDF should not be removed from the text.
> It is probably not intentional to delete SHAKE.

i considered this document (as a newbie) to be a kind of patch, not a complete
chapter to replace the current chapter.

> The list of Blake2 KDFs could be formulated as in current working draft to be consistent: "The key derivation functions CKD_BLAKE2B_[160|256|384|512]_KDF, which are based on..."

agreed, changed.

> If new mechanisms for DSA and RSA shall also be defined (see proposed header file changes) explanatory text is missing in appropriate sections.

this is a mistake, i'll remove them.

> There are inconsistencies between text (CKM_BLAKE2B_256_KEY_DERIVATION) and header file definitions (CKM_BLAKE2B_256_KEY_DERIVE) - the text is right.

agreed. changed: all are now *_DERIVE

> XEdDSA / x3dh / Double Ratchet:
> 
> All definitions are located on https://signal.org/docs/ only, and there is no official standard available. I agree that the Signal protocol has been adopted by others in the meantime. Nevertheless, I would like to see a standard first - see my initial comment.

whatsapp with potential 1.3B users, and Microsoft Skype with more than 300M
users can be considered a de facto standard, if not de jure. but as both of
these behemoths are closed source i don't expect any interoperability
initiatives between these two and thus also see a negligible chance of these
parties engaging in a public standard.

> Apart from that:
> 
> For XEdDSA I agree to Darren's comments.

i'm sorry, did i miss those? i cannot find any

> For x3dh table 4, the same comment as for XEdDSA key derivation functions applies.

is that also from Darrens comments? i cannot find them.

> In DoubleRatchet table 6, all attributes should include a term "DOUBLERATCHET" or similar since "CKA_RK" would be too general otherwise.

ack. changed. used X2RATCHET as term.

> Field eCurve in CK_X2RATCHET_INITIALIZE_PARAMS and CK_X2RATCHET_RESPOND_PARAMS could be consistent with the EdDSA proposal, i.e. specifying it as string "curve25519" and "curve448".

in eddsa_notes_Additional_EC_Key_Types_draft2.docx i don't see this, is there
a newer version already available which i missed?

> DoubleRatchet section 2.5 seems to be copied mostly from x3dh without renaming to CK_X2RATCHET_KDF_TYPE. Above comments on the KDF types apply here as well.

yeah, this can also be attributed to me being new to this TC, and being unsure
what the best way to do it is, as you can see in the definition of
CKM_X2RATCHET_INITIALIZE i used 

   CK_MECHANISM_TYPE       kdfMechanism;

and in CKM_X2RATCHET_RESPOND i used 

   CK_X2RATCHET_KDF_TYPE   kdfMechanism;

and indeed section 2.5 should define CK_X2RATCHET_KDF_TYPE not
CK_X3DH_KDF_TYPE, however i'm unsure what do do here, to restrict the KDF with
such a limited list of KDFs, or simply allow any mechanism as i do in
CKM_X2RATCHET_INITIALIZE. the latter would allow more flexibility and no need
to update in later versions of pkcs#11, the former would more strict.

Thank you so much for your review of my proposals! although i disagree with
your assessment that half  of them should not be considered, i hope we can
come to a solution.

I'm looking forward to other review comments, and a reaction from Chris
regarding the AEAD construct, and if nothing comes i'll distribute updated
versions during the weekend.

thanks again!
s