6 ms·

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

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#L5 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.

brachi 7y ago
> No tests yikes, that's hard to justify.
- javert 7y ago
  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.
  - jMyles 7y ago
    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?
    - javert 7y ago
      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!
  - sverhagen 7y ago
    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...
    - javert 7y ago
      It's not a "product." It's an academic research paper.
mskd12 7y ago
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!
- sverhagen 7y ago
  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.
- dkoston 7y ago
  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.
- dkoston 7y ago
  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!
  - mskd12 7y ago
    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!

brachi 7y ago

> No tests yikes, that's hard to justify.

javert 7y ago
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.
- jMyles 7y ago
  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?
  - javert 7y ago
    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!
- sverhagen 7y ago
  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...
  - javert 7y ago
    It's not a "product." It's an academic research paper.

mskd12 7y ago

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!

sverhagen 7y ago
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.
dkoston 7y ago
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.
dkoston 7y ago
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!
- mskd12 7y ago
  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!