8

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?

Maestro
  • 9,046
  • 15
  • 83
  • 116
  • wow thanks for making me notice this. – ericosg Jul 12 '12 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. – Eugene Mayevski 'Callback Jul 12 '12 at 15:37
  • You could crack a 384 bit key on a desktop computer in a few days. Or was it weeks. – Wug Jul 12 '12 at 16:06
  • we use 768bit and 1024bit. Our tokens are screwed but our software is ok, for now. – ericosg Jul 12 '12 at 16:20
  • @EugeneMayevski'EldoSCorp It has been a conscious trade-off: performance of signature verification was more critical than security in this case. – Maestro Jul 12 '12 at 16:29
  • @Wug I think it is in the order of weeks. – Maestro Jul 12 '12 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. – Wug Jul 12 '12 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. – Security Hound Jul 12 '12 at 17:18
  • 1
    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. – Maarten Bodewes Jul 12 '12 at 18:22
  • @Wug They are signatures, used to authenticate senders, I believe you can't do that with symmetric encryption, since it requires a shared secret. – Maestro Jul 12 '12 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. – Maestro Jul 12 '12 at 19:26
  • 1
    I presume you cannot use a symmetric or combined symmetric / asymmetric solution? Those millions of messages are all from different parties? – Maarten Bodewes Jul 12 '12 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) – Wug Jul 12 '12 at 20:09
  • @Joshua Would you care to provide some sample code? – Wug Jul 12 '12 at 20:28
  • @Wug I use standard .NET functions, see http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider.signhash.aspx – Maestro Jul 12 '12 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. – Wug Jul 12 '12 at 23:02
  • "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](http://crypto.stackexchange.com/questions/100/modern-integer-factorization-software) on crypto.SE – CodesInChaos Jul 14 '12 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. – CodesInChaos Jul 14 '12 at 11:53
  • 1
    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. – CodesInChaos Jul 14 '12 at 11:57
  • @CodeInChaos that would be [ISO 9796, Digital Signature Schemes giving Message Recovery](http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=54788). I second the use case for Elliptic Curve here, both schemes can be found in the C# version of the bouncy castle libraries. – Maarten Bodewes Jul 15 '12 at 22:27

3 Answers3

4

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.

Maestro
  • 9,046
  • 15
  • 83
  • 116
  • 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. – Maarten Bodewes Jul 15 '12 at 22:39
0

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)

Wug
  • 12,956
  • 4
  • 34
  • 54
  • 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. – Maestro Jul 12 '12 at 23:35
0

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.

President James K. Polk
  • 40,516
  • 21
  • 95
  • 125
  • 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. – Maestro Jul 14 '12 at 09:04
  • 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. – Maarten Bodewes Jul 15 '12 at 22:35