I'm interested in providing a managed dll for use in .Net that provides authenticated encryption services. The DLL might be used in a WPF program or an ASP application. I have a couple of questions related to Microsoft's crypto and stream models.
Authenticated encryption modes (CCM, CWC, EAX, GCM, etc) typically produce two artifacts - first is the cipher text and second is the authentication tag. Its fairly easy to stream encryption, but there can be some problems. For example, CCM cannot be streamed due to the way the header is built and authenticated encryption modes produce an authentication tag.
Decryption is trickier since it can't be streamed. Decryption can't be streamed because all the cipher text must be available, and that cipher text must be verified using the authentication tag before being decrypted.
How does one adapt an authenticated encryption mode for a block cipher so that it can be used in a CryptoStream
? Is it even possible? Perhaps its why Microsoft does not supply it?
Does Microsoft have a recommendation? For example, break apart a large message into smaller messages or units (each with its own tag)? Or does MS recommend buffering until the entire message and tag is input?
Where does Microsoft recommend 'putting' the tag? At the beginning of the stream? At the end of the stream?
Some helpful references:
Authenticated Encryption (AE) is a block cipher mode of operation which simultaneously provides confidentiality and authenticity (integrity) assurances on the data. It became readily apparent that securely compositing a confidentiality mode with an authentication mode could be error prone and difficult.
Encryption transforms meaningful data into what looks like gibberish using a secret that can also be used to reverse the process. Reversing the process is called decryption. Authentication is the process of convincing a gatekeeper that you are who you say you are, typically by proving that you know a secret.
Algorithms providing confidentiality and authenticity can be divided into two categories: authenticated encryption (AE) and authenticated encryption with additional data (AEAD). The two NIST modes, CCM and GCM, and the proposed mode, EAX are AEAD algorithms.
Counter with cipher block chaining message authentication code (counter with CBC-MAC; CCM) is an authenticated encryption algorithm designed to provide both authentication and confidentiality. CCM mode is only defined for block ciphers with a block length of 128 bits.
In 2010 the microsoft CLR security team released an extension to the System.Security.Cryptography that included authenticated symmetric encryption specifically GCM. Why they haven't done anything with it since then, I don't know.
But, since your question put emphasis on "what would microsoft do?", there it is... they did that.
You are using an assumption that does not really hold for authenticated encryption baard on stream ciphers such as GCM: that you cannot decrypt before verification. This is true for e.g. AES in CBC mode that is authenticated by a MAC when padding oracles apply. GCM mode, for instance, does not perform padding as the underlying stream cipher is CTR mode encryption. This means in turn that padding does not have to be applied, thus padding oracles do not apply.
Of course, it would be extremely unwise to perform any business logic with the decrypted data before it has been authenticated. Any code that touches unverified data should be considered high risk, and it should be statically analysed and audited. If you want to perform any business logic earlier then you should indeed make sure that it gets authenticated before do so. Splitting it up in smaller parts would certainly make sense.
Obviously these are just my recommendations. For recommendations by Microsoft: if they cannot be found using Google or (god forbid) Bing: ask Microsoft. Nobody here can talk for them.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With