Clarification on scope #1
Comments
|
Much of that should fit both into what I've already thinking and algorithms I immediately want to support. You can take a look at the Rust implementation: Here's what it presently includes:
(Sidebar: perhaps There are four algorithms presently supported: EncryptionAES-128-GCM
AES-256-GCM
SigningEd25519Secret Key
Public Key
Signature
DigestSHA-256
Will post a second comment with some point-by-point followup on specific algorithms. |
|
To break down what you've requested: (Unauthenticated) Stream Ciphers
I have been mulling whether including an intended algorithm usage for a key is a good idea, and generally been leaning towards yes (see above for Prospectively these would be e.g.:
(Sidebar: split symmetric encryption into a namespace? e.g. (Elliptic Curve) Diffie-Hellman / Key Exchange / Key Agreement
My first thought is: static or ephemeral? For CryptoURI, I'm not sure anything but static keys make sense, and if we only have to worry about one, we don't need to encode the distinction into the key format itself. So something like:
(Sidebar: should D-H be split into a namespace? e.g. Message Authentication Codes
Isn't a MAC! 😉 It's a universal hash function and therefore useful as a one-time authenticator, however MACs generally operate over multiple messages. Poly1305-AES provides this property. Perhaps:
...is a more interesting one, and should use the digest/hash algorithm registry for identifiers. Some prospective syntax:
AEAD modes
Would suggest:
Already spec'd
This is a particularly fun one in terms of combining it with other constructions. I think an interesting one to look at is how we might represent keys for the Google Tink instantiation of an AES-GCM STREAM mode, which uses HKDF to derive a per-stream key. Some ideas for the Tink STREAM case:
Password Hashing Functions
These are particularly fun in terms of both how complex they are and how URI syntax might permit something a bit friendlier than the extended The first question is what do you want to represent as a CryptoURI in regard to them? I think the main use case is a stored password digest, which would include a salt and the algorithm-specific parameters used to compute it. Here's an example of a prospective PBKDF2 digest:
Digest AlgorithmsThese are straightforward enough. As mentioned earlier, this one is already implemented:
|
|
I think it might be worth making GitHub issues relevant to each of these topics so we can discuss each of them in more depth. |
|
Yes, let's split up topics into issues, but before we get going, I want to finish clarifying the basics: Essentially, it boils down to: What are cryptouri's, what do they represent exactly? As I understand, there is typed cryptographic material, which can be a public or private key, a secret, a signature or a hash, where you have:
But then I am confused when you start with something like this, as if your trying to put a key and how to use it into a single cryptouri: And then, go one step further, adding a protocol to cryptouri:
I guess this would resolve some of my confusion, though To repeat my question: What are cryptouri's, what do they represent exactly?
(sorry for all the questions 😉) Maybe, to put it another way: I am missing a list of "Why cryptouri is so awesome and everyone should use it". I mean, I can see the benefit of this, because I started to define algorithm names and data formats and stuff and it was hard, so joining efforts with others will give me a better result at creating something maintainable and non-confusing. Maybe a good place to help me understand, is to think about usage scenarios. Are there any available already? Quick new ideas for namespaces:
Just a braindump, take what you like, leave the rest. Last thing for this comment:
I am by no means a real expert in this area, so I am extremely cautious how I use and combine cryptographic algorithms. I use the Go extended stdlib here: https://godoc.org/golang.org/x/crypto/poly1305 DJB writes in his paper: "There is nothing special about AES here. One can replace AES with an arbitrary keyed function from an arbitrary set of nonces to 16-byte strings. This paper focuses on AES for concreteness." How I use the poly1305 package: Every operation has its own unique nonce in addition to the main key material. They are both fed into a key derivation function which generates a key for every gear in the process of doing whatever cryptographic operation. Currently this would mean that I use something like Poly1305-HKDF, but I still treat Poly1305 itself as a MAC function, and I think this is correct. I now carefully re-read your statement after writing all that. I probably wouldn't have, if I had read it that carefully the first time. So in your eyes, I'd be using Poly1305-HKDF, so we basically agree afterall? 🤓 |
A namespace of cryptographic objects, formatted to be friendly to human interaction/consumption/transcription. These objects are all effectively numbers (typically very large numbers) or sets thereof. I'd personally consider them URN-like, in that they are a self-contained, location-independent representation of a unique identifier within a particular namespace. Some prior art and inspiration can be found in RFC 6920: Naming Things with Hashes, which introduced a CryptoURI is an attempt to generalize this notion to commonly used cryptographic objects in a way that both conveys their sensitivity in a standard manner ( The primary immediate focus is cryptographic key types, notably secret keys. In that regard, CryptoURI can be seen as an alternative to formats like PKCS#8, JOSE JWK, or numerous bespoke secret key encodings (e.g. SSH). Ideally it can provide a feature set equivalent to PKCS#8, including this like encrypted key storage and even password-based encrypted key storage using modern algorithms. For digital signatures, it can be seen as an alternative to Cryptographic Message Syntax (CMS), various other ASN.1 DER-based encodings, or JOSE JWS. RFC 6920 was interesting in its usage of the hierarchical features of URIs. Though I don't think I have any examples of this anywhere, a longer-term goal of CryptoURI is to support hierarchies of cryptographic objects, e.g. derivation paths. These are still URN-like in that they're location-independent: any bearer of a CryptoURI with hierarchical features can modify a derivation path, hand it to a conforming implementation, and get another CryptoURI for the derived object. An example of such an algorithm is "HKD32", an extraction/simplification of BIP32 (which can be used as the core of a conforming BIP32 implementation)". Given that, you can imagine representing a key derivation hierarchy for AES keys as follows. Non-hierarchical: Hierarchical: or in practice something like Hierarchical usage patterns are the main motivation for having a URI-like syntax in addition to the "dasherized" syntax: while the latter may be more convenient in a number of contexts, its more simplistic notation will also necessitate a more constrained set of usages, and expressing complicated things like derivation hierarchies seems like it will be difficult to keep unambiguous.
That concern is literally what I opened with 😉 "I have been mulling whether including an intended algorithm usage for a key is a good idea, and generally been leaning towards yes (see above for So there is a debatable issue here: how much algorithm information should be encoded into each CryptoURI? Salsa20 and XSalsa20 use identically sized keys, so why should a CryptoURI encode This gets back to the human interaction/consumption/transcription issue. By encoding more information about how keys should be used, it makes it easier for e.g. security teams making keys to specify intended usages in a way which software implementations can verify. A higher degree of specificity also enables things like a 1:1 mapping of CryptoURI algorithm identifiers to their IANA-assigned OIDs, for example.
It depends on if you want a short term goal or pie-in-the-sky. Pie-in-the-sky:
Short-term goals:
Absolutely. But perhaps beyond readability, I think "comprehensibility" is important. As stated above, the format should make it easy for anyone, even people who don't know any of the algorithms they're looking at, to be able to understand they are looking at something which is particularly sensitive/secret (i.e.
As I sit here with manually transcribed secrets in front of me, yes it's something I very much want to support. For context to any third party readers out there: the current implementation of CryptoURI uses Bech32, an ASCII encoding for binary data (ala hex/base32/base64) but with an alphabet engineered to reduce transcription errors, and also an associated checksum (ala a Luhn check) to detect transcription errors. This adds a small amount of overhead to the encoded data, which does come at a cost. The benefit is general resilience to transcription errors over lossy media (or at least, the ability to detect them), be that manually transcribing them between devices by typing, reading them out over the phone, or writing them down.
I'd say succinctness is a secondary goal to human-friendliness, in that shorter strings are easier for humans to work with.
CryptoURI is very much intended to be a text format. I am a big fan of binary formats too, but I think the solution there is to have precise and well-understood mappings to existing binary formats. To that end an algorithm registry should maintain a set of 1:1 aliases to existing algorithm identifiers, to facilitate an uncomplicated mapping of e.g. Done correctly, that should just be looking an OID up in the CryptoURI algorithm identifier registry, and serializing the decoded Bech32 binary object. re: the rest of your post, I think I can open a follow-up issue which can serve as a starting point. |
|
As a hierarchical namespace, I think we can break this problem down hierarchically so we're not talking about a dozen things at the same time: That said, I think it's still helpful to have a thread like this one to talk about the bigger picture. |
|
Thanks for the thorough answers (and repeats), I think understand what CryptoURI is trying to achieve much better now - and like it much more. Also, I am starting to realize how big this is going to be and will move to gradually supporting CryptoURI instead of fully switching to it now. I think this approach will allow us to take time to carefully define the details, instead of hurrying through the process. This does not reduce my ambition to contribute in any way. I will continue with issue #2, and further deepen my understanding until I start opening other issues. |
Hey Tony,
As discussed on Twitter, I am interested in using cryptouri for a cryptographic library.
I am not yet entirely sure if cryptouri fits what I expect from it, so here is what I would want to do with it.
Please tell me if that is possible and what you think about using cryptouri for this.
So, this library I'm building is kind of a framework library where you can plug together the algorithms you want to use and it combines them correctly.
Before doing any operations, the library checks that all needed components are available in order to fulfull C-I-A. It can do single operations on data or be used for a communication channel (w/ double ratchet and key rotation).
The library is almost finished in its first version will be professionally audited in October or November.
Currently, all these plugins have a unique name, which I am seeking to replace with a cryptouri equivalent:
Symmetric Algorithms:
Assymmetric Algorithms:
MACs:
Combined Algorithms:
Other:
Hash Algorithms:
Secondly, these data types would be great to have a standardized cryptouri format for:
Also, on a side note, it would also be interesting to use these formats in messages and headers, in an albeit more compressed format and without integrity checks.
The text was updated successfully, but these errors were encountered: