CCL draft RFC

[dhuseby]

This is the draft RFC for the Cryptographic Construction Language (CCL) for encoding cryptographic constructions in a self-describing way that is independent from the underlying crypto library.

Signed-off-by: Dave Huseby dhuseby@linuxfoundation.org

[danintel]

I don't see the changes, but I'll assume they have been made and are stashed somewhere.

[dhuseby]

@danintel There are three commits in this PR. I addressed your feedback in the second commit ---4cf6391 --- and then later added some minor clean ups in the third commit.

[danintel]

@dhuseby: I saw the multiple commits. Usually the commits are aggregated under "Files changed". I'll look again.

[jaromil]

If I understand well your value proposition, you may want to acknowledge Zencode as prior art:

• https://dev.zenroom.org/Zencode
• https://zenroom.org
  We already use it connected to an hyperledger product.

[dhuseby]

If I understand well your value proposition, you may want to acknowledge Zencode as prior art:

* https://dev.zenroom.org/Zencode

* https://zenroom.org
  We already use it connected to an hyperledger product.

I have been reading LangSec papers for years and, like zenroom, a lot of the thinking is inspired from there. However, after looking at Zenroom and Zencode, it isn't an inspiration for CCL. CCL isn't about the VM, it's more about a uniform way to serialize crypto constructs. Crypto constructs almost always consist of some data and some implied processing of that data to validate, verify, authenticate, encrypt, decrypt, etc. CCL acknowledges that fact and explicitly encodes the processing along with the data. Using a stack machine as the "VM" for executing the CCL encoded constructs just simplifies things and drastically limits attack surface area by allowing for a non-Turing-complete deterministic DSL to be used.

[jaromil]

Thanks for the clarification! I'll be following the CCL specification with great interest.

[mikelodder7]

No XChaCha20Poly1305?

[mikelodder7]

Keccak?

[mikelodder7]

Do we want to support any ECIES methods like libsodium's secretbox and sealedbox?

[dhuseby]

XSalsa20Poly1305 is libsodium's SecretBox. In the v0.1.0 version I left out the SealedBox but if you look at the CCLang repo you'll see that it would be trivial to add new construct primitives.

[mikelodder7]

Love this idea. Just some minor things to include and I think we’ve got a good start

[dhuseby]

I just published v0.1.0 of my CCLang implementation. I scaled back on some of the algorithms to get a MVP. The repo is here: https://github.com/dhuseby/cclang and the crate page is here: https://crates.io/crates/cclang

[dhuseby]

My hope is that CCLang will stop using sodiumoxide as it's crypto library and instead be built into Ursa and use Ursa's API while also integrating with Ursa's build system so that depending on how Ursa is built, the CCLang algorithms and underlying primitives are set up accordingly. This would allow consumers of Ursa to use CCLang in FIPS mode or "open crypto" mode or with any of the restricted sets of algorithms and underlying crypto libraries.

[dcmiddle]

I gather this should be closed now?