- You: Wow! I love this. I want to use this to encrypt everything, everywhere, always.
- Me: You can't. Or at least you shouldn't. And yes, it's ok2cry.
This project is here to show that it's OK to use cryptography. It's about how to use simple, disposable PKI without the tears. And without the bitcon bitcoin bitcon.
Cryptography is everywhere, and it's free. So you can and should use it liberally and, with ok2cry, disposably
- your programming language and OS have cryptographic tools
- mobile devices have cryptographic tools
- embedded devices, even very small and cheap kits, have cryptographic tools
- web browsers, including
OprahOpera, have a built-in cryptographic tools
- Protect data end-to-end from a server to a client
- Protect data end-to-end from a client to a server
- Protect data end-to-end from a server to a server (peers)
- Protect data end-to-end from a client to a client (peers)
Yes, yes you do. And it's great. And in many cases it's good enough. You can move on.
It's not great for every situation. Here are a few examples:
- did we say it's end-to-end, beyond IP endpoints
- it's end-to-end, beyond IP endpoints. Probably for that.
- organisation constraints
- you don't have any managed cryptography capabilities in the organisation, but you want to protect specific messages in a way that's simple and does not impose a management or operational burden.
- you do have managed cryptography capabilities but there is a lot of overhead in getting it set-up, and you only want it for a few specific cases. Or, more likely, just one.
- as an add-on to your identity system
- your users get logged in but your identity system doesn't do encryption. Few of them do. Even fewer offer end-to-end encryption for messages.
- you want to protect data after it exits TLS but before it hits your service.
- you can't risk having that data written into logs
- you don't want anyone except the person entering the data and your service accessing the data ie it's end-to-end. Yes this is the same as the first point but more words can help. And repetition is soothing.
- you want to send data to a client and be sure that only that one, exact client can read it.
- TLS is a general, universal way to protect data for anybody that uses your service.
- One way TLS used in browsers, does not help in restricting data visibility per client, by design.
- you don't want enterprise TLS interceptors to read the message.
- you've got nothing to hide, or maybe you do. Either way you don't want them peeking. You like privacy cos... it's a human right, maybe?
Thanks.
Ah, no. Definitely not. And that's why you can't use it for everything, everywhere, always. It ok2cry, it really is.
You should know that PKI based identity platforms don't give you a perfect, admin free version of secrecy either. There is always a key to protect, manage and share. Or a set of keys. If it's done well, you will hardly notice it, but it's there. The burden is always there. And it's fine. Usually.
You can use it as a value add to your identity system though. More on how to integrate with OIDC / OAuth systems [is here ... link tbc]
It's ok2cry. It really is. We encourage it. Maybe you missed the disposable part of the explanation at the beginning? It was a while ago. It's so good that you came this far.
ok2cry is a way to use cryptography for just one message at a time. Nothing about these keys is tied to your identity. Every key lasts for the duration of the message exchange and then its thrown away. Whoosh, and it's gone.
Meanwhile, your message was always perfectly encrypted between the two ends of the string. It's not a string, but I'm trying a little poetry here, so work with me. Poetry and repetition are soothing.
Excuse me, no. Where are my pearls? I need to clutch. No, absolutely not.
This is not bitcon mining. It's very efficient to produce keys. The most commonly used CPUs (mobile, PC) have direct support for cryptography. Even tiny IOT style embedded CPUs / SOCs have cryptographic support eg the ESP32. You can buy one for less than $10.
Here are two examples:
- client initiated: a browser-based Single Page Application can give the server a public key so that it, and only it, can read a message encrypted with the key and returned by the server.
- server initiated: a server gives a public key so that it, and only it, can ever read a message encrypted with the key by the client.
sequenceDiagram
User->>SPA: Clicks form "Send" button
SPA->>SPA: Produce temporary key pair
SPA->>Service Instance: Make data request, includes public key
Service Instance->> X-Y-Z: Do X-Y-Z to get data
Service Instance->>Service Instance: Encrypt data using public key
Service Instance->>SPA: Send encrypted data
SPA->>SPA: Decrypt using private key
SPA->>SPA: Destroy temporary key pair
SPA->>User: Show decrypted data
More examples and documentation notes are in the Client key documentation.
sequenceDiagram
User->>SPA: Clicks form "Send" button
SPA->>Service Instance X: Request key (GET)
Service Instance X->>Service Instance X: Produce temporary key pair
Service Instance X->>Storage: Save key, expires in N seconds
Service Instance X->>SPA: Send public key
SPA->>SPA: Encrypt secure data with public key
SPA->>Service Instance Y: Send encrypted data (POST)
Storage->>Service Instance Y: Retrieve key
Service Instance Y->>Service Instance Y: Decrypt message using private key
Service Instance Y->> X-Y-Z: Do X-Y-Z
Service Instance Y->>SPA: Success message
SPA->>User: Confirm card creation
SPA->>SPA: Destroy public key
Time->>Storage: Key deleted after N seconds
More examples and documentation notes are in the Server key documentation.
Message Secrecy
Strict Confidentiality to a single user
Proofs (as an add-on)
Identity (as an add-on)
Java 11+ (tested with 17 and 21)
Clojure
clj -X:clj:test :dirs '["jvm/test"]'NodeJS 16+
npm installnbb -cp js/src:js/test -m nextjournal.test-runner -d js/testnbb -cp src:test -m interactive.server.web