.Net: Will my RSA keys still function after August 2012?

Asked 12/7, 2012 at 15:14 Answered 14/7, 2012 at 9:13

.net cryptography rsa cryptoapi rsacryptoserviceprovider

I just read this article RSA keys under 1024 bits are blocked, and in my .NET software I make extensive use of 384bit keys. Will my program still be able to generate/store/read keys from the MachineKeyStore using the RSACryptoServiceProvider? Or will I be forced to send out a patch?

Decrepit answered 12/7, 2012 at 15:14 Comment(20)

wow thanks for making me notice this. – Colobus 12/7, 2012 at 15:15

Most likely you will be in trouble (if not with this patch then with one of the next ones), but your current code is flawed at the first place: 384-bit RSA keys are WEAK and you must consider updating them to at least 1024 bits ASAP not waiting for Microsoft's patches. – Candlewood 12/7, 2012 at 15:37

You could crack a 384 bit key on a desktop computer in a few days. Or was it weeks. – Dogmatist 12/7, 2012 at 16:6

we use 768bit and 1024bit. Our tokens are screwed but our software is ok, for now. – Colobus 12/7, 2012 at 16:20

@EugeneMayevski'EldoSCorp It has been a conscious trade-off: performance of signature verification was more critical than security in this case. – Decrepit 12/7, 2012 at 16:29

@Dogmatist I think it is in the order of weeks. – Decrepit 12/7, 2012 at 16:30

Symmetric encryption is both faster and more secure for an equivalent key size over asymmetric encryption. Why aren't you doing a key exchange as is the typical practice? Or perhaps you are. I don't have all of the details. – Dogmatist 12/7, 2012 at 16:32

@Joshua - You should start to update your RSA keys before the patch hits. When something can be cracked in a matter of weeks, you may as well NOT even use it, I suggest doing something greater then 1024 because even that is only secure enough. the industry is moving to 2048. – Carlow 12/7, 2012 at 17:18

The first key of (over) that size was "cracked" in 1994. Computing power nowadays is much better and easier to obtain. Furthermore, the algorithms to factor the key have been improved as well. This presents very little challenge against a hacker with e.g. a botnet, let alone a security agency. – Demodena 12/7, 2012 at 18:22

@Dogmatist They are signatures, used to authenticate senders, I believe you can't do that with symmetric encryption, since it requires a shared secret. – Decrepit 12/7, 2012 at 19:19

@owlstead I use them to sign very short messages, even with 384bits the added signature more than doubles the size of the messages, so going 2048 is really not an option. Besides, millions of them need to be verified quickly, and larger keysizes also slow down verification. – Decrepit 12/7, 2012 at 19:26

I presume you cannot use a symmetric or combined symmetric / asymmetric solution? Those millions of messages are all from different parties? – Demodena 12/7, 2012 at 19:57

It's noteworthy that the article states specifically that keys UNDER 1024 bits will be invalidated (i.e, keys of exactly 1024 bits will still be valid) – Dogmatist 12/7, 2012 at 20:9

@Joshua Would you care to provide some sample code? – Dogmatist 12/7, 2012 at 20:28

@Dogmatist I use standard .NET functions, see msdn.microsoft.com/en-us/library/… – Decrepit 12/7, 2012 at 20:43

I meant specific details regarding your implementation. What exactly are you passing around? How many clients are there typically, how many transactions per second? etc etc. – Dogmatist 12/7, 2012 at 23:2

"Factoring a number of 120 [decimal] digits [about 400 bits] will require 3 to 4 days on a single core of a typical PC." Why use encryption at all, if you make it that weak? See Modern integer factorization software on crypto.SE – Censor 14/7, 2012 at 11:50

btw If you need fast verification, use e=3, and there are message recovery schemes that let you embed the message into the signature. – Censor 14/7, 2012 at 11:53

Personally I'd probably use elliptic curves, even if verification times are a bit worse. You can achieve decent security level with 40 byte signatures. – Censor 14/7, 2012 at 11:57

@CodeInChaos that would be ISO 9796, Digital Signature Schemes giving Message Recovery. I second the use case for Elliptic Curve here, both schemes can be found in the C# version of the bouncy castle libraries. – Demodena 15/7, 2012 at 22:27

I got a reply from Microsft (Kurt L Hudson), and this update should only affect chainbuilding, so it seems RSACryptoServiceProvider will continue to function with small keysizes after August 2012.

Decrepit answered 14/7, 2012 at 9:13 Comment(1)

According to the linked article, anything that uses the chain building function is affected, which includes SSL and S/MIME (aka CMS). Other users with small key sizes should check which protocols and functions they use. – Demodena 15/7, 2012 at 22:39

This is a suggested answer to a question that came up in the comments.

You could probably find a way to use a symmetric method to authenticate clients. I'm assuming right now youre using a typical RSA signing scheme, in which a message hash is signed by a clients private key, which can then be verified by the public key.

You could perhaps perform an exchange of a persistent key and then encrypt the message digest with that key instead of the asymmetric one. You would still be guaranteed that whoever sent the message knew the secret key, though you would have no way of verifying whether the message was sent by the client or the server (since both know the key). If the client challenged the server during authentication, that would help prevent man in the middle attacks (though the client would need to have the public key of the server embedded locally)

Dogmatist answered 12/7, 2012 at 20:24 Comment(1)

I appreciate your suggestion, but it has nothing to do with the initial question. It will be a massive tasks to convince all my users to upgrade before August 2012, so I rather not change the code or the encryption scheme. Besides, the system is decentral, like email, so clients cannot store a fixed list of public keys, they have to be transfered alongside the message. They can then choose to whitelist certain keys, so that whenever they receive another message, can rest assured it was from the same sender as before. – Decrepit 12/7, 2012 at 23:35

If minimizing signature size is critical, then RSA is poor choice to begin with. DSA and ECDSA both produce shorter signatures with much greater strength that RSA. However, neither DSA or ECDSA will come close to the speed of signature verification for RSA 384.

If, however, you must continue using the keys you have then you will have to change your code to avoid using Microsoft cryptography APIs. You can use for example the Bouncycastle C# library if you use C#. Finally, you can complain to Microsoft about this. I doubt it will do any good but you can always try.

Barmecide answered 13/7, 2012 at 21:43 Comment(2)

My main complaint is that they announced this only 1 month before they will make this breaking change. I have a installed base of almost half a million users, and no auto-update functionality, so there will be no way to make sure everyone upgraded before the patch hits. – Decrepit 14/7, 2012 at 9:4

Note that key generation and, more importantly, signature creation is much much much faster when using ECDSA compared with an RSA key of similar strength. So it depends on the protocol and the total system which is most beneficial. – Demodena 15/7, 2012 at 22:35

Recommended topics

Hot tags