On 24/12/2018 11:51, Christian wrote:
> Hello, people. I'm a beginner with OpenSSL and with cryptography in general,
> and
> have been wondering how to best implement an upcoming system.
>
> I apologise in advance for any grammar or orthography mistakes, as English
> isn't
> my native language.
>
> We have a local network with a databse in which we do most of our processing,
> and a public machine that runs a webserver. Periodically we have to connect to
> that server and query new data to process it. The connection to that server is
> not necessarily trusted.
>
> The problem is that our webserver is slow and clunky and generally just issues
> another process to deal with any request, which is unnecessary and slow. We
> want
> to streamline that process by having a local program run on the server
> sending a
> set of predefined queries over a predefined protocol, and then just sent that
> data back to the client. However, only a select few machines are supposed to
> be
> able to get any data from the server, like, those who have a certain private
> key. If a client can sign a ping that can be decrypted with the client side
> public key, and if the server can sign a ping that can be decrypted with the
> servers public key, then both sides are authenticated, and - from my limited
> understand - a MITM scenario is foiled (unless the MITM manages to steal
> either
> private key, which is why I also want to have password protection for the key.
> I'm away that putting the key into a program compromises the security of the
> key
> if an attacker manages to gain access to the server, but in this case it's
> just
> supposed to give us some time to stop the programs, close all holes, and
> generate new keys).
>
> This sounds like a typical RSA scenario, however I also want to have forward
> security, which requires me to use something with temporary keys only - I'm
> having ECDHE in mind for that, ECDHE-RSA-AES128-GCM-SHA256 in particular.
> However, after some research I found out that the "RSA" in that cipher only
> refers to the temporary keys that are being generated for this connection, and
> thus authentication would have to be issued on top of TLS, not within the
> means
> of TLS itself.
>
> And last, but not least I've read about an attack a little while back how some
> DH parameters (usually those with a size of 1024 bits) have become stale. If I
> want to have extra security,
>
> Speed isn't an incredible huge problem, as there will always be just one, at
> most two connections running with the server. As such its design can be
> incredible simple, and the connection can be more secure in terms of
> cryptography than default (4096 RSA keys and 2048 DH params wouldn't be an
> issue). I expect the bulk of the runtime to be spent on the database server
> side
> of things anyway.
>
> I don't want to use certificates. Either a client/server has the necessary
> private keys to sign data, or the connection is simply refused. I also don't
> want to use any password, because that requires to share a secret over a to
> this
> moment still unverified channel.
>
> My question is thusly how to implement authentication over ECDHE in the best
> way. My searches for "openssl c sign data with private key" doesn't yield any
> usable results, which suggests that there is some sort of misunderstanding
> with
> the concept of "signing ping/pong with respective private keys". Are there any
> functions or further documentation to be of help here? Please keep in mind
> that
> all of this has been Greek to me until last Friday, and that I'm by no way a
> cryptography expert.
>
> Thank you for your time and effort in advance.
How about using PSKs? That way you completely avoid the need for a certificate.
Authentication is implied since both peers must have access to the PSK for the
connection to succeed. ECDHE can be combined with the PSK to create a temporary
key for the connection, thus giving you forward secrecy, e.g. using a
ciphersuite such as ECDHE-PSK-AES128-CBC-SHA256.
Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
