> From: Michael Wojcik
> Sent: Thursday, February 28, 2019 15:55
>
> Have you tried just changing the PEM header and footer? ...
Whoops. Just saw Viktor's response. Never mind.
--
Michael Wojcik
Distinguished Engineer, Micro Focus
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Ken Goldman
> Sent: Thursday, February 28, 2019 15:06
>
> I've been using this command to generate a password protected ECC keypair.
>
> openssl ecparam -name prime256v1 -genkey -noout | openssl pkey -aes256
> -passout
On Thu, Feb 28, 2019 at 03:05:43PM -0500, Ken Goldman wrote:
> The output is a
> -BEGIN ENCRYPTED PRIVATE KEY-
This is PKCS8, which is the non-legacy private key format that
should be used by modern libraries. This is for example output by:
$ openssl genpkey -algorithm ec -pkeyopt e
Not sure if anyone is aware or not, but many of the man pages on the
openssl.org site contain broken links. Basically anywhere a man page
refers to a man page in a different section, the link is broken because
it uses the same section.
So for example:
https://www.openssl.org/docs/man1.1.1/man7
I've been using this command to generate a password protected ECC keypair.
openssl ecparam -name prime256v1 -genkey -noout | openssl pkey -aes256
-passout pass:passwd -text > tmpecprivkey.pem
The output is a
-BEGIN ENCRYPTED PRIVATE KEY-
which I parsed using
PEM_read_PrivateK
On Wed, Feb 27, 2019 at 8:42 AM Matt Caswell wrote:
> On 27/02/2019 16:33, Sam Roberts wrote:
> > That would be helpful!
>
> It has been updated:
Thank you, that is helpful.
On Thu, 28 Feb 2019 14:41:19 +0100,
Salz, Rich wrote:
>
> > There are two options. First, the application does the digest and
> > sign as two separate things.
>
> My memory is a foggy surrounding that scenario, so I might be wrong,
> but I think it was argued that this was in
> There are two options. First, the application does the digest and
> sign as two separate things.
My memory is a foggy surrounding that scenario, so I might be wrong,
but I think it was argued that this was invalid use from a FIPS
perspective. Now, we can't actually stop
>From https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
I got these lines
"OpenSSL provides mechanisms for interfacing with external cryptographic
devices, such as
accelerator cards, via “ENGINES.” This mechanism is not disabled in FIPS
mode. In general, if a
FIPS validated cryptographic de
On 27/02/2019 19.53, Michael Richardson wrote:
>
> Christian Heimes wrote:
> > I'm concerned about the version number of the upcoming major release of
> > OpenSSL. "OpenSSL 3.0" just sounds and looks way too close to "SSL 3.0".
> > It took us more than a decade to teach people that SS
On 28/02/2019 00:17, Torrelli, Maxime wrote:
> Thank you very much for your answer. At least now I know what to except from
> the generated makefile !
>
> What do you think of this : could I try to adapt the makefile for 1.0.2
> (which is compiling for 1.0.2) to the 1.1.1 release ? Is the dif
On 27/02/2019 22:20, Richard Levitte wrote:
>> I believe Richard is wrong here. Or at least his text could be
>> misleading. If the EVP API does the digesting with one module and
>> then calls another module to do the RSA signing, that is okay.
>
> Huh? From the design document, section "Exa
On Thu, 28 Feb 2019 00:51:24 +0100,
Dr. Matthias St. Pierre wrote:
>
>
> > Uhm, I'm confused. I thought we were talking about 3.0?
>
> Well, the original post started at FIPS 2.0:
>
> > I am using openssl-fips-2.0.16 and openssl-1.0.2e.
> https://mta.openssl.org/pipermail/openssl-users/2019
On Thu, 28 Feb 2019 00:17:13 +0100,
Salz, Rich wrote:
>
> >Huh? From the design document, section "Example dynamic views of
> algorithm selection", after the second diagram:
>
> An EVP_DigestSign* operation is more complicated because it
> involves two algorithms: a s
14 matches
Mail list logo
