-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Organization and naming issues #10
Comments
Long issue, in general, it would probably be easier to address these as
Off topic: I'll admit, I'm jumping into these questions being 6 months On Sat, Jan 10, 2015 at 11:22 AM, Bryan Ford notifications@github.com
|
Great, thanks for the feedback. (And anyone else is welcome to chime in too.)
There is still support for integer groups - see crypto/nist/residue.go. I think it’s probably worth keeping this in the library at least for now but I’ve been considering integer-group support to be increasingly “deprecated” since ECC has matured and most everything interesting is gradually shifting that way. I’d certainly be open to a less purely ECC-centric name for the library though (“Charm” is certainly suitably generic). Another idea that occured to me is “crykit” - which could be pronounced like either “cricket” or “cry-kit” - just meaning an advanced crypto toolkit. But if you or anyone has better naming ideas, by all means please suggest them.
The nice thing is that with this framework, as far as I know, the high-level crypto functionality like Neff shuffles are completely portable across groups, and there’s already significant functionality in the library to test these functions against multiple groups (e.g., NIST curves versus Edwards curves versus integer residue groups). I definitely want to maintain that.
What exactly is the “this” that you’re saying is “a bit tricky”? And what are “these nuances” that you’re referring to? What extra code? What “nearly identical code” do you have in mind that can/should be reduced?
What would make more sense? I think you’re neglecting to preserve some critical context here.
I settled on the name “Pick” mainly because it seemed to express the idea (picking a group element or curve point, picking a secret), and was shorter and simpler than “GenerateRandom”. :) I’m tentatively in favor of normalizing the argument signature one way or another, perhaps by adding (very simple) data-embedding support to the Secret interface.
Sounds good, thanks. We don’t need to make decisions on these items quickly; just wanted to get them out there and we can plan how and when to address them for real later. B |
Revert "Coco refactor"
@ineiti @nikkolasg I just wanted to remind you about this now quite old issue, which brought up a number of questions to consider related to reorganization and stabilization of the crypto library. Some we're already on top of (e.g., renaming the top-level), but there are others that I'm not sure we've actually resolved yet (e.g., consistent argument ordering and Pick methods etc). |
I'm definitely OK with that.
I'm definitely more for the c) option. Having |
Agreed on most of the above. On the proliferation of "bytes-level methods": I agree that this is a concern in principle, but in my current understanding these three sets of bytes-level methods each address real and semantically distinct needs. In my understanding:
|
This should be copy/pasted to the documentation! |
Yep I agree with all of the above. And for the moment, let's continue like that but one way to reduce the size of the interfaces would be to do that |
I realized while implementing it that we don't need a |
This issue is more complex than I thought, I'm realizing it while trying to code it... |
I'm closing this issue as most of its items have been implemented in the sub-issues listed in #151 |
higher threshold / n for resharing
There are a number of naming and package-structure changes that probably need to happen at some point, but they'll be somewhat invasive and touch a lot of code, and I'd like to get some discussion and feedback on these before committing to any of them. Roughly from highest-level to lower-level:
More such possible changes might come to mind, which I'll add to this thread as they do, and feel free to suggest others. I'd like to decide on a batch of such invasive changes and apply them about the same time, to minimize the painfulness of updating all the code that depends on these. Thanks.
The text was updated successfully, but these errors were encountered: