locked
Inconsistent Async support in Cryptography API? RRS feed

  • General discussion

  • After getting real comfortable with the .Net crypto api, you guys go and change it up completely in the Windows Runtime :)  One of the things I've noticed is the inconsistent Async support provided by the api.  Looking at the CryptographicEngine class I see the following

    Decrypt() -> has async version DecryptAsync()

    DecryptAndAuthenticate() -> does not have an async version

    Encrypt() -> does not have an async version

    EncryptAndAuthenticate() -> does not have an async version

    Sign() -> has async version SignAsync()

    SignHashedData() -> has async version SignHashedDataAsync()

    VerifySignature() -> does not have an async version

    VerifySignatureWithHashInput() -> does not have an async version

    I'm a little confused by all of this, and why some methods got async counterparts, and some did not. But what has me most confused is why CryptographicEngine.Encrypt() does not have an async version considering how intensive encryption uses the CPU, and introduces slowness in the UI.

    Yes, I'm sure you saying "Why does it matter, just wrap the call to encrypt in Task.Run()". True, this could be a solution, but it seems like a work around to a design issue in the existing api ? Why do we have a DecryptAsync() and no EncryptAsync() ? Can someone help me understand the motives around partial support for async behavior in the Crypto api ?

    Tuesday, January 7, 2014 10:05 PM

All replies

  • Hi BigBlueDodge,

    Good question, I'm not sure if you will satisfied with my answer but I will give a try.

    Normally some methods need more than 50 milliseconds to execute and in order not to block UI thread, some Async methods are newly added in Windows 8.1 as new feature. You may notice that decryption procrss spend much time than encryption. See the remark section of the Async methods in CryptographicEngine class, for instance DecryptAsync():

    If the key is a persisted key and the decrypt operation requires UI or takes a long time, use the DecryptAsync method instead of the Decrypt method. For example, UI is required when decrypting using a key that is strongly protected.

    I believe this kind is design is to ensure your app works fast and fluid in the Windows Runtime. More information please read this blog: http://blogs.msdn.com/b/windowsappdev/archive/2012/03/20/keeping-apps-fast-and-fluid-with-asynchrony-in-the-windows-runtime.aspx

    And personally I would understand like this way: While decrypt something, I would like to see what is the message, but the process takes long time, I'd like do thing other than just wait before the screen, so I use Async and I can work with UI thread. But when encrypt something, it will not take long time, so I wait for less than 50 milliseconds, it's ok.

    Hope this help.

    --James


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, January 8, 2014 2:33 AM
    Moderator
  • James, I'm not questioning WHY you need async methods, as I'm very versed in that respect.  What I'm questioning is why Microsoft chose to implement Async versions on some of the methods, and did not on other (which obviously should have them).  The example I gave was that the synchronous Decrypt method has an async counterpart DecryptAsync. As you stated, encrypting/decrypting is a CPU intensive task and would be just the type of task that should be done asynchronously. Now seeing Decrypt/DecryptAsync, if you look at the counterpart Encrypt() you will see that Microsoft did not create a EncryptAsync() alternative.  There are other methods where Microsoft did not create async alternatives, and this seems very odd to me. It's like the API was partially written.  What I'm trying to understand is if there are legitimate technical reasons why there can't be a EncryptAsync, or if it just because of a lazy developer :)
    Wednesday, January 8, 2014 4:20 PM
  • Hi BigBlueDodge,

    I know you are asking for why some method implement Async but some not, unfortunately I can only tell it is by-design, and I can hardly provide more information, its out of forum support scope.

    But it is a really interesting question, I'd like to know why either. Let's see if we can get a satisfied reply from some senior engineers. Please be patient.

    Best Regards,

    --James


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Friday, January 10, 2014 1:25 AM
    Moderator
  • Hello,

    This is excellent feedback. It is up to the API architect to decide if a method needs an "async" equivalent. I agree that we should support asynchronous encryption as well as decryption. I can't think of any technical reason to not include this functionality. I will file a design change request against the next version of the API. 

    Again thanks for your feedback. We appreciate constructive feedback like this from our development community.

    -James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Friday, January 17, 2014 11:06 PM
    Moderator