On the samples page: http://phpseclib.sourceforge.net/x509/guide.html there is a sample "Example: CA-signed cert" I have been playing with it, but whatever I do, I only get sha1 signatures. I tried to setHash('sha256'), but no luck. How can this sample code generate sha256 signatures?
Thanks!
$x509->sign($issuer, $subject, 'sha256WithRSAEncryption');
The $issuer private key needs to be an instance of RSA for that to work but that's how you'd do it.
It probably ignores the setHash('sha256') thing because (1) not all the hashes you can use with RSA have OIDs that X509.php knows about and (2) options available in RSA - like PSS signatures - aren't supported by X509.php and may not have OIDs defined by any IETF RFC and may not be supported by another other X509 implementation out there.
Related
I'm familiar with CryptoKit and the SHA512 implementation, which is super easy to use.
let digest = SHA512.hash(data: Data("".utf8))
However, I can't seem to find how to compute SHA512/256 (the truncated version of SHA512) anywhere in the Apple CryptoKit documentation. Do I somehow have to combine SHA512 with SHA256Digest?
I think this pod will do the trick.
This has the implementation for SHA512/SHA256. (Check readme's HASH section: SHA-2)
Link: SHA512/SHA256 Lead
I am trying to decrypt a string which has been encrypted in my rails project. This is how I am encrypting the data:
def encrypt_text(text_To_encrypt)
# 0. generate the key using command openssl rand -hex 16 on linux machines
# 1. Read the secret from config
# 2. Read the salt from config
# 3. Encrypt the data
# 4. return the encypted data
# Ref: http://www.monkeyandcrow.com/blog/reading_rails_how_does_message_encryptor_work/
secret = Rails.configuration.miscconfig['encryption_key']
salt = Rails.configuration.miscconfig['encryption_salt']
key = ActiveSupport::KeyGenerator.new(secret).generate_key(salt, 32)
crypt = ActiveSupport::MessageEncryptor.new(key)
encrypted_data = crypt.encrypt_and_sign(text_To_encrypt)
encrypted_data
end
Now the issue is I am not able to decrypt it using openssl. It just shows bad magic number. Once I do that in open ssl, my plan is to decrypt it in golang.
Here is how I tried to descrypt it using openssl:
openssl enc -d -aes-256-cbc -salt -in encrypted.txt -out decrypted.txt -d -pass pass:<the key given in rails> -a
This just shows bad magic number
Trying to decrypt data encrypted in a different system will not work unless you are aware and deal with the many intricate details of how both systems do the cryptography. Although both Rails and the openssl command line tool use the OpenSSL libraries under the hood for their crypto operations, they both use it in their own distinct ways that are not directly interoperable.
If you look close to the two systems, you'll see that for example:
Rails message encryptor not only encrypts the message but also signs it
Rails encryptor uses Marshal to serialize the input data
the openssl enc tool expects the encrypted data in a distinct file format with a Salted__<salt> header (this is why you get the bad magic number message from openssl)
the openssl tool must be properly configured to use the same ciphers as Rails encryptor and key generator, as openssl defaults are different from Rails defaults
the default ciphers configuration changed significantly since Rails 5.2.
With this general info, we can have a look at a a practical example. It is tested in Rails 4.2 but should work equally up to Rails 5.1.
Anatomy of a Rails-encrypted message
Let me start with a slightly amended code that you presented. The only changes there are to preset the password and salt to static values and print a lot of debug info:
def encrypt_text(text_to_encrypt)
password = "password" # the password to derive the key
salt = "saltsalt" # salt must be 8 bytes
key = ActiveSupport::KeyGenerator.new(password).generate_key(salt, 32)
puts "salt (hexa) = #{salt.unpack('H*').first}" # print the saltin HEX
puts "key (hexa) = #{key.unpack('H*').first}" # print the generated key in HEX
crypt = ActiveSupport::MessageEncryptor.new(key)
output = crypt.encrypt_and_sign(text_to_encrypt)
puts "output (base64) = #{output}"
output
end
encrypt_text("secret text")
When you run this, you'll get something like the following output:
salt (hexa) = 73616c7473616c74
key (hexa) = 196827b250431e911310f5dbc82d395782837b7ae56230dce24e497cf07b6518
output (base64) = SGRTUXYxRys1N1haVWNpVWxxWTdCMHlyMk15SnQ0dWFBOCt3Z0djWVdBZz0tLTkrd1hBNWJMVm9HcnptZ3loOG1mNHc9PQ==--80d091e8799776113b2c0efd1bf75b344bf39994
The last line (output of the encrypt_and_sign method) is a combination of two parts separated by -- (see source):
the encrypted message (Base64-encoded) and
the message signature (Base64-encoded).
The signature is not important for encryption so let's take a look in the first part - let's decode it in Rails console:
> Base64.strict_decode64("SGRTUXYxRys1N1haVWNpVWxxWTdCMHlyMk15SnQ0dWFBOCt3Z0djWVdBZz0tLTkrd1hBNWJMVm9HcnptZ3loOG1mNHc9PQ==")
=> "HdSQv1G+57XZUciUlqY7B0yr2MyJt4uaA8+wgGcYWAg=--9+wXA5bLVoGrzmgyh8mf4w=="
You can see that the decoded message again consists of two Base64-encoded parts separated by -- (see source):
the encrypted message itself
the initialization vector used in the encryption
Rails message encryptor uses the aes-256-cbc cipher by default (note that this has changed since Rails 5.2). This cipher needs an initialization vector, which is randomly generated by Rails and must be present in the encrypted output so that we can use it together with the key to decipher the message.
Moreover, Rails does not encrypt the input data as a simple plain text, but rather a serialized version of the data, using the Marshal serializer by default (source). If we decrypted such serialized value with openssl, we would still get a slightly garbled (serialized) version of the initial plain text data. That's why it will be more appropriate to disable serialization while encrypting the data in Rails. This can be done by passing a parameter to the encryption method:
# crypt = ActiveSupport::MessageEncryptor.new(key)
crypt = ActiveSupport::MessageEncryptor.new(key, serializer: ActiveSupport::MessageEncryptor::NullSerializer)
A re-run of the code yields output that is slightly shorter than the previous version, because the encrypted data has not been serialized now:
salt (hexa) = 73616c7473616c74
key (hexa) = 196827b250431e911310f5dbc82d395782837b7ae56230dce24e497cf07b6518
output (base64) = SUlIWFBjSXRUc0JodEMzLzhXckJzUT09LS1oZGtPV1ZRc2I5Wi8zOG01dFNOdVdBPT0=--58bbaf983fd20459062df8b6c59eb470311cbca9
Finally, we must find out some info about the encryption key derivation procedure. The source tells us that the KeyGenerator uses the pbkdf2_hmac_sha1 algorithm with 2**16 = 65536 iterations to derive the key from the password / secret.
Anatomy of an openssl encrypted message
Now, a similar investigation is needed on the openssl side to learn the details of its decryption process. First, if you encrypt anything using the openssl enc tool, you will find out that the output has a distinct format:
Salted__<salt><encrypted_message>
It begins with the Salted__ magic string, then followed by the salt (in hex form) and finally followed by the encrypted data. To be able to decrypt any data using this tool, we must get our encrypted data into the same format.
The openssl tool uses the EVP_BytesToKey (see source) to derive the key by default but can be configured to use the pbkdf2_hmac_sha1 algorithm using the -pbkdf2 and -md sha1 options. The number of iterations can be set using the -iter option.
How to decrypt Rails-encrypted message in openssl
So, finally we have enough information to actually try to decrypt a Rails-encrypted message in openssl.
First we must decode the first part of the Rails-encrypted output again to get the encrypted data and the initialization vector:
> Base64.strict_decode64("SUlIWFBjSXRUc0JodEMzLzhXckJzUT09LS1oZGtPV1ZRc2I5Wi8zOG01dFNOdVdBPT0=")
=> "IIHXPcItTsBhtC3/8WrBsQ==--hdkOWVQsb9Z/38m5tSNuWA=="
Now let's take the IV (the second part) and convert it to a hexa string form, as that is the form that openssl needs:
> Base64.strict_decode64("hdkOWVQsb9Z/38m5tSNuWA==").unpack("H*").first
=> "85d90e59542c6fd67fdfc9b9b5236e58" # the initialization vector in hex form
Now we need to take the Rails-encrypted data and convert it to the format that openssl will recognize, i.e. prepend it with the magic string and salt and Base64-encode it again:
> Base64.strict_encode64("Salted__" + "saltsalt" + Base64.strict_decode64("IIHXPcItTsBhtC3/8WrBsQ=="))
=> "U2FsdGVkX19zYWx0c2FsdCCB1z3CLU7AYbQt//FqwbE=" # encrypted data suitable for openssl
Finally, we can construct the openssl command to decrypt the data:
$ echo "U2FsdGVkX19zYWx0c2FsdCCB1z3CLU7AYbQt//FqwbE=" |
> openssl enc -aes-256-cbc -d -iv 85d90e59542c6fd67fdfc9b9b5236e58 \
> -pass pass:password -pbkdf2 -iter 65536 -md sha1 -a
secret text
And voilá, we successfully decrypted the initial message!
The openssl parameters are as follows:
-aes-256-cbc sets the same cipher as Rails uses for encryption
-d stands for decryption
-iv passes the initialization vector in the hex string form
-pass pass:password sets the password used to derive the encryption key to "password"
-pbkdf2 and -md sha1 set the same key derivation algorithm as is used by Rails (pbkdf2_hmac_sha1)
-iter 65536 sets the same number of iterations for key derivation as was done in Rails
-a allows to work with Base64-encoded encrypted data - no need to handle raw bytes in files
By default openssl reads from STDIN, so we simply pass the encrypted data (in proper format) to openssl using echo.
debugging
In case you hit any problems when decrypting with openssl, it is useful to add the -P parameter to the command line, which outputs debugging info about the cipher / key parameters:
$ echo ... | openssl ... -P
salt=73616C7473616C74
key=196827B250431E911310F5DBC82D395782837B7AE56230DCE24E497CF07B6518
iv =85D90E59542C6FD67FDFC9B9B5236E58
The salt, key, and iv values must correspond to the debugging values printed by the original code in the encrypt_text method printed above. If they are different, you know you are doing something wrong...
Now, I guess you can expect similar problems when trying to decrypt the message in go but I think you have some good pointers now to start.
I'm limiting the ciphers that my webservice allows to only these TLS 1.x ciphers:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
Update in response to Dave Thompson's comment:
I now take the ciphers generated from this SO answer, in that order.
Because we currently use Delphi XE2/Indy 10.5.8.0/OpenSSL 1.0.2f I leave out the ECDHE ciphers, these are too cumbersome to implement with these software versions.
Also, we still allow TLS 1.0.
After the update to Delphi Seattle 10 we'll disallow TLS 1.0 and put the ECDHE ciphers back in.
This leaves:
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc15)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0xc4)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
Converted to OpenSSL names (according to Mapping OpenSSL cipher suite names to RFC names) these are:
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-SHA256
- cannot find the equivalent for 0xc4 - anyone? -
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-RSA-CAMELLIA128-SHA256
The order in which a server offers ciphers is important, but do I have control over this order? The CipherList is a string property containing these names concatenated with '+':
TIdServerIOHandlerSSLOpenSSL.SSLOptions.CipherList := 'DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SH:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA256';
If so, what is the recommended order?
Note that, since my webservice is the server, I have set SSLOptions.Mode := sslmServer.
* These are the ones that the nmap script ssl-enum-ciphers grades with an 'A'
Is the order of cipher names in TIdServerIOHandlerSSLOpenSSL.SSLOptions.CipherList important?
Mostly Yes.
TLS does not specify who decides on the cipher. Conventionally, the server honors the client's preference. That is, the server will use the client's first preference if its available and enabled, or the client's second preference if its available and enabled, and so on.
Most libraries allow a server to override the behavior. For example, with OpenSSL, SSL_OP_CIPHER_SERVER_PREFERENCE option. In this case, the server will match the server's first preference if the client advertises it, the server's second preference if the client advertises it, and so on.
For servers I control, I tune the cipher suite list and usually set SSL_OP_CIPHER_SERVER_PREFERENCE because many clients don't pay attention to the details. They just throw the soup of cipher suites in the ClientHello hoping something sticks.
The order in which a server offers ciphers is important, but do I have control over this order?
Yes.
At the server, determine your order of cipher suites, and then set them with SSL_CTX_set_cipher_list or SSL_set_cipher_list. By setting the list, you ensure RC4-MD5 is not used even its the client's first choice (presuming you omit it). For maximum impact, also set SSL_OP_CIPHER_SERVER_PREFERENCE context option.
Also see How do I disable a particular cipher suite in openssl? The context is OpenSSL, but it should give you an idea of where to go in Delphi.
(Comments): What's not clear to me from your answer: Does the CipherList property already signify an order? If I look at the underlying Delphi/Indy code I see that it is just a wrapper for external function SSL_CTX_set_cipher_list : function(_para1: PSSL_CTX; const str: PAnsiChar): TIdC_INT cdecl = nil; in IdSSLOpenSSLHeaders.pas
If I am understanding Delphi properly, then I believe the answer is Yes, it does. But its probably using either (1) OpenSSL's default list, or (2) a Delphi default list. Both are probably something like "ALL:!EXP:!LOW" or similar. In either case, you will want to tune it to suite your taste.
If you are interested in what the list looks like when its put on the wire, use Wireshark to inspect the ClientHello. Its easy to generate one with s_client, and it shows you what OpenSSL's default cipher suite list looks like:
$ openssl s_client -connect www.ietf.org:443 -tls1 -servername www.ietf.org
And the corresponding Wireshark trace with 55 default cipher suites stuffed into it:
You can also improve your security posture and reduce the number of cipher suites with the -cipher option and "HIGH:!aNULL:!MD5:!RC4". The cipher suite count will be reduced to about 35.
$ openssl s_client -connect www.ietf.org:443 -tls1 -servername www.ietf.org \
-cipher 'HIGH:!aNULL:!MD5:!RC4'
If you don't like TripleDES and Cameilla, then you can reduce it to about 20 cipher suites with:
$ openssl s_client -connect www.ietf.org:443 -tls1 -servername www.ietf.org \
-cipher 'HIGH:!aNULL:!MD5:!RC4:!3DES:!CAMELLIA'
Now, suppose a client is configured with only RC4-MD5 and a server is configured with only AES-GCM. I.e., there's no intersection of cipher suites between client and server. In this case, you will get an error in OpenSSL. The error will be 0x1408A0C1, "no shared cipher suites". It will look something like this at the server:
140339533272744:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353
For OpenSSL-based clients and server, you can determine the default cipher suite list with the "DEFAULT" string. That's literally what its called (check the ciphers(1) man page).
There's 103 of them, which includes weak and wounded algorithms. In practice, you want to pair it down to 16 or so cipher suites you feel comfortable using (i.e., your security posture):
$ openssl ciphers -v 'DEFAULT' | cut -f 1 -d " " | wc -l
103
And:
$ openssl ciphers -v 'DEFAULT' | cut -f 1 -d " "
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
SRP-DSS-AES-256-CBC-SHA
SRP-RSA-AES-256-CBC-SHA
SRP-AES-256-CBC-SHA
DH-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DH-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DH-RSA-AES256-SHA256
DH-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DH-RSA-AES256-SHA
DH-DSS-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
DH-RSA-CAMELLIA256-SHA
DH-DSS-CAMELLIA256-SHA
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA256-SHA
PSK-AES256-CBC-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
SRP-DSS-AES-128-CBC-SHA
SRP-RSA-AES-128-CBC-SHA
SRP-AES-128-CBC-SHA
DH-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DH-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DH-RSA-AES128-SHA256
DH-DSS-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DH-RSA-AES128-SHA
DH-DSS-AES128-SHA
DHE-RSA-SEED-SHA
DHE-DSS-SEED-SHA
DH-RSA-SEED-SHA
DH-DSS-SEED-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
DH-RSA-CAMELLIA128-SHA
DH-DSS-CAMELLIA128-SHA
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
SEED-SHA
CAMELLIA128-SHA
IDEA-CBC-SHA
PSK-AES128-CBC-SHA
ECDHE-RSA-RC4-SHA
ECDHE-ECDSA-RC4-SHA
ECDH-RSA-RC4-SHA
ECDH-ECDSA-RC4-SHA
RC4-SHA
RC4-MD5
PSK-RC4-SHA
ECDHE-RSA-DES-CBC3-SHA
ECDHE-ECDSA-DES-CBC3-SHA
SRP-DSS-3DES-EDE-CBC-SHA
SRP-RSA-3DES-EDE-CBC-SHA
SRP-3DES-EDE-CBC-SHA
EDH-RSA-DES-CBC3-SHA
EDH-DSS-DES-CBC3-SHA
DH-RSA-DES-CBC3-SHA
DH-DSS-DES-CBC3-SHA
ECDH-RSA-DES-CBC3-SHA
ECDH-ECDSA-DES-CBC3-SHA
DES-CBC3-SHA
PSK-3DES-EDE-CBC-SHA
EDH-RSA-DES-CBC-SHA
EDH-DSS-DES-CBC-SHA
DH-RSA-DES-CBC-SHA
DH-DSS-DES-CBC-SHA
DES-CBC-SHA
Meta: not an answer to the question but response to comment. To 'really understand' SSL/TLS isn't really programming and is a big question that may be 'too broad' for SO. But some thoughts anyway:
The definitive guide to SSL/TLS as a standardized protocol, or really family of them, is of course the RFCs that define them, plus where applicable the external standards referenced by those RFCs (like FIPS 197 for AES, PKCS#1 for RSA, SECG1 for ECC, etc). Wikipedia has a good overview and (AFAICT) complete list of references.
If you just want a general understanding of what the pieces are and how they work (like RSA vs DHE vs ECDHE, and AES vs TDES or HMAC vs AEAD) Wikipedia is also good, and so is the canonical Q&As on security.SE
A middle gound might be Ivan Ristic's new 'Bulletproof' book; he's the guy behind the widely-used and well-regarded SSLLabs test and the book is linked from that homepage. I haven't read the actual book, but a few years ago he showed and discussed on his blog some of the material planned to go in the book and I thought that looked excellent.
Also, you are not implementing the standard directly; you are using an implementation that is a version of OpenSSL, and in today's software ecosystem OpenSSL can vary. First OpenSSL itself has a number of build (aka compile-time) options. And I know of Delphi only in outline and I don't know if the OpenSSL version you identify is provided with or for Delphi (or Indy?) or 'pulled in' from the OS or elsewhere, and in any case who built it with what options and possibly even modifications (patches). (For comparison, I commonly use RedHat-based and Debian-based Linuxes that backport patches so that a package identified as for example '1.0.1e' is usually different, sometimes significantly so, from other versions that are also identified as '1.0.1e'.)
I have encrypted a PIN block under a TPK (clear)
When I am going to translation my PIN block from encryption under TPK to encryption under ZPK given from client on real HSM then it is giving me either error code 24 or 20.
What can i do to resolve my issue ? I have tried many ways but it is not getting resolved.
Translation command I am using is CA - Translate a PIN from TPK to ZPK/BDK (3-DES DUKPT) Encryption.
Al these my operations working beautifully with thales HSM simulator.
Errors you are getting are:
Error 20:PIN block does not contain valid values
Error 24:PIN is fewer than 4 or more than 12 digits in length
You said that you have clear TPK, but you can't do anything with clear keys on HSM. You have to import key and get key under LMK for any command.
You also have to import this key as TPK key in HSM to use CA command. You can also import it as ZPK, but than you should use CC command.
I am using OpenSSL in iOS app to sign a message. I use RSA_sign to sign. When I use RSA_verify to verify the signature, result is like this
050 +(f2d7846a5f495a743e470663facf7a2858d052cf
Where f2d7846a5f495a743e470663facf7a2858d052cf is the original signature. So I am getting additional 050 +( at the beginning of the signature. Can anyone please tell me the reason of this?
This is how I am signing
int sign = RSA_sign(NID_sha1,( char *)reply, strlen(reply), signature, &siglen, myRSA );
where reply contains sha1 hashed data to be signed.
Best Regards
I'm very surprised that you see anything other than the original signature in the buffer. RSA_verify is not supposed to "return" anything other than the result of the verification (in the returned integer value, 0 for failure, 1 for success. Please use the methods as defined in the SSL documentation.
In my opinion it is a bug that you can see the hash in the first place. Unfortunately OpenSSL is not very well documented.