2023 2024 EduVark > Education Discussion > General Discussion


  #1  
June 16th, 2016, 12:09 PM
Unregistered
Guest User
 
Openssl NID SHA1

Hi I am interested in having the details about the process to be used for the assignment of the NID SHA 1 in the open SSL system?
  #2  
June 16th, 2016, 12:57 PM
Super Moderator
 
Join Date: Mar 2013
Re: Openssl NID SHA1

NID_sha assigns SHA-0, the immediate predecessor of SHA-1. SHA-0 was initially called "SHA" however soon a changed form, called SHA-1, was distributed; the past "SHA" was then proclaimed out of date, and is presently customarily called "SHA-0". The real purpose behind the change was not made authority, but rather it was for the most part comprehended that SHA-0 had some kind of shortcoming - which was found by free scientists a couple of years after the fact, and used to deliver impacts. In this way, SHA-0 is "broken" (a great deal more than SHA-1) and you ought not utilize it.

For RSA marking with SHA-256 you ought to utilize NID_sha256 (for SHA-512, NID_sha512). In the event that you utilize NID_sha, then you misunderstand a mark. Inside, the marking procedure incorporates a change where the hash esteem (the m/m_len parameters to RSA_sign()) is cushioned with a header which distinguishes the hash capacity (which is the reason RSA_sign() must have admittance to this data, through its sort parameter). In the event that you utilize NID_sha then this header will say "this is a SHA-0 hashed worth, of length 32 bytes" which is doubly wrong: a SHA-0 hash esteem has length 20 bytes, not 32; and this is not a SHA-0 hashed esteem, but rather a SHA-256 hashed esteem.

So essentially your underwriter creates a mark which leaves from the authority RSA signature standard (PKCS#1). So your mark won't be unquestionable with a consistent verifier. In any case, your verifier likewise leaves from the standard, similarly: by utilizing NID_sha as parameter for RSA_verify(), you teach the verifier to expect a "SHA-0" header (and a 32-byte hash esteem). This discloses why things seem to work with your code: your verifier does precisely the same than your endorser, and the two blunders counterbalance.

As such, you are not marking with the genuine RSA, but rather a variation thereof, which, at first look, is no less secure than the authentic thing, yet at the same time distinctive and in this manner not interoperable. Possibly this is not an issue in your particular circumstance, but rather, by and large talking, for cryptographic operations, you ought to adhere to the letter of the standard (since security shortcomings are unpretentious things). In the event that you utilize NID_sha256 when you sign a SHA-256 hash esteem, then you get a standard-acclimating PKCS#1 v1.5 RSA signature, and that is greatly improved.

To total up: overlook NID_sha, use NID_sha256 if the hash esteem originates from SHA-256 (NID_sha512 for SHA-512), both for RSA_sign() and RSA_verify().


Quick Reply
Your Username: Click here to log in

Message:
Options



All times are GMT +5. The time now is 04:40 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.6.0

1 2 3 4 5 6 7 8