RSA and DSA
Both methods are used here in the context of sending a message encrypted by a symmetric key algorithm suchas AES.
1) Encrypts the message.
2) The encryption key/password is encrypted using recipient's RSA public key.
3) A hash of the encrypted message is determined.
4) The hash is then signed using the sender's DSA private key.
If the key/password is very strong, preferably a 256 bit binary key, then the encrypted key/password will not need to be changed that often.
RSA encryption could be used on the message but the message size is limited to the RSA bit strength employed and reduced even further if padding is used. The recommended padding is the Optimal Asymmetric Encryption Padding (OAEP) scheme, which uses a hash function, resulting in this simple formula for determining the maximum message size: (Bit strength)\8 - 2 - 2x(Hash length)\8. So, with a bit strength of 1024 and a 160 bit hash we get 86 bytes. We have a very different animal then to AES, for example, which can handle GBs of message. Actually, the term padding is a misnomer. If we applied RSA 1024 encryption to 160 bits, say, then the encrypted output would be 1024 bits, the RSA bit strength, but we would not recognise the structure of the 160 bits. It has the opposite effect to a message digest.
1) The signature is verified using the sender's DSA public key.
2) A hash of the encrypted message is determined and if that equates with the sent hash then the encrypted message is effectively authenticated.
3) The encrypted key/password is decrypted using the recipient's RSA private key.
4) The decrypted message is then decrypted.
If Eve, a dastardly eavesdropper, intercepts any of the files sent then they will be of no use to her without the recipient's RSA private key. The plaintext version of the key/password never enters the public domain.
RSA 1024 was broken in the middle of 2017 and the US National Institute of Standards and Technology (NIST) is recommending we now use at least RSA 2048. There is a correspondence between the RSA modulus/bit strength and security strength. AES 128 has a security strength of 128 bits. SHA512, for example, because of the birthday paradox, has a security strength of 256 bits. Here is a comparison taken from NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key ManagementJanuary 2016 Table 2 page 53.
Code: Select all
Strength RSA modulus ECDSA
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 512
The DSA bit strengths are the same as RSA. More on Elliptic Curve Digital Signature Algorithm (ECDSA) later.
The correspondence between RSA bit strength and security strength is more precisely defined in Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation Program page 106.
The NIST reckon that RSA 2048 should hold us in good stead until about 2030 beyond which we should move up to 3072 bits. The NIST are not currently 'pushing' over and above RSA 3072. The NIST are not the only authority making recommendations and, after much reading, the following code, GenerateKeyPairs, a console application, defaults to a bit strength of 3072 bits; exceeding all minimum recommendations at this time (2018).
With regard DSA the NIST Digital Signature Standard specifies the following choices for the pair L and N where L is the bit strength and N is the length of the hash function to be signed.
(1024, 160) NIST FIPS-186-2 for earlier than Windows 8
(2048, 224) Above plus NIST FIPS-186-3 for Windows 8 and later
(2048, 256) -do-
(3072, 256) -do-
DSA (2048, 224) does not work with Microsoft APIs because SHA224 is not supported by Windows. FIPS-186-4 was published July 2013 but the four choices above were not expanded upon. DSA (1024, 160) has not been broken yet but it is no longer recommended by the NIST. So, the DSA used in Windows 7 is no longer recommended.
I found DSA to be very slow. For a 256 bit hash the signing and verifying times for DSA (2048, 256) and (3072, 256) were in the seconds whereas with ECDSA 256 I got, with one test, 0.9ms and 1.2ms for signing and verifying respectively. There are not many DSA/ECDSA performance comparisons on the Internet but of those that I found they did not report such a marked difference as I found. Perhaps the Microsoft DSA implementation is a poor one. With DSA I would have been lumbered with writing code to cater for Windows 7 (and earlier) and Windows 8 (and later).
Clearly, ECDSA wins hands down with regard to Microsoft's APIs and is OK for Windows Vista and later. We have a few ECDSA bit strengths to chose from but with ECDSA 256 having a security strength of 128 bits it is an ideal partner for RSA 3072 at 128 bits.
A little off topic but until recently the NIST recommended that passwords should have a bit strength/entropy of at least 80 bits. This has now been updated to 112 bits.
Console application GenerateKeyPairs.
We could have a separate folder for each person we deal with but there will be the resulting file navigation to contend with. I have opted to have everything in one folder: My keys, other people's keys and the applications. To this end GenerateKeyPairs asks for a prefix to add to the key names. For my keys I simply chose DR_ and got these keys.
The bit strengths are got from the code assignments.
On my machine using '-gen gcc -Wc -O3' the keys were generated in a little more than four seconds. If you have FreeBASIC 64 bit then use it because generation is a lot faster. Just to put things into perspective I generated a public and private key pair for RSA 16384, with 32 bit, and it took over 8 minutes. The law of diminishing returns is very noticeable with both RSA and DSA key generation and this is reflected when using the keys.
GUI application RSA-ECDSA
This was written using José Roca's WinFBX Windows framework. If you have Paul Squires' WinFBE then you will already have the necessary files on board and it is a simple matter to add the WinFBX path to the Editor's Compiler Setup. If you are using another IDE then go to JoseRoca / WinFBX at GitHub and click on the green 'Clone or download' button; then click on 'Download ZIP'. Within the unzipped WinFBX-master folder is a folder called Afx. Copy Afx to your FreeBASIC's installation's inc folder. That is it. If you have FreeBASIC 64 bit then do the same into it's inc folder; wherever you put that. I am suggesting the GitHub link as it has the latest Afx folder. In the WinFBX folder there are a lot of examples and there is also FBWinSpy for 'dissecting' GUIs. You can get a copy of the WinFBX help file here at the bottom of the first post.
I am compiling RSA-ECDSA.bas with '-gen gcc -Wc -O3 RSA-ECDA.rc'.
This what RSA-ECDSA looks like.
We don't need a help file for that, do we? <smile>
The Microsoft open file dialog is used extensively and I am using a heavily adapted version of José's code. Since there are a lot of different files the filtering is done programmatically. If we clicked on 'Verify a .sig file', for example, then we get a list of *ECDSAPublicKey*.dat files and nothing else. We are not left scratching our heads as to which algorithm we should use and what type of key. After selection we get another open file dialog with a list of *Hash.dat files and nothing else. After that selection we get another open file dialog with a list of *Hash.dat.sig files and nothing else. The only output with this task is a message advising whether we have a successful verification or not. The open file dialog title bar keeps us informed; as does the filter.
The Function Hash is one of my stock functions. It could have ben trimmed down for RSA-ECDSA but that would defeat the object of a stock function. <smile>
The first three tasks are obvious and don't require an explanation.
Hash a file option.
This is for hashing an encrypted message - the one subject to symmetric encryption, such as AES. If we hash <Somefile.ext> then we get <Somefile.ext_Hash.dat> and that will be a 256 bit (32 byte) binary hash; as opposed to a 64 character hex string. The open file dialog here has an all files ("*.*") filter; I don't know how you are naming your encrypted message.
Verify hashes option.
The first open file dialog needs the encrypted message which is then hashed for us. The second open file dialog needs a hash file, <Somefile.ext_Hash.dat>. This operation is similar to 'Verify a .sig file' in that the only output with this task is a message advising whether we have a successful authentication or not.
The padlock icon in the window caption is placed there by
Code: Select all
pWindow.SmallIcon = LoadImage(hInstance, MAKEINTRESOURCE(100), IMAGE_ICON, 32, 32, LR_SHARED)
and the entry '100 icon padlock.ico' in the resource file.
The 'signature' bitmap at the bottom right is placed there by
Code: Select all
LoadImage(hInstance, MAKEINTRESOURCE(101), IMAGE_BITMAP, 0, 0, LR_SHARED)
pWindow.AddControl("BitMapButton", , ID_DR, "#101", 223, 266, 26, 33)
and the entry '101 bitmap DRmed.bmp' in the resource file.
The 'signature' is just a bit of fun. I figured that I couldn't write an application for signing without signing the dialog. <smile> Just click on the bitmap for another reason for it's existence.
The images can be downloded at the beginning of the next post.
The 256 bit hashing done in 'Hash a file' and 'Verify hashes' uses a truncated SHA512 and adapted to overcome the length extension bug in the SHA-2 family of hash functions.
If RSA-ECDSA's closing position differs to that of its opening position it's closing position will be remembered and used at the next opening. I do this often as I have two monitors and prefer some applications to open on the secondary monitor. No big deal but it is there if required.
TaskDialog, as opposed to messagebox, has been used throughout. José's code makes it very easy to implement. Some of the parameters are the same for each execution so I wrote a little wrapper which takes just four parameters; the same number as messagebox. TaskDialog is nothing like as powerfull as TaskDialogIndirect and is only a small step up from messagebox but here is an example.
That was got from
Code: Select all
TDWrapper Hwnd, "Hash comparison", "Hash of " + EncMainMessage + " and given hash match.", TD_INFORMATION_ICON
All the source code is in the next post and any revisions will take place there. The files for theming are also there.
Code: Select all
RSA 3072/ECDSA 256 (128) versus RSA 7680/ECDSA 384 (192) on key sizes 256 bits and 384 bits respectively.
enc 0.2ms 0.6ms
dec 9.3ms 119.1ms
sig 0.3ms 0.7ms
ver 0.5ms 1.0ms
Here we can see the performance of RSA suffering very badly moving from a 128 bit security strength to a 192 bit security strength. The ECDSA performance, on the other hand, is very much less noticable. Having said that enc/dec on a key/password will be a rare event, perhaps every year or so. Organisations involved in mass sig/ver operations will be looking for a balance between speed and security and will need a very good reason to be using a security level of 192 bits in 2018. NIST clearance levels are 128 bits up to Secret and 192/256 bits up to Top Secret. For most of us RSA 3072/ECDSA 256 (128) is more than adequate.
As written RSA-ECDSA will not accomodate ECDSA 521. It could, but I am not going to go there. I have no need to rub shoulders with the NSA, GCHQ and their like.
Special thanks to José Roca - WinFBX is absolutely awesome.
Still on topic but minus the encryption/decryption aspect. Suppose you have a pdf which anyone can have but want to send it to someone in the knowledge that they know for certain it was from you and that is has not been tampered with; a licence agreement, for example. The message now is a pdf and not an encrypted file. Hash the pdf file and then sign the hash. When the recipient verifies the signature and then verifies the hashes using options 4 and 6 of the RSA-ECDSA dialog then they will know that you sent the pdf and it has not been tampered with. We can sign anything - a jpg or whatever.
You may have wondered what the difference between a digital signature and a HMAC is. HMAC is symmetrical: Both the sender and receiver use the same secret key. 'A' could produce a licence agreement and a HMAC but 'B' may repudiate sending anything. Digital Signatures are asymmetric and provide integrity plus non-repudiation whereas HMAC provides only integrity. 'B' cannot repudiate the signature as his/her private key is not known to anyone else and 'A' cannot try and pull a 'fast one'.
The D-Wave 2000 qubit quantum computer, which costs $15 million dollars and will need a spare room to put it in, is about 100 million times faster than a desktop PC or 3600 times faster than the current super computers. I do not know what the running costs are but if anyone can afford £15 million dollars they can probably afford getting some solar panels fitted on their roof. <smile> It is reckoned not to be a fully fledged quantum computer as, it seems, it does not exploit quantum entanglement. It may be some years before quantum computers become main stream, if ever they do. Remembering that 2^256 = 2^128 x 2^128 > 10^38 x 2^128 then AES256 is more powerful than 10^38 x AES128. It is thought that AES256 is post-quantum computer proof. I have not seen anything with regard ECDSA but the 'arithmetic' used by RSA and DSA is such that both are destined to be dead in the water in the post-quantum computer era. In other words the security strength of RSA and DSA based upon classical computers collapses with quantum computer computing. The NIST recently held a competition with regard to post-quantum computer cryptography. All being well we should be well prepared.
Finally, I should mention that cryptlib has both RSA, up to RSA 4096, and ECDSA, up to ECDSA 521, giving both a Windows and Linux route but my comfort zone is the Windows API so please forgive me for preferring to keep comfortable. <big smile>