Comment by dkoston | Hacker News Reader

Comment by dkoston | Hacker News Reader

Not sure if OP is the author but thanks for sharing. Secret management is a challenge for a lot of folks.

For the authors, here are a couple of items that made it hard for me to evaluate the project:

1. This project doesn't build for me and some of the dependencies don't exist or are private repos which prevent me from building the project (https://github.com/CHURPTeam/CHURP/blob/master/src/cmd/bb.go...)

2. It's lacking godoc documentation which means it's hard for me to quickly see how the API works. As such, some of the API methods seem less than useful.

For example, `(Optional) storeSecret(SK)`. What does "optional" mean? What's the return value? What's SK?

(Optional) retrieveSecret() -> SK: What? I can only store a single secret? Without passing params to this, it seems so.

3. Project structure is not conventional (cmd/ inside src/)

This may not seem like a big deal but am I really going to trust my secrets without someone who didn't learn enough about go to use godoc and use a conventional project structure?

4. No tests

Again, doubtful I'm going to trust my secrets to a distributed network that's not tested.

One of the authors of the work here.

1. Thank you for your comments. The project is an early-stage research prototype, and we are soon going to add documentation and tests to the code.

2. In fact, not all functions in the API are fully implemented, the development is under process. At a high level, the functionality provided is to store and retrieve a secret key (SK). The function is denoted optional because in practice, the secret might not be inputted, instead it might be generated randomly.

3, 4. We appreciate the comments. At this point, we’re still adding more features and improving the documentation. We plan to release the code with tests in the future.

PS: Just added a disclaimer stating that the code is under development!

I know that this isn't universally accepted, but in significant parts of the industry, we consider it vaporware if there's no tests... FWIW.

Appreciate the disclaimer.

One of the challenges you are facing is that people consume software illogically based on marketing and popularity rather than code review and fit.

Making sure to market and disclaim that this is a research implementation and should not be used in production is important, especially in cryptography where most people are novices and wouldn’t be qualified to review the code either way.

For #2, it seems unlikely that people would have a single secret.

I’m not sure if the codebase is more just to prove the concept from the paper or to potentially get adoption. If you are looking for people to adopt the project, I’d suggest a way to store and retrieve multiple secrets.

Best of luck with the research and project!

In many scenarios, I'd think that different user-specific secrets can be derived from the single secret stored, perhaps using a PRF. Why wouldn't this be enough?

Thanks!

You can use a PRF for the domain to derive additional secrets. It simply depends on the scope of the project and who you think your users are.

For example: if your user base is cryptocurrency wallet holders who have multiple secrets for each wallet, will they construct a secondary library on top of yours to manage those additional secrets? Why wouldn’t they choose to derive each secret independently? If millions of dollars are at stake, would you risk any shared state from your secret derivation function?

It would be unnecessary to derive additional secrets with this library to prove the concept in the paper so I don’t think it’s necessary if that’s the goal of the code. However, if mass adoption of the techniques you’ve created is your goal, a more user friendly API which doesn’t require each end user to “roll their own code” to manage multiple secrets should be a goal.

One of the first major projects I worked on was essentially a wrapper around open source software that provided “ease of use APIs and UIs”. Because the average user was not technical, the convenience wrapper became highly valuable and is used by hundreds of millions of sites today (cPanel).

One of the biggest challenges as a technologist is to understand to what degree most people are not technologists, even fellow programmers. For example, I’ve worked with skilled programmers with impressive resumes who had issues troubleshooting CORS because they never learned how headers are defined and where to look up the RFCs.

As mentioned above, providing an API for multiple secrets could be out of scope for a bunch of reasons. If you’re looking for mass adoption by developers, I’ll wager an Omakase at the sushi place of your choosing that it’ll be required.

> No tests

yikes, that's hard to justify.

No, no it's not. The product here is an academic paper. The code is just kind of a sanity check for the concepts in the paper. That's how academia works.

I don't really agree that "that's how academia works". What other recent reference papers for cryptographic primitives are you thinking about when you say that?

I don't have any in mind, but this paper struck me as being in "distributed systems" more than in "cryptographic primitives." That is totally debatable, though.

Anyway, I have experience in the former field (and adjacent fields) but not the latter, so that's where my cynicism is coming from, if you are wondering.

You are probably right that there are higher standards for papers dealing with cryptographic primitives. That would be nice!

If you're positioning it as a product, which is how many here perceived it, that reasoning doesn't hold. Not that every product has good testing, but they should...

It's not a "product." It's an academic research paper.

Reply on news.ycombinator.com