User Tools

Site Tools


Signature Authentication

While public key encryption is a method of encrypting data, signature authentication or public key authentication is an alternative method of identifying yourself to a login server, instead of typing the password. Under most circumstances, it is considered considerably more secure and and at the same time more flexible then conventional password authentication.

When using the latter, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked or your connection to the server is being spoofed, an attacker can learn your password.

Public key authentication solves this problem by using public-key cryptography not for encryption of data, but for merely creating and authenticating digital signature.

You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures . A signature created with your private key (virtually) cannot be forged using some other key; but anybody who has your public key can verify that a particular signature is genuine.

With the program of your choice, you generate a key pair on your own computer (which should not already be hacked…), and copy the public key to the server, in our case running OpenWrt. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in.

Now in case the server is hacked or the connection is being spoofed, the attacker does not gain your private key nor your password, but merely one signature. And signatures cannot be re-used, so they have gained nothing.

NOTE: ssh already make use of public key authentication, but only to authenticate the server. If the server has been hacked, the auth would still succeed.


Implied Weaknesses

  • Public Key Authentication can be brute-forced. The expenditure to do this with modern technology is so high that it can be considered secure for most purposes. This may change in the future, either due to increases in raw computing power or due to a mathematical breakthrough.
  • A private key is usually 2048 bits (or more) in size, so (almost) no one can memorize it. Therefore, it has to be stored. Access to the storage device must be controlled or the key must be encrypted.
  • The client system from which a login is performed has to be pristine.
  • 3rd party authentication of public keys is not an issue when you personally put public keys on the server or give them to other people. However, if the server has been compromised, the perpetrator can replace the public key (besides doing many other things).

User negligence

Security never relies on some algorithm, but on the user comprehending the principles and acting sanely. Usually there is a chain of security and every link must be kept secure on its own, for the whole concept to work. Therefore every encryption method has some immanent weaknesses which once met, define a method as considerably secure. But then there is the user…

* If success of brute-force attacks is reported as high, do not use this encryption method any longer :-P

  • Pristine Client: You should not store you private key on a memory stick and then attempt a login from a host in an Internet café or from your friend, since the host could be hacked. But if at least the BIOS of this host is pristine, you could very well boot from a Linux DVD, or from your USB stick. That way you'd have a clean OS in which you could use your private key to encrypt data or generate signatures.
  • Access to Private Key. Your private key is nothing but a huge number. Nobody can know it! The private key is going to be stored in a digital form on some storage device, like your hard disc or some memory stick. And that way, anybody who gains access to that is able to copy your key. For this reason, a private key is ALWAYS encrypted when it is stored, using a passphrase (now this has to be a very long password) of your choice. In order to generate a signature, your client (e.g. PuTTY) must decrypt the key, so you have to type your passphrase.


The passphrase can make public-key authentication less convenient than password authentication because the passphrase is much longer then a password. Every time you log in to the server, instead of typing a short password, you have to type a long passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY's authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience.

There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA's federal Digital Signature Standard.

Here is a german wiki from about security:


Assuming you have a key in ~/.ssh/ on your host computer, you can copy it to the OpenWrt system in just one command:

ssh root@openwrt "echo $(cat ~/.ssh/ >>/etc/dropbear/authorized_keys;chmod 0600 /etc/dropbear/authorized_keys"

Thereafter, you can log into the OpenWrt system from your host computer without the need for a password.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
docs/techref/signature.authentication.txt · Last modified: 2018/06/07 19:33 by tmomas