CURE|THE|ITCH

12/20/2010 *** FireGPG has been discontinued; so we are working on implementing a new browser solution; we are taking this oppotunity to change some of the structure, as, FireGPG was the only gpgAuth client I am aware of, we won't be breaking the protocol for anyone. A client supporting gpgAuth v1.3.0 is almost ready. ***

gpgAuth is an authentication mechanism which uses Public/Private (cryptographic) keys (such as GnuPG, PGP) to authenticate users to a web-page/web-service.

The process works by the two-way exchange of Encrypted+Signed tokens between a user and the service.

The mechanism consists of a server-side process which:

• Stores the Public-Key(s) of the users - maintaining a map that correlates the key(s) to a user account.
• When a login request is initiated, the server process accepts a token of random data (a "nonce") - generated by the client and encrypted to the Public Key of the service/domain.
• Decrypt the token received from the client
• Generate a different nonce and encrypt it to the users Public Key, signed by the service/domain Public Key - and provided both to the client.
• Upon receiving the decrypted and signed result from the client, verify signature matches and compare the nonce against the original packet.

Some things to note regarding the server-side process:

• The server-side process is NOT a transport encryption mechanism akin to TLS/SSL. gpgAuth is an authentication mechanism for verifying the identity of users via cryptographic key verification and/or the web of trust.
• The server-side process does not have to be 'all or nothing', it can operate in other authentication environments.
• The server-side process is not specific to any particular programming language, web technology, operating system or web-server platform. gpgAuth has been implemented in environments such as: PHP, mod_python and Django.
• The server-side process is a process/protocol, not software - obviously you need logic to implement the process/protocol, but this can be achieved using just about anything which can communicate with the keyring software (such as GnuPG)

The client side process is responsible for performing the following:

• Storing the Public Keys associated with domains/web services
• Maintaining a map of keys to services/servers/domains
• Verifying the validity of the Public Keys [optional]
• Generating a nonce and encrypting it to the server/service Public Key [optional]
• Posting the data and initiating the login event [optional]
• Accept the decrypted nonce and verify the signature [optional]
• Accept the encrypted packet from the server/service, decrypt it and verify the decrypted data is properly encapsulated in the predefined wrapper
• Return a signed copy of the decrypted nonce to the server

Things of note regarding the client process:

• The steps marked optional are only necessary to perform symmetric authentication - to ensure to the client the server/service's identity.
• It is possible to perform this process of maintaining keys and exchanging tokens of encrypted/decrypted/signed data by hand (without client software)
• Software exists to automate this process
• After receiving an encrypted token, the client verifies the data is encapsulated by pre-formatted data to prevent the client from being tricked into decrypting and returning data that should not be returned to the server/service.