On Wed, 2012-09-12 at 00:28 +0300, farmdve data.bg wrote:
> I have seen a lot of applications that utilize the OpenSSL library,
> however I see that the majority of the documentation is incomplete.
>
>
> In particular, I need some documentation for the EC package in the
> 'crypto' sub-folder, I m
You should just be able to create an ECDSA_SIG structure using:
ECDSA_SIG *mysig;
if(!(mysig = ECDSA_SIG_new())) goto err;
And then simply copy your r and s values directly into the ECDSA_SIG
structure (assuming they are BIGNUMs):
if(!BN_copy(mysig->r, r)) goto err;
if(!BN_copy(mysig->s, s)) go
With PKCS padding there is always between 1 and 16 padding bytes added (for
AES). The value of the padding bytes is equal to the number of padding
bytes added, so if one padding byte has been added then the value "0x01"
will be added, for two padding bytes then "0x0202" will be added, for three
"0x
Yes, you can use CTR mode for AES-256: use the EVP interface with the
EVP_CIPHER of EVP_aes_256_ctr().
However it is a fundamental requirement of CTR mode that the IV must be
unique across messages. If you reuse the IV then your messages can be
broken quite trivially. Therefore, if by a fixed IV,
t; On Mon, Jan 14, 2013 at 12:22 PM, Matt Caswell wrote:
>
>> Yes, you can use CTR mode for AES-256: use the EVP interface with the
>> EVP_CIPHER of EVP_aes_256_ctr().
>>
>> However it is a fundamental requirement of CTR mode that the IV must be
>> unique across mes
tion for all the modes supported by openssl??
>
> Regards,
> Rohit Bansal
>
>
> On Mon, Jan 14, 2013 at 1:16 PM, Matt Caswell wrote:
>
>> The EVP API is documented here:
>> https://www.openssl.org/docs/crypto/EVP_EncryptInit.html#
>>
>> There is some e
I have previously submitted a largish patch for documentation around the
OpenSSL EC library. Unfortunately there seems little interest in it, and it
has been hanging around in RT for some while:
https://rt.openssl.org/Ticket/Display.html?id=2799 (username guest,
password guest)
This documentatio
It is a feature of GCM that the ciphertext (excluding the authentication
tag) is identical length to the plaintext. Therefore no padding is required.
Matt
On 8 February 2013 14:27, Dirk Menstermann wrote:
> Hi,
>
> I'm playing around with "EVP_aes_128_gcm". This works, but it seems that
> EVP_*
See the README for instructions, under the SUPPORT section:
http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=README;hb=refs/heads/master
Matt
On 6 March 2013 23:10, Dennis Clarke wrote:
> Is there a bugzilla site or similar for openssl ?
> __
On 6 March 2013 11:40, Dr. Stephen Henson wrote:
> On Wed, Mar 06, 2013, Matej Kenda wrote:
>
> >
> > I am working on a solution which includes encryption of files of
> arbitrary
> > size (at least up to 2 GB) to be encrypted with AES CCM with 256-bit key
> > and uploaded to a server.
> >
>
> CCM
On 16 March 2013 18:00, azhar jodatti wrote:
>
>
> Thompson,
>
> Really thanks for the reply. appreciate your time.
>
> Yes it was JCE and not JCF. it was typo :)
>
> I am working on application which has android and iPhone client. Both the
> client talk to my server which is written in JAVA. I
On 18 March 2013 12:15, azhar jodatti wrote:
> 2) Is this sample from the *same* key exchange? The parameters are
> different which are obviously going to cause it to fail.
> When I run both programs it calculates the params (p,g,pk) every time on
> execution . that's the reason both key values a
On 18 March 2013 15:05, azhar jodatti wrote:
>
> I also just noticed that in your JSON sample there is only one prime
> number provided. There are in fact two required: p and q.
> well, I think other prime number is g and not q. other prime number is
> base generator i.e g in above JSON sample.
>
On 18 March 2013 21:02, Dave Thompson wrote:
> >I also just noticed that in your JSON sample there is only one
> >prime number provided. There are in fact two required: p and q.
>
> No. *DSA* uses p,q,g. DH requires p,g which effectively determines
> q, but DH computation doesn't use q and standa
On 18 March 2013 21:44, Matt Caswell wrote:
> However, you are correct that the DH computation does not use q, although
> I do not
>
> know whether JCE requires it to be specified (not having used JCE).
>
> One other point on this - X9.42 describes an optional validation proced
On 19 March 2013 09:01, azhar jodatti wrote:
> And possibly relevant here, the standard Suncle JCE provider actually
> uses DSA paramgen for DH and thus imposes the DSA size restrictions
> on DH -- 512 to 1024 in steps of 64 -- although they aren't required
> by any standard I know of. I don't re
On 19 March 2013 10:37, azhar jodatti wrote:
>
>
> On Tue, Mar 19, 2013 at 2:58 PM, Matt Caswell wrote:
>>
>> On 19 March 2013 09:01, azhar jodatti wrote:
>>
>> > And possibly relevant here, the standard Suncle JCE provider actually
>> > uses DSA
On 19 March 2013 12:22, azhar jodatti wrote:
>PEM_write_bio_DHparams(out, temp);//this prints public key in base64
> (this is what i think :) )
This is NOT a base64 representation of the public key. This is
printing out the parameters only (which does not include the public
key)
>
On 19 March 2013 14:18, azhar jodatti wrote:
> On Tue, Mar 19, 2013 at 6:24 PM, Matt Caswell wrote:
>> On 19 March 2013 12:22, azhar jodatti wrote:
>> >PEM_write_bio_DHparams(out, temp);//this prints public key in
>> > base64
>> > (this is what i t
On 20 March 2013 07:37, azhar jodatti wrote:
>> Public key :
>> 510930286596310951521275475612102569543976030982320596660271226159732273824290276894393668009018948652558944129592742623399736587550878753266525193164086412911472101163507241794456000621904406552477307648348188701130736756595973501460
On 20 March 2013 11:25, azhar jodatti wrote:
> byte[] bobPubKeyEnc = bobKpair.getPublic().getEncoded();
This is providing an encoded form of the public key, whereas your code
is expecting it as an integer. Use the following instead:
DHPublicKey dhpubkey = (DHPublicKey)(bobKpair.getPublic());
Big
On 20 March 2013 19:21, azhar jodatti wrote:
> One more query :).
>
> After generating secret key :
> byte[] bobSharedSecret = bobKeyAgree.generateSecret();//this generates
> secret key. Note : this key matches with C client secret key :)
>
> I am doing below stuff in JAVA :
>SecretKeyFac
On 21 March 2013 21:04, steveRX04 wrote:
> I'm using DES so the cipher block size is 8 bytes. Padding is enabled.
DES? Really? Are you sure you want to use that? It is no longer
considered secure.
>
> I know that if the input buffer is 14 bytes, then by calling
> EVP_EncryptUpdate the first 8 b
See:
http://wiki.opensslfoundation.com/index.php/EVP
http://wiki.opensslfoundation.com/index.php/EVP_Symmetric_Encryption_and_Decryption
http://wiki.opensslfoundation.com/index.php/EVP_Authenticated_Encryption_and_Decryption
Matt
On 22 March 2013 19:15, Jevin Sonut wrote:
> Can anyone post a sa
On 26 March 2013 16:45, tos iro wrote:
> Hello
> I'm sorry when there is an impoliteness.
>
> I want you to tell me a *correct way to* call the EVP_CIPHER_CTX_cleanup().
>
> I'm writing the program for encrypt independent data one by one.
>
> Should I call EVP_CIPHER_CTX_cleanup() at each EVP_Encr
On 29 March 2013 15:09, Zach wrote:
> I'm trying to do the following:
> 1) Put a base64-encoded key (the normal one generated by openssl command
> line tools) into a header file
Do you mean to put the actual key itself hardcoded into the header
file?? This seems like a strange thing to do.
PEM f
On 1 April 2013 23:30, Zach wrote:
> RSA* x = PEM_read_bio_RSA_PUBKEY(bio, NULL, NULL, NULL);
>
Try using this instead:
PEM_read_bio_PUBKEY
Matt
Hi Jeff
Is FHMQV covered by any patents? I've always assumed that was the
reason MQV was not in OpenSSL.
Matt
On 22 January 2012 20:03, Jeffrey Walton wrote:
> Hi All,
>
> Is anyone interested in implementing FHMQV in OpenSSL?
>
> I recently implemented FHMQV in Crypto++ (hopefully the patch wi
On 15 April 2013 12:48, Anil Kumar K K wrote:
> Hi OpenSSL Team,
>
> I am Anil, trying to code aes encryption and decryption program using
> openssl library.
>
> I have coded a program which takes key and data as inputs and computes
> AES-128 cipher text and decrypt the same. If the size of the da
On 25 April 2013 21:42, Taraniteja Vishwanatha wrote:
> Hey guys,
>
> I was using the low level aes APIs and now have switched to EVP ones. My
Good. That is (in most cases) the correct approach.
> string encryption and decryption always work fine. But when it comes to
> files, I am getting mall
On 11 May 2013 05:05, Lunar Mushrooms wrote:
> Hello I can see a call to OBJ_bsearch_pmeth() in openssl source. By I could
> not find the definition of OBJ_bsearch_pmeth(). I greped the entire source.
> Can somebody help me to find the definition ?
>
> ./openssl-1.0.1d/crypto/evp/pmeth_lib.c:
On 15 May 2013 20:15, Bin Lu wrote:
> Hi,
>
> Could somebody tell me what names I should use in EVP_get_cipherbyname() to
> return the AES_128_GCM and AES_256_GCM ciphers? I looked into openssl code
> but got lost.
>
aes-128-gcm and aes-256-gcm
Matt
__
On 24 May 2013 03:21, wrote:
> Can one use HMAC through EVP? If so, can someone point me to an example?
>
> It seems that when the OpenSSL module is in FIPS mode, it doesn't like
> programs using HMAC_*() functions directly:
>
> "OpenSSL internal error, assertion failed: Low level API call to di
On 24 May 2013 05:45, Matt Caswell wrote:
> On 24 May 2013 03:21, wrote:
>> Can one use HMAC through EVP? If so, can someone point me to an example?
>>
>> It seems that when the OpenSSL module is in FIPS mode, it doesn't like
>> programs using HMAC_*() fu
On 31 May 2013 10:58, Jakob Bohm wrote:
> According to a server testing service I have tried, OpenSSL 0.9.8
> fails to reject degenerate ephemeral DH keys, while OpenSSL 1.0.0
> does this rejection. They do not provide a CVE number for this
> issue, and I cannot find it in the OpenSSL CHANGES fil
On 31 May 2013 16:42, Jakob Bohm wrote:
> Interesting, I don't seem to be able to find code that calls dh_check
> or equivalent on received DH group parameters, but then the check in
> that function is too strict in its criteria (for instance, some
> standards (such as X9.42 and NIST SP 800-56A) r
On 31 May 2013 21:07, Matt Caswell wrote:
> On 31 May 2013 16:42, Jakob Bohm wrote:
>> Interesting, I don't seem to be able to find code that calls dh_check
>> or equivalent on received DH group parameters, but then the check in
>> that function is too strict in its cr
On 12 June 2013 21:15, Jakob Bohm wrote:
>>>
As for the DH_check_pub_key() function, checking if pubkey is in the
range "two to large prime minus 2, inclusive" is an insufficient check
against accepting degenerate keys. For instance NIST SP 800-56A
requires the following check
On 14 June 2013 20:12, Steve Tarzia wrote:
> I am having some trouble finding documentation or examples showing how to
> perform Elliptic Curve crypto operations using the openssl command line
> tool. Is possible to perform EC encryption and decryption using the openssl
> command line tool?
>
> I
On 14 June 2013 01:55, Jakob Bohm wrote:
> On 6/12/2013 11:35 PM, Matt Caswell wrote:
>>
>> On 12 June 2013 21:15, Jakob Bohm wrote:
>>>>>
>>>>>
>>>>>> As for the DH_check_pub_key() function, checking if pubkey is in the
>>
On 16 June 2013 10:41, enrico d'urso wrote:
> Client send to Server encrypt data, first time all works fine, but second
> time no.
> For example if I first time send:
> "Stack Overflow" server print "Stack Overflow",
> but second time anything client sends, server always print "erflow".
> Note tha
On 17 June 2013 12:57, enrico d'urso wrote:
> Hi, thanks for your answer.
>
> I didn't call them all times, just first time.
> The fact is that I would like to use 'cbc' scheme, so I Could make this way,
CBC is a mode used within an individual message. It cannot be used
across multiple messages i
On 17 June 2013 13:25, Matt Caswell wrote:
>>
>> Take a random IV, and use it.
>> Encrypt a message, and save last cipher-text ( Let be C).
>> Re-call EncryptInit using C as IV.
>>
>
> IVs must be random and not predictable in advance. Using the last
> bloc
On 17 June 2013 14:02, enrico d'urso wrote:
> Hi, thanks for answer.
> At the moment in my application I create an random IV and a random KEY.
> Client after this creation send them to Server encrpyting all with RSA
> public key.
> Client decrypt the message with private key, and from this point t
On 17 June 2013 15:17, Jakob Bohm wrote:
>>
>> IV's should always be random - you should not reuse an IV.
>> Using the the last block of cipher-text from a previous message as the
>> IV gives a predictable IV which is insecure in CBC mode for certain
>> classes of attack.
>
>
> You are making the
On 18 June 2013 09:43, Michel wrote:
> Hi Yamini,
>
> I would suggest looking at the 'EVP Envelope' API :
> https://www.openssl.org/docs/crypto/EVP_SealInit.html
>
Also see:
http://wiki.openssl.org/index.php/EVP_Asymmetric_Encryption_and_Decryption_of_an_Envelope
Matt
__
On 18 June 2013 19:22, Jakob Bohm wrote:
> Fundamentally, every CBC block except the first will use what you call a
> "predictable" IV, namely the previous ciphertext block. To make any sense
> security arguments about this need to be very clear about what is
> and is not vulnerable.
Your clarif
Just to clarify, that should say the OpenSSL wiki is NOW available!
Matt
Steve Marquess wrote:
>The recently created OpenSSL Wiki is not available for general access
>at
>
> http://wiki.openssl.org/
>
>It is starting to accumulate some useful content and should continue to
>grow in the futur
On 16 August 2013 16:46, Swair Mehta wrote:
> On 16-Aug-2013, at 7:49 AM, Unga wrote:
>
>> Hi all
>>
>> I have a requirement to encrypt files, in such a way identical files should
>> generate identical ciphertexts.
>>
>> I plan to use aes-256-cbc cipher with 128-byte long non-guessable password
On 3 September 2013 15:16, Jonas Andersson wrote:
> Hi all,
>
> Is there a way to verify a signature with ECDSA_do_verify having only the
> x-coordinate (in public key) available?
Are you sure you *only* have the x-coord and not a point in compressed
format? The difference being that with compres
ice solution though.
Matt
> Br,
> Jonas
>
>
>
> 2013/9/3 Matt Caswell
>>
>> On 3 September 2013 15:16, Jonas Andersson
>> wrote:
>> > Hi all,
>> >
>> > Is there a way to verify a signature with ECDSA_do_verify having only
>> &g
On 18/10/2019 11:49, Nagalakshmi V J wrote:
> Now the issue is SSL_session structure is also having accessor APIs
> which I am not aware of. So I need to get the APIs for accessing the
> master_key_length,etc.. given in the above code. Those are not listed
> in the openssl link referred.
On thi
gt; Thanks & Regards,
> Nagalakshmi V J
> --------
> *From:* Matt Caswell
> *Sent:* 18 October 2019 14:48:33
> *To:* Nagalakshmi V J ;
> openssl-users@openssl.org
> *Subject:* Re: OpenSSL compilation errors in
On 23/10/2019 10:24, Johannes Bauer wrote:
> Hi list,
>
> I'm in the process of refactoring/updating code that has been using
> TLS-PSK with TLSv1.2 for a number of years successfully. I want to
> upgrade it so that it uses TLSv1.3 exclusively.
>
> I find it *exceptionally* hard to wrap my hea
On 23/10/2019 12:32, Johannes Bauer wrote:
> One step further... I've peeked at s_server.c and copied some of that
> code. I.e., concretely I now am at:
>
> const unsigned char tls13_aes128gcmsha256_id[] = { 0x13, 0x01 };
> const SSL_CIPHER *cipher = SSL_CIPHER_find(ssl, tls13_aes128gcmsha256_i
On 25/10/2019 09:39, Viktor Dukhovni wrote:
> On Fri, Oct 25, 2019 at 03:33:43PM +0800, John Jiang wrote:
>
>> I'm using OpenSSL 1.1.1d.
>> Just want to confirm if DHE_DSS cipher suites are not supported by this
>> version.
>
> They are supported, but:
>
> * DSS ciphersuites are disabled
On 29/10/2019 10:34, Nagalakshmi V J wrote:
>
> tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf),
>
> pGenerator->master_secret,sizeof(pGenerator->master_secret),
>
> km,tmp,num);
It seems your code is replicating parts of libssl - which seems like a
strange (and possibly
d.html
Matt
>
> Not sure if I can use the above link.
>
>
> /Thanks & Regards,/
> /Nagalakshmi V J/
> ----
> *From:* Matt Caswell
> *Sent:* 29 October 2019 10:47
> *To:* Nagalakshmi V J ;
On 31/10/2019 11:59, Samuel Williams wrote:
> I am maintaining the OpenSSL bindings for Ruby, and I'm considering
> exposing SHA3 and BLAKE digests.
>
> In addition, for the first time, I wrote some tests to test ALL
> algorithms we expose, and found that "DSS", "DSS1" and "SHA" no longer
> exi
On 01/11/2019 07:56, pablo platt wrote:
> Hi,
>
> Stitching aes-cbc with sha1 can result with x2 performance [1].
> Is there support for stitched aes-128-hmac-sha1 encrypt-then-mac? This
> issue [2] says that only mac-then-encrypt is supported in OpenSSL.
The issue is correct. Only mac-then-en
gt; Is it planned to add aes-128-hmac-sha1 encrypt-then-mac?
There are no current plans. You might investigate the impact of using
AEAD ciphers instead.
Matt
>
> On Fri, Nov 1, 2019 at 1:32 PM Matt Caswell <mailto:m...@openssl.org>> wrote:
>
>
>
>
Please take a look at my blog post that gives an update on OpenSSL 3.0
development, FIPS and 1.0.2 EOL:
https://www.openssl.org/blog/blog/2019/11/07/3.0-update/
Matt
On 11/11/2019 19:43, Benjamin Kaduk via openssl-users wrote:
> On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote:
>> I am speaking TLS 1.3 with openssl to a hardware device that I can't change.
>> I need the client hello header to only support certain extensions, yet I
Any compli
On 11/11/2019 22:12, Michael Wojcik wrote:
> -Original Message-
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Phil Neumiller
>> Sent: Monday, November 11, 2019 15:57
>>
>> Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL);
>
> That's just a verbose way of s
On 11/11/2019 21:09, Phil Neumiller wrote:
> The hardware wants to see a client hello like the following:
By this do you imply that if you give it additional extensions it fails?
That is a highly non-compliant implementation!!
Matt
On 11/11/2019 20:51, Phil Neumiller wrote:
> Extension: ec_point_formats (len=4)
> Type: ec_point_formats (11)
> Length: 4
> EC point formats Length: 3
> Elliptic curves point formats (3)
> EC point format: uncompressed (0)
> EC point f
On 13/11/2019 09:22, Umamaheswari Nagarajan wrote:
> The following apis seems to be unavailable or modified in 1.1.1c,
>
> ENGINE_cleanup
This still exists, but was converted from a function to a macro that
does nothing. You no longer need to call it. OpenSSL 1.1.0+ cleans
itself up automatica
On 13/11/2019 17:20, Jason Schultz wrote:
> Hello-
>
> I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in
> preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm
> confused about the function in the subject line as well as other,
> related sk_X509_* functions.
On 14/11/2019 17:46, Phil Neumiller wrote:
> Here is my server script is:
>
> PSK=63ef2024b1
> openssl s_server -accept 4433 -tls1_3 -nocert -psk $PSK -ciphersuites
> TLS_AES_256_GCM_SHA384
>
> Here is the client:
>
> PSK=63ef2024b1
> openssl s_client -tls1_3 -psk $PSK -connect :4433 -ciphe
On 14/11/2019 22:30, Phil Neumiller wrote:
> Hi Matt,
>
> That works fine for 256 as you mentioned. I trying to speak to a piece of
> hardware that has one supported cipher, i.e. TLS_AES_256_GCM_SHA384. I
> tried the naive approach of
>
> PSK=63ef2024b1
> openssl s_server -accept 4433 -tls
On 15/11/2019 22:03, Phil Neumiller wrote:
>
> TLS 1.3 doesn't use EC point formats right? I don't know why they are in my
> TLS 1.3 client hello.
No, its not used in TLSv1.3 but is used in TLSv1.2 or below. A
ClientHello is sent before version negotiation takes place so you don't
know what v
On 17/11/2019 01:43, Rafael Ferrer wrote:
> It's DTLS-OK according to IANA.
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16
>
>
> I tested ED25519 certificates on TLS 1.2 and it worked fine.
>
> openssl s_server -port 4321 -cert server-cert.pem -key se
On 18/11/2019 16:42, Matt Caswell wrote:
>
>
> On 17/11/2019 01:43, Rafael Ferrer wrote:
>> It's DTLS-OK according to IANA.
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16
>>
>>
>> I tested ED2551
On 25/11/2019 08:45, fer...@hyperion.io wrote:
> Sorry to bring this up again but I really don't know how to fix. I already
> re-wrote my code to use SSL_read/SSL_write instead of a SSL filter BIO but I
> still get the same error.
>
> I can reproduce when the sender is nginx, socat openssl-list
On 26/11/2019 11:38, shiva kumar wrote:
> Hi,
> As we know that OpenSSL 1.0.2 support will end in 31st December 2019.
> and the latest version is 1.0.2t, is there will be any release by EOL?
> can we expect a release before EOL?
This is as yet undecided. We issue releases on an as-needed basis
;
> On Tue, Nov 26, 2019 at 6:31 PM Matt Caswell <mailto:m...@openssl.org>> wrote:
>
>
>
> On 26/11/2019 11:38, shiva kumar wrote:
> > Hi,
> > As we know that OpenSSL 1.0.2 support will end in 31st December 2019.
> > and the latest versio
On 03/12/2019 16:29, Angus Robertson - Magenta Systems Ltd wrote:
> Google has started using RSA-PSS private keys for Json Web Keys.
>
> I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key, but this
> does not work for RSA-PSS.
In what way does this not work?
Perhaps you are missin
On 03/12/2019 16:59, Angus Robertson - Magenta Systems Ltd wrote:
>>> I create an RSA JWK using EVP_PKEY_get1_RSA and RSA_get0_key,
>>> but this does not work for RSA-PSS.
>>
>> In what way does this not work?
>
> error:0607907F:digital envelope routines: EVP_PKEY_get0_RSA:expecting
> an rsa
On 03/12/2019 17:23, Angus Robertson - Magenta Systems Ltd wrote:
>> What does EVP_PKEY_base_id() return for your pkey? How did you
>> create it?
>
> base_id is 912, EVP_PKEY_RSA_PSS=NID_rsassaPss.
Sorry. My mistake. I actually meant what does EVP_PKEY_id() return.
That just does this:
int
On 03/12/2019 18:02, Angus Robertson - Magenta Systems Ltd wrote:
>>> Sorry. My mistake. I actually meant what does EVP_PKEY_id()
>> return.
>
> Also returns 912, the same as base_id. RSA keys both return 6.
>
>> So if you get EVP_PKEY_RSA_PSS returned from that I don't
>> currently unders
On 03/12/2019 19:07, Angus Robertson - Magenta Systems Ltd wrote:
>>> Agreed, code looks clear enough, but was this was for 1.1.1 or
>>> master?
>>
>> This code looks the same in 1.1.1 and master.
>
> It seems the EVP_PKEY_RSA_PSS addition was only committed 28th October
> 2019, so need to wai
On 04/12/2019 11:22, Angus Robertson - Magenta Systems Ltd wrote:
>>> It seems the EVP_PKEY_RSA_PSS addition was only committed 28th
>>> October 2019, so need to wait for 1.1.1e, hopefully real soon...
>>
>> Ah, that explains it!
>
> Now tested with 1.1.1e-dev and I can generate a JWK from an
On 07/12/2019 11:41, Myron Joffe wrote:
> Hi all
>
> Does either OpenSSL 1.0.2j or 1.0.2r support Extend Master Secret (EMS)?
>
No. Extended Master Secret support was first added in OpenSSL 1.1.0.
Matt
On 13/12/2019 23:52, John Baldwin wrote:
> I've recently been working on adding support for kernel TLS offload
> to FreeBSD and have some patches merged into master already along
> with a couple of open reviews (and at least one other patchset in
> progress).
>
> With the recent-ish announcemen
On 13/12/2019 16:46, Shamatrin Dmitriy wrote:
> Hello!
>
> I have few questions related to openssl distribution.
>
> Let's say that I need this:
>
> https://pastebin.com/D4Eh0i6P
>
> For my application to keep working.
>
> Could someone please help me with these questions?
>
> 1. Is that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.0.2u
This release will be made available on Friday 20th December 2019 between
1300-1700 UTC. This will contain one LOW severity fix for CVE-2019-1551
previo
On 02/01/2020 04:11, Manish Patidar wrote:
> Hi
>
> What is the difference in libfips.a and fips.so.?
> Selftest.c and fipsprov.c is extra in fips.so library compilation. Does
> it mean that it just add provider entry function and self test, which is
> required for fips certification.?
libf
On 10/01/2020 22:41, Sebastian Andrzej Siewior wrote:
> gnutls-cli sends by default (in the supported groups extension)
> `secp256r1' first and later `x25519'. The key_share extension contains a
> key for both types. The server has both types configured both groups and
> `x25519' comes first.
>
On 13/01/2020 06:20, Phani 2004 wrote:
> Hi Team,
>
> I am trying to add support on an hardware engine for aes-cbc-hmac-sha1.
> I have observed that currently aes-cbc-hmac-sha1 is supported only for
> x86 architecture.
> "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The
>
t;
> Thanks in advance.
>
> Regards
> Phani
>
> On Mon, Jan 13, 2020 at 5:53 PM Matt Caswell <mailto:m...@openssl.org>> wrote:
>
>
>
> On 13/01/2020 06:20, Phani 2004 wrote:
> > Hi Team,
> >
> > I am trying to add support
On 14/01/2020 04:51, Manish Patidar wrote:
> Hi
>
> Can any guide me how to use fips api in openssl?
>
> I try to use like below but it always returns null.
>
> ctx = EVP_CIPHER_CTX_new() ;
> ciph = EVP_CIPHER_fetch(NULL, "aes-128-cbc", "fips=yes") ;
>
> I am doubting fips provider is not l
On 26/01/2020 21:03, Jeffrey Walton wrote:
> I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d.
>
> Configure is dying:
>
> * Unsupported options: no-comp
> --prefix=/home/jwalton/tmp/build-test
> --libdir=/home/jwalton/tmp/build-test/lib
>
> According to INSTALL
On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote:
> 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
> version number:s3_pkt.c:365:
You don't say, but from the reference to s3_pkt.c above I assume you are
using OpenSSL 1.0.2
This error means that the server has received a record
re you using for reading the data in the server?
Is it possible to get a wireshark trace of the failing handshake?
Matt
>
> Regards,
> Hari.
>
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Matt Caswell
> Sent
On 01/02/2020 21:10, Leslie Rhorer wrote:
> Sat Feb 1 14:54:29 2020 us=650860 192.168.1.1:1194 VERIFY ERROR:
> depth=0, error=unsupported certificate purpose: C=US, ST=TX, L=San
> Antonio, O=Silicon Ventures, CN=RAID-Array, emailAddress=lesrho...@att.net
> Sat Feb 1 14:54:29 2020 us=650899 192
On 07/02/2020 18:14, Pedro Lopes wrote:
> Hello,
>
> I'm assigning the RSA key as EVP_PKEY_RSA_PSS:
> RSA* key;
> EVP_PKEY_assign(*outKey, EVP_PKEY_RSA_PSS, key);
>
> As is known EVP_PKEY_get0_RSA was recently updated to also accepts
> EVP_PKEY_RSA_PSS and return the rsa value.
>
> I'd like t
On 11/02/2020 13:05, Valerio Di Gregorio (vadigreg) via openssl-users wrote:
> 1. ASYNC_pause_job() can wake up before write(). It will then block on
> the read(), which is too bad in my single-threaded code.
> 2. I fixed case 1 by making read() non-blocking, I then run
> ASYNC_pause_j
gt; Many thanks for helping!
>
> Val
>
>
> -Original Message- From: openssl-users
> On Behalf Of Matt Caswell Sent:
> Tuesday, February 11, 2020 2:52 PM To: openssl-users@openssl.org
> Subject: Re: Issues with ASYNC_pause_job() wake up
>
>
;t know what that means you need to do in libcurl terms.
Matt
>
> Val
>
> -Original Message- From: Matt Caswell
> Sent: Tuesday, February 11, 2020 3:36 PM To: Valerio Di Gregorio
> (vadigreg) ; openssl-users@openssl.org Subject:
> Re: Issues with ASYNC_pause_job()
The OMC has just published a blog post on our thoughts on QUIC in
OpenSSL. You can read it here:
https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/
Matt
1 - 100 of 1436 matches
Mail list logo
