Freigeben über


RSA keys under 1024 bits are blocked

Public key based cryptographic algorithms strength is determined based on the time taken to derive the private key using brute force methods. The algorithm is deemed to be strong enough when the time required to derive private key is prohibitive enough using the computing power at disposal. The threat landscape continues to evolve.  As such, we are further hardening our criteria for the RSA algorithm with key length less than 1024 bits.
To further reduce the risk of unauthorized exposure of sensitive information, Microsoft has created a software update that will be released in August 2012 for the following operating systems: Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. This update will block the use of cryptographic keys that are less than 1024 bits.
Some issues that you may encounter after applying this update may include:

  • Error messages when browsing to web sites that have SSL certificates with keys that are less than 1024 bits
  • Problems enrolling for certificates when a certificate request attempts to utilize a key that is less than 1024 bits
  • Creating or consuming email (S/MIME) messages that utilize less than 1024 bit keys for signatures or encryption
  • Installing Active X controls that were signed with less than 1024 bit signatures
  • Installing applications that were signed with less than 1024 bit signatures (unless they were signed prior to January 1, 2010, which will not be blocked by default).

To prepare for this update, you should determine whether your organization is currently using keys less than 1024 bits. If it is, then you should take steps to update your cryptographic settings such that keys under 1024 bits are not in use. 

Certificate Chain Build Block of Keys under 1024 Bits

The Crypto API builds a certificate trust chain and validates that chain using time validity, certificate revocation, and certificate policies (such as intended purposes). Once the update is applied, during chain building there is an additional check to ensure that no certificate in the chain has key length less than 1024 bits). Chain building is done using the CertGetCertificateChain function. If a key chain building issue is encountered with such a certificate, then the errors produced are as follows:
Event 11, CAPI2

• CERT_TRUST_IS_NOT_SIGNATURE_VALID
• CERT_TRUST_HAS_WEAK_SIGNATURE

Working CSPs that Default to Allow Minimum 512 Bit Keys

There are three cryptographic service providers (CSPs) that default
to allow minimum 512 bit keys in Windows Server 2008 R2:

  1. Microsoft Base Cryptographic Provider v1.0 (RSA)
  2. Microsoft Base DSS and Diffie-Hellman
    Cryptographic Provider (DH)
  3. Microsoft DH SChannel Cryptographic Provider
    (DH)

When working with V2 certificate templates, if you do not specify the key size, then the default CSP with default key size will be used to generate the key. If the default CSP is one of the above 3 CSPs on the client box, then the generated key will be under 1024 bits. The CA which has been updated with weak key protection will reject such request. As a result, we recommended that you do the following:

  1. Configure the template to specify the cryptographic providers that you want to be utilized by selecting Requests must use on of the following
    providers
    .
  2. Configure the Minimum key size to 1024 bit or larger.

When using certreq, ensure that you specify a 1024 bit or larger key in the INF file. For additional information, see Best Practice for Configuring Certificate Template Cryptography.

Discovering Usage of Keys under 1024 Bits in Certificate Templates

You can run the following query on your Certification Authorities (CAs) in order to discover certificate templates that are utilizing
keys under 1024 bits:

Certutil -dstemplate | findstr "[ msPKI-Minimal-Key-Size"| findstr /v "1024 2048 4096"

Note: The command should be run in each forest in your organization.

If you run this query, templates that utilize keys that are smaller than 1024 bits will be shown with their key size. The following figure illustrates that two of the built-in templates SmartcardLogon and SmartcardUser templates have default key lengths that have minimum key sizes of 512 bits. You may also discover other templates that were duplicated with minimum key sizes of less than 1024 bits.

For each template you discover that allow less than 1024 bit keys, you should determine whether it is available to issue certificates as shown in the Certificate Templates section of the Certification Authority console.

For these templates, you should consider increasing the Minimum key size to a setting of at least 1024 (assuming the devices to which these certificates are to be issued support a larger key size).

You should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size (assuming certificate autoenrollment is enabled).

If you have issued certificates using the built-in Smartcard Logon or Smartcard User templates, you will not be able to adjust the minimum key size of the template directly. Instead, you will have to duplicate the template, increase the key size on the duplicated template, and then supersede the original template with the duplicated template.

After you have superseded the template, you should use Reenroll All Certificate Holders to cause the client computers to reenroll and request a larger key size.

Discovering usage of RSA keys under 1024 Bits in Cryptographic Operations

You can utilize CAPI2 logging starting with Windows Vista or Windows Server 2008 computers to help identify keys under 1024 bits. You can then allow the computers to perform their normal operations and check the log after a period of time to help identify such keys. You can then use that information to track down the sources of the certificates and make the necessary updates.

To accomplish this, you must first enable verbose diagnostic logging. To enable verbose mode logging:

  1. Open the Registry Editor (regedit.exe).
  2. Navigate to the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\crypt32
  3. Add a DWORD (32-bit) value DiagLevel with value of 0x00000005
  4. Add a QWORD (64-bit) value DiagMatchAnyMask with value of 0x00ffffff

Once you do this, you can then enable CAPI2 operational logging in the Event Viewer. The CAPI2 Operational log is located under Applications and Service Logs, Microsoft, Windows, and CAPI2 in the Event Viewer. To enable logging, right-click the Operational log and select Enable Log.

Once you've collected the log, you can use the following filter to reduce the number of entries that you have to search through in order to find certificate operations with keys under 1024 bits. The following filter looks for keys of 512 bits.

<QueryList>

 
<Query Id="0"
Path="Microsoft-Windows-CAPI2/Operational">

   
<Select Path="Microsoft-Windows-CAPI2/Operational">Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength='512']]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName='RSA']]]]]]</Select>

 
</Query>

</QueryList>

You can also query multiple key lengths with a single query. For example, the following filter queries for both 384 bit and 512 bit keys.

<QueryList>

 
<Query Id="0"
Path="Microsoft-Windows-CAPI2/Operational">

   
<Select Path="Microsoft-Windows-CAPI2/Operational">Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength='384']]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName='RSA']]]]]]
or
Event[UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyLength='512']]]]] and
UserData[CertGetCertificateChain[CertificateChain[ChainElement[PublicKeyAlgorithm[@publicKeyName='RSA']]]]]]</Select>

 
</Query>

</QueryList>

Discovering issued RSA certificates with keys less than 1024 bits

Ingolfur Arnar Stangeland came up with a certutil command to show whether a CA has issued RSA certificates with keys less than 1024 bits. He published the instructions in his blog post "How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)" https://blogs.technet.com/b/instan/archive/2012/08/03/how-to-identify-if-your-adcs-has-issued-any-certificates-with-public-keys-lt-1024-bits-in-preparation-for-kb2661254.aspx

Additional resources

Security advisory https://technet.microsoft.com/security/advisory/2661254.

KB 2661254: https://support.microsoft.com/kb/2661254

Additional blog posts:

https://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx

https://blogs.technet.com/b/pki/archive/2012/08/14/blocking-rsa-keys-less-than-1024-bits-part-3.aspx

Comments

  • Anonymous
    January 01, 2003
    Tony Fiore: I asked our PMs on your behalf, but only one came back with "I'm not sure." I think it may be more efficient if you ask your question on the Security forum social.technet.microsoft.com/.../threads

  • Anonymous
    January 01, 2003
    Philippe Cornu: The update is still scheduled to be available tomorrow on the download center. More details will be published tomorrow along with the KB and advisory. Damon Betlow: Your servers will be affected by the update, if installed. CAs are absolutely affected by the update. The results from the certutil command do not indicate that you are safe. I am not even sure if the command is working as expected. You will not see the registry key util the update is applied, but you can put the registry settings in place before applying the update and your changes will remain after the update is applied. Please, be sure to check tomorrow for more information about this update. There will be a KB article and Microsoft Security Advisory.

  • Anonymous
    January 01, 2003
    Security advisory technet.microsoft.com/.../2661254. KB 2661254: support.microsoft.com/.../2661254 Ryan Mrachek: This update affects only RSA certificates with keys less than 1024 bits. Please, read the KB article and try out the update. :-)

  • Anonymous
    January 01, 2003
    GPAV: If a Microsoft Exchange Server has an SSL certificate with <1024 bit RSA key and the update is applied mail distribution is blocked. Outlook 2010 will produce an error that the certificate cannot be trusted and no email will be delivered. RickB: I tried your PowerShell script and got a ton of errors - a lot of access denied on those files. Did you try it out?

  • Anonymous
    January 01, 2003
    Q: How will this affect VPNs? A: PPTP used for VPN uses MPPE (technet.microsoft.com/.../cc757532.aspx) for encryption, which is different protocol and is not affected by the blocking RSA keys less than 1024 bits. Microsoft’s MPPE uses RC4 cipher suite for encryption, while non-Microsoft clients may use different ciphers for encryption. None of these is affected by this change. This change is applicable only to RSA asymmetric keys and we are changing the behaviour of chain building (msdn.microsoft.com/.../aa376078.aspx) only. RFC 3078 specifies that for initial session keys, peer credentials are used. If certificates less than 1024 bits are used for authentication then the authentication will fail before MPPE comes into picture.

  • Anonymous
    January 01, 2003
    Rodolfo Giovanninetti: No, there is not a way to add exceptions for specific sites. You either block all keys of the specified size or not. Tony Fiore: Thanks for posting back the information from Brian Komar to this blog! Thanks for Brian Komar for the answer!

  • Anonymous
    January 01, 2003
    Questions and answers:

  1. Is this update targeting only RSA keys less than 1024 bits? Yes, only RSA keys are targeted.
  2. Will there be a KB article? Yes, one is planned and will go out with the update.
  3. If after installing the patch on a Microsoft CA, will the Web enrollment interface allow PKCS # 10 requests for certificates that use a key of 512-bit? Once the CA is patched, requests for certificates that are less than 1024 bits will fail.
  4. Will the 1023 bit keys that are issued by IBM’s WebSphere be affected by the update? No, those keys will not be blocked by the update.
  • Anonymous
    January 01, 2003
    Tony Larson: More information should be published today. I am preparing a second blog post. ppivanov: I don't follow your scenario. I would think that your browsers would build just fine with a 1024 bit cert on the SSL site. You will be able to override the setting using regedit, if it turns out that it does not work. I will be posting more about this in a second blog post - probably today. Muis: No. You need not worry about that because it is only affecting chain building. Frank Lesniak: Thanks. One step at a time. :-)

  • Anonymous
    January 01, 2003
    Isabelle Sanier: You do not require certutil in order for the blocking to happen or to mitigate. I just updated blog post part 2 to discuss registry paths & mitigations for systems that either do not have certutil or have older versions of certutil: blogs.technet.com/.../blocking-rsa-keys-less-than-1024-bits-part-2.aspx Steve Sipos & GPAV: I am still seeking a full answer from the responsible feature teams for your questions. ASP.NET & C# Developer: Not sure what specifically you want to know about affecting dlls. Did you see the follow-up blog post part 2? blogs.technet.com/.../blocking-rsa-keys-less-than-1024-bits-part-2.aspx If that does not answer your question, would you give me a more specific question to forward, please? If you want, please, use "Email blog author" to contact me. BlackKnights: The patch will block <1024 bit RSA key certificates, especially when accessing web sites. I have done testing with IE8, IE9, and IE10 - all produce different looking error messages and they prevent you from entering a web site with an RSA key of <1024 bits. If you need more follow-up, please, try to contact me through the blog using "Email blog author."

  • Anonymous
    January 01, 2003
    GPAV: Anytime an SSL certificate with key < 1024 bits is verified, there will be blocking. Here is a bit more from the answer I received: If the mail server verifies client certs to authenticate clients (standard SSL client authentication), it will be affected. If clients use passwords to access the server, then SSL client authentication isn’t involved. If the mail server verifies its own cert, it will be affected. Clients verifying the SSL server cert will be affected (standard SSL server authentication).

  • Anonymous
    January 01, 2003
    Will this patch BLOCK the access to sites using less than 1024 bit key or display the error message only?

  • Anonymous
    January 01, 2003
    In one of the response you stated -- 4. Will the 1023 bit keys that are issued by IBM’s WebSphere be affected by the update? No, those keys will not be blocked by the update. The 1023 key cert on UNIX system will not be blocked, but for the Windows platform (with Aug 14 patch deployed) to access the site using this cert should also be affected, correct?

  • Anonymous
    January 01, 2003

  1. I'm interesting in doing/using Event Forwarding to forward CAPI2 events to a central server. I'm already familiar with event forwarding and using it to forward from security, application and other logs. When I try to forward from the CAPI2 log the forwarder returns an error. I started with the Machine Account but even tried my domain admin account and the forwarder says 'no active channel is available'
  2. Just a comment: You can enable the capi2 log by a registry or GP update also. Set the following key to a value of 1.  HKLMSOFTWAREMicrosoftWindowsCurrentVersionWINEVTChannelsMicrosoft-Windows-CAPI2/OperationalEnable
  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    January 01, 2003
    The Part 2 of this blog post is now ready at: blogs.technet.com/.../blocking-rsa-keys-less-than-1024-bits-part-2.aspx

  • Anonymous
    January 01, 2003
    The SELFCERT.EXE from the office will generate only certificat with 512 Bit. So every VBA developper can't use SELFCERT.EXE the generate a developer certificat . Will Microsoft update SELFCERT.EXE in the near future?

  • Anonymous
    January 01, 2003
    Jose Gonzalez: Yes, MD5 will continue to work. Isabelle Sanier: Yes, the application will continue to work once installed. See also blog post 2 blogs.technet.com/.../blocking-rsa-keys-less-than-1024-bits-part-2.aspx

  • Anonymous
    January 01, 2003
    Poes: Yes, you can still retrieve smaller key sizes. As I mentioned in several other comments and in the article itself, this update is only targeted to affect chain building.

  • Anonymous
    January 01, 2003
    We have a website which requires client certificates in ssl negotiation and for signing docs with capicom. All client certs were issued by a certe authority with 512 rsa pub key.  Although signing will probably work we are worried clients will not be able to log into the website after the update is pushed because their browsers will not build a trust chain. We can reissue the CA root cert but do we have to reissue all client certificates as well?

  • Anonymous
    January 01, 2003
    Fixed the command. It should have included a space in the syntax (as shown in the figure). Thanks for reporting. As for the other comment about us considering the length of keys, we have done extensive testing on this and continue to do so. We will be posting an article in the future that will explain more, including troubleshooting steps and modifications to the settings. This posting is just an informational post about what is coming in the future. There will be more information and steps presented in the future as well.

  • Anonymous
    January 01, 2003
    Steve Sipos: An answer came back from the TMG team: certificates for TMG use 2048 bit key lengths, by default. Unless customers have specifically modified the default length, the update should not affect TMG.

  • Anonymous
    January 01, 2003
    You may also want to mention the fine script that was dropped on the gallery by Tim Springston gallery.technet.microsoft.com/.../Weak-RSA-Key-Certificate-189c51e9

  • Anonymous
    January 01, 2003
    Kai Rohrbacher - When the update comes out, you will be able be modify how it works through the registry modifications. For example, you will be able to set 512 as minimum or set the system to only log issues - not block them. We have another blog post to discuss these settings planned as well as a TechNet Wiki article planned to describe how to identify and resolve issues with the update.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Andreas: Please, see blog post 3 (blogs.technet.com/.../blocking-rsa-keys-less-than-1024-bits-part-3.aspx), which explains what is going on. In short, the update was posted to the download center - not on Windows Update yet! The plan is to put it on Windows Update in October. Jeffrey S. Patton: Good idea. Thank you!

  • Anonymous
    January 01, 2003
    Joey: Sorry about the delay. After checking with some people internally, the answer is: No, there is no simple way to do this from the scanning side. You can do it from the issuing side, as discussed in the blog article by looking at templates and CAPI2 logging. Otherwise, you have to know where the applications store their certificates and that may vary on an application-by-application basis

  • Anonymous
    January 01, 2003
    Is there any way to add exceptions to this? For example, I have an internals server with a software that uses a 512 bits certificate to access the dashboard/console. To be able to work with it I have to disable the minimum level of 1024 bits on my workstation and to allow any key length. But in this way when I go to internet I can go to a site that has a weak certificate and still believe that it is strong, because it is not rejected. Instead, I would like to be able to say keep the limit of 1024 bits, but add an exception for this INTERNAL site, for which 512 bits are ok. Is it possible? Thank You and regards Rodolfo Giovanninetti

  • Anonymous
    January 01, 2003
    jbourdet23, Would you please post the technical issue regarding the forwarding of CAPI2 logs to the Security forum (social.technet.microsoft.com/.../threads)?

  • Anonymous
    June 12, 2012
    I strongly hope you are taking under consideration in this update that some '1024' keys are actually 1023 or 1022 bits long keys. Or you will run into very serious problems with it.

  • Anonymous
    June 13, 2012
    Please delete a "[" character from findstr "[msPKI-Minimal-Key-Size"

  • Anonymous
    June 25, 2012
    Will there be the chance to intentionally delete / uninstall the respective MS patch? (=as a work-around in case that customer systems will not be able to be updated till August)

  • Anonymous
    June 27, 2012
    How will this affect the Secure ID RSA tokens?

  • Anonymous
    July 11, 2012
    Is the update one of the updates that Microsoft releases with the security patches every month? And will the patch be downloaded though Windows update? When will there be more information about the update and the modifications of it?

  • Anonymous
    July 11, 2012
    If you are using certificates with one of the three CSP listed above, but you are using keys like 1024bit or longer, will there be any issues then? Is Microsoft working with these CSP to change the default behavior or to delete the CSPs? It seems strange having them as available CSP if Microsoft dosnt changes the CSPs.

  • Anonymous
    July 13, 2012
    Will this update also affect .Sign/.Verify operations using the RSACryptoServiceProvider class?

  • Anonymous
    July 13, 2012
    Umm... while you're at it, do yourself a favor and go up to at least 2048 bit RSA. 1024 bit RSA is pretty much deprecated and should not be rolled out as of Jan 1 2011. See http://www.keylength.com/ or NIST recommendations for key length

  • Anonymous
    July 14, 2012
    Does it still allow my software to store and retrieve smaller keysizes from the Machine Key Store?

  • Anonymous
    July 18, 2012
    ppivanov: The cost to break a 512 bit key in a week is less than $150 on EC2, I hope you're not protecting anything worth more than that.

  • Anonymous
    July 19, 2012
    What about certificares 1024 but MD5 ?  They will be affected?  Can we still using its?

  • Anonymous
    July 24, 2012
    Hello, I have an application that has been signed with a root authority of 512 bits after the 1st Jan. 2010. This application is working fine today. I understand I won't be able to install it anymore once the patch has been installed on a workstation. Anyhow will the currently installed version continue to work? Tyhanks for your help!

  • Anonymous
    July 24, 2012
    Thank you for taking time to answer. Just a quick clarification: will it work without the CertUtil application or am I forced to patch someone my workstation with CertUtil to have it running? Thanks again!

  • Anonymous
    July 25, 2012
    How will it affect internet access if installed on MS TMG server?

  • Anonymous
    July 25, 2012
    How will this effect mail server using SSL Cert

  • Anonymous
    July 25, 2012
    Will this effect dlls in the GAC with less than 1024?

  • Anonymous
    August 02, 2012
    Thanks Kurt for the notification. Here is a base script in powershell to scan all exe, dll, and ocx files on a Windows system to determine if they are digitally signed and if the certificate used for the signature was less than 1024 bits. $Files = dir C:* -include .exe,.dll,*.ocx -r Foreach ($File in $Files)    {    #$File.FullName   Get-AuthenticodeSignature $File.FullName | Where-Object {$.Status -eq "Valid" -and $.SignerCertificate.PublicKey.Key.keysize -le 1023}    }

  • Anonymous
    August 03, 2012
    We have thousends of application servers which has local intranet websites. Is there a simple way to scan all those servers from out of an serverlist? I checked the certutil but couldnt find anything to remotly scan an server.

  • Anonymous
    August 08, 2012
    The comment has been removed

  • Anonymous
    August 12, 2012
    did MS give it up or postpone? I can't find kb or security advisory 2661254 and we are 2 days away from the deadly tuesday patch...

  • Anonymous
    August 13, 2012
    We believe we have servers that will be affected by this patch.  However, they are running Windows Server 2003 R2.  There is no "HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CertDllCreateCertificateChainEngine" key.   The following command (Certutil -dstemplate | findstr "[ msPKI-Minimal-Key-Size"| findstr /v "1024 2048 4096") only returns '[Version]'.  Is this patch only going to affect Certification Authorities?  How can I know for sure whether or not my servers will be affected?

  • Anonymous
    August 13, 2012
    I don't see the "HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CertDllCreateCertificateChainEngine" registry key on any of my servers.  Will this only appear after the update? Also, when I run the following command (Certutil -dstemplate | findstr "[ msPKI-Minimal-Key-Size"| findstr /v "1024 2048 4096"), I only get [Version] as a result.  Does this mean I'm safe?

  • Anonymous
    August 13, 2012
    The comment has been removed

  • Anonymous
    August 14, 2012
    Is 3DES impacted as well?

  • Anonymous
    August 14, 2012
    So is there a KB article for this?

  • Anonymous
    August 15, 2012
    We've gotten all the other updates to our SCCM SUP but this one isn't showing up. Not even after manually syncing and searching for all products.

  • Anonymous
    August 19, 2012
    Would like to know if a 512-bit SSL certificate installed web site in IIS can be startup after installed the patch ?

  • Anonymous
    October 20, 2012
    This article is very informative.  It saved me a lot of time.  The only problem is now instead of using sha1RSA as the Signature Algorithm it uses RSASSA-PSS which does not seem to work under Windows XP.  I re-issued some smart card using 2048-bit keys and they work on Vista,7 and 2008 but not under XP.  What can be done to get the cards to work under XP?

  • Anonymous
    October 27, 2012
    The comment has been removed

  • Anonymous
    October 30, 2012
    MVP Brian Komar found the solution! Here is his post: I think your server was setup to put the alternate signature algorithm in the certs it issues. Check it out by running certutil -getreg cacspalternatesignaturealgorithm If the value is 1, then you need to change it to 0 certutil -setreg cacspalternatesignaturealgorithm 0 Then restart certificate services Also, check the capolicy.inf file. If it has alternatesignaturealgorithm=1, then you will have to change it to alternatesignaturealgorithm=0 and renew the CA certificate

  • Anonymous
    November 15, 2012
    wrt Office selfcert.exe is making 1024 bit keys for me... but another option is to use makecert.exe -sk SelfSignedCerts -r -ss My -n "CN=CertificateName" -eku 1.3.6.1.5.5.7.3.3

  • Anonymous
    April 26, 2014
    Not application please support my phone 5130c-2

  • Anonymous
    July 31, 2015
    http://www.chotabheemgames.org//">Chota Bheem games : play Chota Bheem Games, new Chota Bheem online at ChotaBheemGames.org. Our site have all Chota Bheem Games for you

  • Anonymous
    July 31, 2015
    http://www.chotabheemgames.org//">Chota Bheem games : play Chota Bheem Games, new Chota Bheem online at ChotaBheemGames.org. Our site have all Chota Bheem Games for you

  • Anonymous
    November 06, 2015
    your posts and information's are very impressive.... Thanks for the support websphere Online Training
    http://hadooptraininginhyderabad.co.in/websphere-training-in-hyderabad/

  • Anonymous
    May 04, 2017
    hi,You shared such a great information and it is very useful for us i am feel like this article might be shared for me by u...........thank you............

  • Anonymous
    May 04, 2017
    usage of FSA keys under 1024 bit is nicely described ,thanks for sharing