Plaintext attack vulnerabilities?

Brian Mearns bmearns at
Wed Jun 17 14:37:25 CEST 2009

On Tue, Jun 16, 2009 at 9:11 AM, Daniel Kahn
Gillmor<dkg at> wrote:
> On 06/16/2009 06:44 AM, Brian Mearns wrote:
>> Are there any known vulnerabilities associated with an attacker who
>> can provide plaintext and receive a signature for it? I'm planning a
>> simple computer-auth system where a client sends a random token to the
>> server, and then the server signs and returns it to prove that the
>> server has the private key. I'm wondering if a malicious client could
>> provide a certain plain text such it could learn something about the
>> private key based on the returned signature.
> The client may or may not be able to learn anything about the private
> key directly, but there are other serious attacks that such a scheme
> could be vulnerable to.
> For example, a relay or man-in-the-middle attack is possible:
> Alice wants to, a server run by Bob.  Mallory happens to
> have a machine ( on the network path between Alice
> and
> intercepts the traffic, and answers to Alice as
> though it were
> Alice asks to prove that it is by
> supplying it a random token to sign.
> in turn opens a connection to the real
>, pretending to be Alice, and hands it the same token,
> which signs and returns to
> replays bob.e.o's signature to Alice to establish
> its fake identity.
>  ----
> If the uses the same key for other purposes (e.g.
> identity certification, or more generally as a primary key), there are
> still other attacks that are possible.
> Why design your own protocol?  There are several public-key-based
> network authentication protocols (using OpenPGP or not) which already
> exist and have been vetted, many of which have free implementations you
> can use!  For example, you could use RFC 5081 (TLS with OpenPGP
> certificates).  This is not widely adopted at the moment, but it is
> implemented in recent versions of GnuTLS.
> As a rule of thumb, any asymmetric key which is set up to automatically
> sign arbitrary plaintext provided by possible attackers is opening the
> door to potential compromise.
>        --dkg

Thanks for the response, Daniel.

The man-in-the-middle attack isn't a concern for me because the server
is behind a firewall. The setup here is that the client is a laptop
and I'm looking for a simple, automatic way to determine whether or
not it's on a particular network by sending a string to a certain LAN
IP address (192.168.*.*), and confirming that it comes back signed
with the correct key. This isn't actually for secure communications,
so a man in the middle who's also behind the firewall is no big deal:
the "attack" will only work if we're all on the same LAN, so it will
still confirm what I want it to.

The attack I'm worried about (which I've learned is called a "chosen
plain-text attack") is that a malicious client on the LAN will send
particular strings to the server and be able to learn about the
server's key based on the response. To avoid this, I thought I could
have the server concat it's own random string to the one sent by the
client, then send back a digest of the combined string along with a
signature. That way, the client can guarantee (more or less) that it's
a unique string (so someone couldn't spoof the response from the
server), but cannot reasonably choose the plain text. I think this is
pretty much how the TLS handshake works, anyway.

The reason I'm rolling my own is, well for one I have a bad habit of
doing exactly that (reinventing wheels), plus I want something simpler
than a full TLS session, specifically, I want to use UDP instead of
TCP to reduce network traffic, and I want it to just be a
two-transmission operation, also to reduce network traffic.


Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from:

More information about the Gnupg-users mailing list