-
Notifications
You must be signed in to change notification settings - Fork 11
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
plans for v3.public #40
Comments
Sorry for the late response. I don't have any plans regarding v3.public currently. I haven't been needing it myself, nor has anyone requested it. Is this something you'd want to be using? If so, I can look further into it. |
It is not a late response. It is your project, you can respond when you have time and want to. Thank you for making the project and responding to my question! I have a use case for it. The context is the conversation starting at rust-lang/rfcs#3139 (comment) |
I have some questions I'm hoping you could clarify upon a bit.
Also, just out of curiosity, do you already know what hardware tokens you'll be using for storage? |
Fundamentally I do not have a security background. I will do my best to answer, but they all come with "I don't know until I talked to my security expert".
Confirmed. The "local" is for an entirely different use case.
I don't care, but I will have to talk to a security expert.
I don't quite know what these words mean, but I don't think I need any particular format for the public key. We can document whatever the code does.
That sounds interesting! Do you have the link?
No. It is a "bring your own hardware" situation. If we had control over the hardware we would use v4, and give people compatible hardware. |
Compressed public key is a X-coordinate for the point on the curve along with a parity bit for the Y-coord. So instead of storing a (x,y) pair, you store parity || x, and compute Y when needed for signing/verification. Hope this helps in clarifying a bit. Sorry if it's too jargoned. Re encoding, it's the one called PASERK. I'm on mobile atm and can't get the link so this reference will have to suffice until I can. PASERK link in bottom of PASETO spec README. |
From the sound of it compressed works just fine for our needs. PASERK. I have heard of that. I don't know if we will be needing it, I will be asking the relevant security experts later today. |
I've started the work for compressed points and PASERK encoding. |
Thank you! |
I have a working implementation of both A note: I cannot at the time support deterministic nonces, which PASETO recommends. The only suitable P-384 implementation currently available seems to be ring, which doesn't support this. However, I've seen work on this elsewhere, e.g RustCrypto, but the P-384 implementation there is not ready yet. When it is, I will probably switch to that one but I don't know when this will be. My plan so far is to do a pre-release |
Thank you so much! I look forward to experimenting with your prerelease as soon as it's out. I will talk to my neighborhood cryptographers about deterministic nonces, before we stabilize this for production. |
I've published the Feel free to let me know if you find something you'd like revised. Another thing that crossed my mind, since you asked for the ID operation: Are you going to be putting these into the footer of the tokens? If yes, I've had plans to make a typed implementation of a footer, which may be of use to you in that case? In any regard, I don't know when that could be added, since it's not the biggest priority currently. |
Thank you! I look forward to giving it a try! I am putting the ID in the footer. But, I am happy to work with an untyped API. Improvements are welcome when they're ready. |
I'm leaving it with an untyped API for now then. I'll put up a PR for final review today and expect to have the release of One thing to note is: The PASERK ID operation is currently used with a |
I'm sorry I had other work come up and have not had a chance to test your pre release. |
No problem. I'll hold off the release until you've been able to give it a try then. |
So I have tried to use this and I am starting to have some feedback. https://docs.rs/pasetors/0.5.0-alpha.2/pasetors/index.html#creating-and-verifying-public-tokens Next I wanted to follow the worked out examines in https://rust-lang.github.io/rfcs/3231-cargo-asymmetric-tokens.html#a-complicated-publish-operation I successfully round tripped a Paserk PublicKey into a I was not able to verify the token:
I think the problem is that the My the way how do I go from a Next how do you get the |
First of all, thanks so much for taking the time to provide valuable feedback. It really means a lot! This got a bit lengthy, apologies for that.
|
This is getting long, should we open up separate issues about each thing?
That sounds much more ergonomic! This does not prevent leaving in the code path that uses the dependencies directly, if there are user controls that are better offered by going to the dependencies. But a
If
So we have a full matrix of
This is not too bad, but unfortunate considering the library already has the code to do this.
I really like this idea!
Given the shape of your API, this was the method I checked the docs to see if you had. It also lets you only provided where the underlying crypto library makes it available.
The design document assumed this method would be available, and so does not call for the public key being stored. It can be stored in the users config file, but it opens up possibilities of somebody tampering with their config files and having them no longer match. This can definitely be worked around for now, but I would really like to have it fixed before this functionality is stabilized.
That makes perfect sense! Hadn't thought of it. |
I have created separate issues for the three different topics. I assume the footer discussion will eventually "merge" with
Not sure I fully understand everything here. This library requires a constant-time compare of footer values if the user supplies
I don't see the difference between checked footer and trusted footer. In |
I think I am paying more attention to performance for my one use case than is quite appropriate. The API you propose can work for me, and further optimization is probably not needed. |
I'll close this issue. All discussed points have either been merged into the prerelease branch If anything is still missing, I can re-open it. |
…cx/pasetors#40 so maybe wont become abandonware.
…tors Cargo uses Pasetors?: brycx/pasetors#40 — so maybe it'll be maintained for quite long.
What is your plans re v3.public will you be supporting it? If so do you have an ETA?
The text was updated successfully, but these errors were encountered: