KIP is a surprisingly simple idea that makes encryption and integrity as simple as a service login. Basically, anyone can make a key and use it for encryption or signing; encryption keys are only available under an ACL and a signature verification reproduces the signer's identity.

Frameworks for encryption tend to be difficult, because you need to hold (and trust!) a recipient's keys before you can encrypt. This stems from a past when encryption was an offline operation. These days however, we are so intensely online that we need to defend against it. The easier encryption can be made, the more we can use it and the better our privacy is.

The same holds for integrity, which boils down to signing of documents. To validate a person's signature you would need his key and be able to trust it. But this should ideally much simpler, to rule out any chances of abuse.

..

KIP replaces knowledge of a peer's keys, and the reliability of these keys, with a short communication with the KIP Service run under a domain. For encryption, that would normally be your own domain; for signatures you will have to look back at the signer's domain for an authoratitative statement.

Encrypting a Document

You want to send a document to a number of recipients. Your software needs keys to do this. What to do?

Your software generates a key at random. This is the session key.
Your software encrypts the document with this session key.
Your software and you select a list of users who may see the key, and construct an ACL to describe them.
Your software ships the ACL and session key to a service, that we call the KIP Service. The perfect choice for encryption is one under the recipient's domain. As a fallback your own domain may be used. You could use a third party but the recipient might not appreciate that as much.
Your software skips login at the KIP Service by choosing anonymous access. You simply do not need credentials to encryption!
Your software receives an unreadable blurb (we call it key mud) from the KIP Service, which it will process when it is sent back later.
Your software and you send the key mud and encrypted document, but not the plain-readable session key.

Now your recipients sees this funny .kip document and they can find some software for it, but what does it do?

Their software locates the key mud from the KIP Service, and extracts the domain under which it runs. There could be an interaction if the domain used is not considered reliable.
Their software sends key mud to that KIP Service so it can reconstruct the original session key.
The recipient authenticates to the KIP Service. When their user@domain.name identity is on the ACL, the session key will be returned.
Their software can now decrypt the encrypted document with the session key. Happy reading!

Have you noticed how most of this is done by software, and that the user only needs to guide it with simple choices based on domain names and whether these can be trusted?

How things have Radically Changed

The big trick of KIP is that

you can encrypt documents without managing recipient keys!

or, more accurately,

you only need your recipient's user@domain.name address

...and you probably had to enter it anyway, in a To: field of some sort!

This is a great simplification. It saves you from key management. It saves you from securely connecting with people. All you do is reference their domain names, and rely on the secure infrastructure of the modern Internet (TLS and DNSSEC) to secure your communication with accounts under those domains.

When we say KIPping the balance we mean that the work shifts from a recipient sending you a key well in time, to a sender generating a key for the recipient and letting the recipient retrieve it later. We also mean that we make it plain simple to do this whenever you feel inclined to do so.

Keys can travel with the documents they protect, so there is no need for separate key management. Caching is possible, but so is repeated access to the key. If you prefer to keep an explicit list, perhaps in your contact database, you can do that too of course, but the default is simplicity.

Encrypted Storage with KIP

If you can send encrypted documents to someone else, you can also send yourself encrypted content. You only need to be on the ACL of the session key. This can be used to encrypt files for your own use, including when they are stored at a not completely trusted site.

Interestingly, you might also use a group name on the ACL instead of your own. Then all members of that group could access the document, provided that the KIP Service can somehow see they are group members. This is the kind of thing we always do when we handle identities in ARPA2 projects! Then, when a member drops out from a group, or is added to it, the KIP Service starts making other decisions without any to the document itself. Of course we cannot take documents that were once read away from previous members – and we have not implement any form of memory erasure device into KIP, hah!

If you are going to use this, be clever about it? You want to support solutions that define a promising future, such as IPFS, rather than products that hold us all back, such as services that are "free" but need to lock you in if they are to earn the advertisers' goodwill.

Document Authenticity with KIP

If you want to prove that nobody changed the document after you wrote it, you can also use KIP. You would then sign the document instead of encrypting it, or more likely you would do both.

Signing is only slightly different from encryption:

The authority for an account is with the sender's domain
Therefore, his domain's KIP Service is used for signing
The signer needs to authenticate to produce a signature
The reader does not need to authenticate at all
The reader receives proof of the signer's identity
The reader receives checksums for document validation

Note how authentication is done with a local domain, both for decryption and signing. Remote actions are anonymous. This is why we made trust remarks about the KIP Service choice.

KIP, Tools of the Trade

The KIP toolkit consists of a few basic elements:

libkip implements core encryption and decryption, basically data in, mud out and the reverse. And secure checksums, key derivation tricks and all you might desire.
libkipservice extends the former, and can contact a KIP Service and ask you to authenticate (if need be).
kip is a simple commandline utility to encrypt and decrypt a document. We may extend it later to include network connections. We may use sloppy wit such as kip up and kip down to denote encryption and decryption.
kipd is a simple service that takes in requests to encrypt an ACL plus key; as well as requests to decrypt those by an authenticated user on the ACL. Much of the work is done in a libkipdaemon library, so you can easily make variations or extensions of this service.

There are many ways that graphical tools could do what kip does, by directly using libkip. The commandline utility is a convenience wrapper, more than a functional building block.

Comparison with Public Key Crypto

Doing this with public keys is difficult. You will need a setup, and a complex keying discipline. But that is all a matter of software (and, perhaps, patents). It does have a great advantage too: you only need to talk to the key service once, while you need to contact the KIP Service for any document you intend to decrypt. And if you drop the key or the decrypted document, you need to contact it again for another read. Oh, but there is one other point:

Protected from Quantum Computers

Quantum Computers are not esoteric and they are no fairytale either; they are being built and they will hit us hard. We follow a strategy to get over this.

All public-key encryption is basically broken; as soon as we have Quantum Computers, anything based on them and stored today can be reconstructed in retrospect. This is true for RSA, DSA, DH, ECDSA, ECDH, ECxxx.

The same does not hold for symmetric algorithms such as hashes and block ciphers. This is the kind of algorithm used in the KIP Service. As a result, the things you do with KIP are safe from future decryption.

Even when a KIP Service is authenticated with public-key crypto, this is not the same problem. Authentication is only at risk once Quantum Computers have arrived, but no traffic can be recovered, stored or not.

Bummer: We do return keys. Doing so is only safe when the connection is properly protected. TLS-KDH, please...

Ramification through Legislation

Operationally, the KIP Service is incredibly simple. It needs one key that it can use for elongated periods, but that is all. It requires no storage (let alone transactional databases) and is a perfect privacy solution if it logs nothing about traffic passed through it. And the work is really straightfoward.

Interestingly, EU countries accepted legislation that requires minimal data storage and that minimum is indeed quite low with KIP; it is null. This is the result of sharing the blurb between sender and recipient, rather than on the KIP Service or, if you think it sounds better, in the cloud.

Another important point is that the document is not sent to the KIP Service. Encryption and decryption is done by the customer. In other words, a KIP Service can only decrypt documents when it actively goes looking for them. There is no such thing as accidentally reading lines while they pass by your eyes.

Package Naming

*The kip up is an athletic exercise where you work your body up on a bar. A bit like the muscle up, except that would be a brute-force approach. The "kip up" (tool and athletic exercise) are about making difficult work easier by using proper techniques.