Home

Concept

This library provides a public key infrastructure (PKI). It is based on ASAP, a routing protocol specialized decentralized networks, especially ad-hoc networks.

The concept is very close to PGP but easier to integrate into a ASAP environment. The library allows

• creating RSA keys
• create certificates
• exchange certificate in a pure decentralized system
• calculate a probability of correctness of a certificate

Certificates

The very core of each certificate is a public key of a user, lets say A(lice). A public key can be used by others to a) encrypt data to be sent to the user and b) to verify a digital signature.

A PKI is as save as the relation between a real person and its public available key can be guaranteed.

Attackers try to impersonate others. An attacker, lets call him Mallory, would another person (e.g. Bob) that he is actually Alice. Each good PKI should give Bob to verify issuers claim. That's not an issue of computer science - it is about real world.

Receivers of a public key must ensure that this key belongs to the person (technical term: subject). Mallory will always try to trick others. He is to blame. But receives are even more to blame if they neglect to perform a reasonable checking. Bob should look at Mallory, ask for an ID or something like that and realize that he is not Alice.

Signing

Receivers can create a certificate if they are convinced of subjects' identity. Alice met Bob for instance. Bob is convinced that he really met Alice. He would take the public key, add the name Alice (and a view other parameters) and sign it. Bob becomes issuer of a certificate.

A certificate is a proclamation of the issuer:

I, the issuer (Bob), herewith proclaim, that this public key belongs to the subject (Alice). I sign it.

A certificate contains at least: Subject (name, id or both), issuer (name, id or both), subjects' public key. There is usually a valid since and until timestamp. Lets use the abbreviation: cert(B,A) - B signed A.

Verifying

Even Alice would be interested in getting this certificate. Why is that? She could present this certificate others, e.g. C(lara). Clara would try to verify the signature.

She can do so if she has got issuers' public key. Clara could verify that Bob proclaimed that the public key belongs to Alice. Clara could use this key, if she trusts Bob. We are going to discuss this special kind of trust very soon.

ASAP Certificate concepts

The previous considerations are the basics of digital certificates. This library adds a view concepts.

Identity Assurance and Signing Failure

Singing a public key is a very critical moment in each PKI. An issuer_ must ensure that s/he is not fouled by an attacker. There is always a probability to sign the wrong subject, though.

Signing Failure

We use the term signing failure for this probability. Probabilities rang from 0% (never happens) to 100% (always happens). We use integer numbers from 0 (never makes any mistake) to 10 (is always cheated).

Each person in our PKI can define a signing failure for any other person. This number is never published. The signing failure describes e.g. Alice' estimate how easy Bob can be cheated. Most likely, estimations of Alice and Clara will differ.

Signing failure is not a measure of how persons like each other. Alice and Bob could be very close friends. Nevertheless, Alice could estimate that Bob is somewhat sloppy in this matter. Maybe, it is part of his charming nature. It makes his certificates not better, though. Maybe, Clara does not like Alice at all but has admit that she is very thorough in this matter.

The Signing failure estimation is not a measure of friendship but of thoroughness.

In this lib

• the signing failure of the person itself is always set to 0. We never make mistakes.
• Signing failure of others can never be better than 1. Only we are perfect.

There is a serious reason. We come back to it soon.