Re: Authentication over ECDHE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 24, 2018 at 04:25:54PM +0100, Christian wrote:

> > Your research has led you astray.  The ECDHE-RSA-AES128-GCM-SHA25
> > ciphersuiteo *is* RSA authenticated and offers forward secrecy,
> 
> Then how would I load my static RSA keys into my SSL_CTX? Simply by 
> using SSL_CTX_use_PrivateKey_file on client and server?

To avoid trusted CAs, you have to load both a private key *and*
a self-signed certificate.  While certificate-less TLS is in
theory possible with RFC7250 bare public keys, in practice no
libraries I know of support this.

Also, your CA does not have to be a third-party CA, you can generate
your trusted issuer CA, its private key can be "off-line", making
recovery from server key compromise somewhat simpler, but with so
few systems in scope the difference is minor.

> As far as I understand the mechanism that would only enable encryption,
> but not decryption.

Again, that's not the case, but you still need a certificate to go
with that key.  In the simplest case that certificate can be
self-signed, and would be the only one (or one of a few) trusted
by the verifier (via suitable settings of CAfile and CApath).

> > they are both quite strong, use 128-bit to optimize for speed or
> > 256-bit against hypothetical attacks on 128-bit AES that don't break
> > AES-256.
> 
> Actually, I've been told that AES256 is weaker than AES128 in theory, 
> and have been discouraged to use it.

There are some concerns about the key schedule, but they've not
panned out to attacks that make AES256 weaker than AES128.

> > and you could use Ed25519 certificates and/or X25519 key exchange.
> 
> I said I'd like to avoid using any certificates. I don't see the point 
> of them if I'm going to use static keys anyways.

You're going to have (self-signed) certificates.  They're essentially
slightly bloated key containers.

> And certificates, from my limited understanding, only establish external
> trust anyways. I want direct trust.

Certificates do not preclude direct trust.  Self-signed certificates do
not entail any outside parties.  A suitable self-signed certificate and
private key can be generated via:

    $ temp=$(mktemp chain.XXXXXXX)
    $ openssl req -new -newkey rsa:2048 -nodes -keyout /dev/stdout \
	-x509 -subj / -days 36524 >> $temp && mv $temp self-chain.pem

I think that password protection for the keys is a waste of time,
but if you can use it if you wish.

    $ temp=$(mktemp chain.XXXXXXX)
    $ openssl genrsa -aes128 -out $temp 2048
    $ openssl req -new -key $temp -x509 -subj / -days 36524 >> $temp &&
	mv $temp self-chain.pem

-- 
	Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux