I would like to use openssl as a basic DTLS server from the command line
using: openssl s_server -dtls1_2
The catch is I want to require the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
cipher suite. It appears OpenSSL currently doesn’t support this cipher
suite, even though it supports the both ECDHE_ECDSA
Hello,
I’m using openssl to administer a root/intermediate CA and I use the
certificates for a number of web servers and other applications. All of my
users install my root CA certificate for trust.
I’ve been asked to use a hardware random number generator to create the
keys/certificates go
We are considering a big cleanup to the memory-allocation API's in the next
release.
Please take a look at the attached documentation, which describes *ALL* of the
public functions, and let us know if it will cause a problem.
Thanks.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.
On 09/02/2015 02:35 PM, Alberto Roman Linacero wrote:
> Yep, I understand now. I thought that the whole binary file
> application was signed, and not only the FIPS module part.
An understandable assumption, see below.
> I already did some tests (with that string and also in different parts
> of t
Yep, I understand now. I thought that the whole binary file
application was signed, and not only the FIPS module part.
I already did some tests (with that string and also in different parts
of the code that belongs to the fipscanister.o), and it -correctly-
fails.
server:~# export OPENSSL_FIPS=1
On Tue, Sep 01, 2015, Alberto Roman Linacero wrote:
> So, it is possible in runtime to know if the FIPS module code has been
> changed after compiling? I mean, after the openssl has been compiled
> with the FIPS Object Module (./config fips & make & make install), the
> 4 files in the FIPS Object
On Wed, Sep 02, 2015, Sands, Daniel wrote:
> > Well at first sight that looks like an IMPLICIT tag which replaces
> > the normal
> > tag with the context specific value. It is not possible to determine
> > the
> > underlying type from the encoding itself as it has been replaced. So
> > you need
>
> Well at first sight that looks like an IMPLICIT tag which replaces
> the normal
> tag with the context specific value. It is not possible to determine
> the
> underlying type from the encoding itself as it has been replaced. So
> you need
> the ASN.1 spec to see the appropriate type to use.
>
>
On Wed, Sep 02, 2015, Massimiliano Pala wrote:
> Hi all,
>
> since someone asked, here's my solution (if someone knows of a
> better one, please let me know).
>
> The problem that I tried to solve is how to parse the
> CRYTPLIB-specific envelope for signatures. In particular, the
> example repor
Hi all,
since someone asked, here's my solution (if someone knows of a better
one, please let me know).
The problem that I tried to solve is how to parse the CRYTPLIB-specific
envelope for signatures. In particular, the example reported in my
original e-mail was a DSA signature. The main iss
10 matches
Mail list logo
