Re: crypto-lib Proposal Update
Thanks for the feedback! Either here or on the Google doc is fine. If you have direct suggestions, feel free to comment them in to the Google doc so we can merge them correctly.
I’ll try to address your questions and comments here:
1. Tiering is always going to be somewhat of a judgement call, particularly between tiers 2 and 3. Post-quantum algorithms are a good example of this, and I think (in my opinion) some might go either way. For instance, I would put Frodo (an LWE-based key exchange that is extremely conservative in its parameter choices and has had an open implementation for quite some time) clearly in tier 2. On the other hand, I would put something like WalnutDSA (a braid group-based signature algorithm that has had many parameter changes over the past year) in tier 3. It wouldn’t be unreasonable for maintainers to have disagreements on tiers for certain things, so we would have to vote on tier issues. However, I think that most of the stuff that we will begin with should be clear.
2. Yes, this is a good point. I’ll make this change.
3. Ah, the joys of UC-security. The “theoretical maintainers” should block any pull requests that combine things in such an insecure manner, since any such mechanisms use crypto in a non-black box manner. However, you do bring up a good point: standardized APIs are really nice (that’s actually the goal of the base crypto-lib signature library!). We hope to coalesce into simple APIs that are universally adopted throughout the project, but we think it will hinder development and adoption if we force people to use certain APIs at the start of the project. Backwards compatibility with existing projects is another reason why we can’t standardize APIs completely—we would like to have an API that all of the new stuff uses, but backwards compatibility breaks the old stuff. I guess, to summarize: we hope that some kind of de facto API Council is formed, but we don’t want to mandate it right now because we think it might hinder adoption and development.
4. Yes, that’s a good point. While I’m perfectly comfortable saying that rolling your own hash functions is “incredibly foolish” and having that enshrined and public, I have replaced that phrase with “poor.” In addition, sadly the FAQ about the dunking booth will have to go before the document is finalized…
5. The base lib project is planning to incorporate shims to many different languages. I think that there are many people interested in a Golang interface, so I imagine this will get built. As the project matures, I imagine we will have more discussions about safe languages. I think this is also why many people involved in the project are really excited about Rust.
6. Tier 0, clearly! ;)
I hope this cleared things up. Let me know if you have further questions or comments.
Sent: Tuesday, October 30, 2018 2:07 AM
To: Montgomery, Hart <hmontgomery@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] crypto-lib Proposal Update
Hi Hart, all,
Hope this is the right forum for feedback: if I should be on the wiki or inside the Google Doc just let me know and I’ll shift over.
By and large, looks great, and I appreciate the clear thought that has gone into making this a practical and actionable structured project.
I have a handful of comments/questions:
1. The tiering between 2 and 3 is not completely clear to me in one regard: specifically, we’re talking firmly in tier 2 about things in that are used (widely?) in practise, but then tier 3 goes right to science experiments. What do we do with things like leading post-quantum algorithms that are relatively well known and trod but are not yet standards approved and are still being refined? Would such things default to tier 3 and then be promoted when we’re happy with the implementation? Or default to tier 2 and then be taken out if they’re judged dangerous?
2. I appreciate (and agree with) the intent of the ‘overwhelming consensus’ requirement for doing important things, but as time goes on and people come and go I’m concerned that such loose language could cause unnecessary controversy at some point. Why not define this more concretely as 2/3 super majority or similar as it is later on in the doc? Note that this also implies a requirement to manage the voting eligibility of members, but ‘twas ever thus.
3. Since sub-projects are defined essentially as creating code modules for people to incorporate into their super projects, we should assume that dependent super projects will incorporate a number of these modules in order to satisfy all their Crypto-related needs. It follows therefore that there’s a clear need to ensure that (most of) those modules follow a consistent architectural pattern, implement the same API Design philosophy, and very strictly agree on the semantics and data typing of parameters that may be shared, or at least commonly expressed, between them. Apart from the obvious programming sanity requirement here, we’ve all seen plenty of cases where plugging together 2 secure things makes one big insecure thing. Who/what role will do this? It’s good that the sub projects are independent and self-governing most of the time but Inthink something like an API Council is required here.
4. Assuming this proposal will at some point become enshrined and semi-public, it would probably be polite to replace the “incredibly foolish” language. You’re right, but still. Optics.
5. I want a Golang version. Would that be a subproject shim, or just a separate output of the one base lib project?
5a. I’d like a discussion about safe languages in general, but that can happen in slower time.
6. What tier of Project is the dunking booth? It doesn’t seem to quite fit any consistent set of the criteria for any band.
On Mon, Oct 29, 2018 at 11:55 PM +0100, "hmontgomery@..." <hmontgomery@...> wrote:
First of all, thank you all for the feedback during and after the TSC meeting last week. It was good to hear suggestions from people, particularly those that are open source veterans.
We have incorporated most of these suggestions into a new draft of our crypto-lib proposal. Please take a look—we’d love more feedback. In particular, we thought Chris Ferris’s suggestion to eliminate the steward position and instead rely on maintainer lists was a good one, and it is reflected in the current proposal.
Here is the link: https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing
Thanks a lot for your time, and have a great day.