How to Implement Deterministic Encryption Safely in .NET

Question

I am trying to implement a deterministic encryption scheme in .NET. This link suggests I use AES-SIV mode encryption. An alternative is to use AES-CTR [ k1, nonce, message] mode with HMAC[ k2, message] as the nonce. This is effectively the same as AES-SIV.

In .NET, there is no implementation of AES-SIV. AES-CTR mode is also not available in .NET. The only .NET compatible library which implements AES-SIV I can find is Miscreant .NET. This is not FIPS validated.

Does anyone have any suggestions on how to implement a deterministic encryption scheme in .NET?

This post is a continuation of a previous post.

My Project: I have several bankers who will send the balance information for thousands of bank accounts to a server. The account numbers will be encrypted using this scheme prior to sending to the server for security purposes. The server deliberately will not have the private key [I'm setting up a zero-knowledge encryption scheme]. On the client side, Banker1 and Banker2 must be able to encrypt the account number in a deterministic way that allows any Banker to decrypt account numbers returned from the server. For this reason, I decided to use HMAC(message) as the nonce for my encryption scheme and append it to the ciphertext. AES-CTR[ k1, nonce, message] || HMAC[ k2, message] where nonce = HMAC[ k2, message].

Thank you!

Answer 1

You can safely use HMAC-SHA256 instead of the SIV mode custom PRF to derive the nonce/authentication tag. There's some caveats:

• HMAC-SHA256 gives a 256-bit output; you'll have to truncate it to the nonce size.

• HMAC-SHA256 takes in a single bit string, so it can't distinguish the boundary between a header (unencrypted associated data) and payload (encrypted message); the SIV mode custom PRF is defined on a tuple of bit strings. So make sure that if you compute HMAC over more than just a ciphertext, you uniquely encode the tuple of $(a, c)$ as a bit string you pass to HMAC-SHA256.

• Beware limits on total volume of data for AES-SIV or similar! For example, if your ‘AES-CTR’ takes a 96-bit nonce (as AES-GCM uses), you must limit your total volume of data to well below $2^{48}$ messages, so that there is no danger of nonce collision. For example, you might limit it to a billion messages, $2^{30}$.

  AES-SIV internally uses $\operatorname{AES}_k(n) \mathbin\| \operatorname{AES}_k(n + 1) \mathbin\| \operatorname{AES}_k(n + 2) \mathbin\| \cdots$ with a 128-bit nonce $n$, instead of what is usually meant by AES-CTR, which is $\operatorname{AES}_k(n \mathbin\| 0) \mathbin\| \operatorname{AES}_k(n \mathbin\| 1) \mathbin\| \operatorname{AES}_k(n \mathbin\| 2) \mathbin\| \cdots$ with a (say) 96-bit nonce $n$ and 32-bit block counter like AES-GCM uses. The details don't matter that much as long as you pay close attention to the advertised adversary advantage and data volume limits.

• Make sure to write known-answer test vectors for the system you think you're implementing, using another tool or another library, so that you can do quick self-tests to confirm interoperability.

• Avoid the term ‘zero-knowledge’ unless you're actually doing cryptography involving zero-knowledge proofs, which are a specific technical concept involving provers, verifiers, extractors, and simulators. Saying ‘zero-knowledge encryption’ proudly announces that you have more money for a marketing department than for a cryptography engineering department.

  • Even if you encrypt identifiers, there's lots of information to be learned from network structures and databases with ‘anonymized’ (really, pseudonymized) identifiers. So ‘zero-knowledge’ is especially inappropriate here if you're only concealing the labels, not the structure of the database.

  • In this scenario, I would advise you to either (a) persuade your management to invest more money in cryptography engineering including hiring competent implementors and auditors, or (b) start polishing your CV, because this job is doomed. This is not a comment on your value or intelligence as a person! Obviously you're working hard to learn. But it is not confidence-inspiring to hear that your management are tasking someone who has to ask a pseudonymous forum of strangers on the internet for help with cryptographic basics in order to handle private banking information for thousands of clients over the internet.