2

I need to frequently communicate with a server in the manner do stuff related to x or send me info of x

My thoughts are to directly put the task I want to be executed into the package I want to send, add some SALT and encrypt it using a monthly changing public gpg key. Since every user will have a public and private key, too, the package will be signed by them. This blob will be used client-side.

The server does the same but with it's key to sign and the public key of the specific user to encrypt.

Everything is sent through simple HTTP, though HTTPS would be possible, too. But is it worth it for that particular protocol? Can this even be a safe protocol? What vulnerabilities does it have? Is it considerably fast? What else should I use if any answer to the previous questions implies a highly insecure way of communicating?

NaCl
  • 123
  • 3
  • 1
    If you generate a large enough public-private key pair (4096-bit possibly 2048-bit) then you wouldn't need to change them every month. – RoraΖ Aug 19 '15 at 11:38
  • @raz My weird fiddling there seems like SSL without any CA and with overhead, I guess. If we can ensure a safe communication through e-mail using gpg, where every party knows that the guy he/she is talking to is that actual guy, why are people using CAs then? Both server and client in my 'idea' can verify that they are they and if the message might get changed through man-in-the-middle, the sign becomes invalid. Sure an attacker could act like my server, but he would not be able to sign it. So the only issue I see is whenever an attacker gets access to the server's private key. – NaCl Aug 20 '15 at 22:19
  • You might want to checkout [How does SSL/TLS PKI work?](http://security.stackexchange.com/questions/87564/how-does-ssl-tls-pki-work). If you're using simple HTTP for communication then TLS would be the easier route. It already has the support and infrastructure. Using only GPG could result in performance issues as bignum operations take significantly longer amounts of time to complete vs. symmetric encryption. – RoraΖ Aug 21 '15 at 12:17
  • 1
    The whole point in a CA is to provide trust that the guy is actually who he says he is. For example, If I go to example.com and it presents a cert that claims to be for example.com, why should I trust it? Well, because it's signed by a CA who I trust. I shouldn't trust it just because it claims it's for example.com. In your case, you control both the client and server, so you know you trust yourself and so the fact that you've self signed the cert is enough for you to trust it. – Chris Murray Aug 21 '15 at 14:46

1 Answers1

2

If you're using simple HTTP for communication then TLS would be the easier route. While you think you might have thought everything through it's better to use an established protocol for the following reasons:

  • It's already supported by most browsers, operating systems, and devices.
  • The infrastructure is already in place, with lots of examples for configuration.
  • Already tested. Faults in its security have been detected and fixed.
  • Regular updates

The other concern for using just straight GPG is performance. Bignum operations take significantly longer to perform. Having to do these large calculations for every message you send to the server could be taxing.

Checkout How Does SSL/TLS PKI work? for more information on why/how the web uses Certificate Authorities.

Community
  • 1
RoraΖ
  • 12,347
  • 4
  • 51
  • 83