> I am extracting raw digest by using then below command.
>
> /* decrypt the content using the RSA pub key */
> elen = RSA_public_decrypt(sLen, sData, ebuf, rsaKey, RSA_PKCS1_PADDING);
>
> /* comuptes SHA1 hash*/
> SHA1_Init(&ctx);
> SHA1_Update(&ctx, dataBlk, dataLen);
> SHA1_Final(hash, &ctx);
Hi Stephen,
I am extracting raw digest by using then below command.
/* decrypt the content using the RSA pub key */
elen = RSA_public_decrypt(sLen, sData, ebuf, rsaKey, RSA_PKCS1_PADDING);
/* comuptes SHA1 hash*/
SHA1_Init(&ctx);
SHA1_Update(&ctx, dataBlk, dataLen);
SHA1_Final(hash, &ctx);
/
On Wed, Nov 12, 2014, Sheldon Hearn wrote:
> Hmmm, looking at your suggestion more closely, there's more to it than
> that. When the client holds nothing but the symmetric key used to
> produce the ciphertext, I think it needs an Encrypted-Data, not an
> Enveloped-Data. The CMS_encrypt(3) function
Hello All,
I have a program on Windows that, among tohers things, access databases
through ODBC and computes sha1 values from files.
OpenSSL functions are accessed through a DLL and do initialisation when
it needs to. My program uses release OpenSSL 0.9.8 DLLs
The used database is a PostgreSQL
On Wed, Nov 12, 2014, Gayathri Manoj wrote:
> Hi Steve,
>
> Conclusion of previous thread : For making FIPS compliance we have to
> replace RSA_public_decrypt() with EVP_verify*() APIs. It requires hash of
> the the entire message and not the hash of the 'signed message'.
>
> Currently I am g
On Wed, Nov 12, 2014, Sheldon Hearn wrote:
> I'm building a secret store, kinda like LastPass for services, where
> developers encrypt application secrets and place the ciphertext in the
> store, and then applications fetch the ciphertext and decrypt the secrets
> using a key that they were given
On Wed, Nov 12, 2014, Tristan Hill wrote:
> Hi,
>
> Is it possible to make s_client give more detail about the client
> hello it sends. A break down covering the RFC structure would be
> useful.
>
> struct {
> ProtocolVersion client_version;
> Random random;
>
Took me a while to see, but the difference is in the last line of the client
hello. Your working example has MD5+RSA listed as a TLS 1.2 signature pair
whereas first doesn't.
0302 SHA-224 DSA
0303 SHA-224 ECDSA
0201 SHA-1 RSA
0202 SHA-1 DSA
0203 SHA-1 ECDSA
000F TLS_DH_RSA_WITH_DES_CBC_SHA
0101
Hi,
Is it possible to make s_client give more detail about the client
hello it sends. A break down covering the RFC structure would be
useful.
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2
Thanks for the suggestion, Matt. As far as I know, ruby's openssl
bindings don't expose CMS_encrypt. :-(
On Wed, Nov 12, 2014 at 11:25 AM, Matt Caswell wrote:
>
>
> On 12/11/14 09:07, Sheldon Hearn wrote:
>> The AES-IV is present, but the ciphertext is not. I've boiled the ruby
>> code down for t
Hmmm, looking at your suggestion more closely, there's more to it than
that. When the client holds nothing but the symmetric key used to
produce the ciphertext, I think it needs an Encrypted-Data, not an
Enveloped-Data. The CMS_encrypt(3) function produces an
Enveloped-Data.
On Wed, Nov 12, 2014 a
On 12/11/14 09:07, Sheldon Hearn wrote:
> The AES-IV is present, but the ciphertext is not. I've boiled the ruby
> code down for the purposes of asking this question:
>
> #>>>
>
> require 'openssl'
>
> cleartext = "The cake is a lie!"
>
> cipher = OpenSSL::Cipher::AES256.n
I'm building a secret store, kinda like LastPass for services, where
developers encrypt application secrets and place the ciphertext in the
store, and then applications fetch the ciphertext and decrypt the secrets
using a key that they were given by the runtime environment.
This moves the problem
13 matches
Mail list logo
