Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Two questions about ssh-jce #8

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

Open
vonagam opened this issue Mar 7, 2017 · 2 comments
Open

Two questions about ssh-jce #8

vonagam opened this issue Mar 7, 2017 · 2 comments

Comments

@vonagam
Copy link

vonagam commented Mar 7, 2017

KeyFormat.SSH_RSA has Algorithm.SSH_RSA as the first candidate for algorithm, but it is not supported by node-http-signature:

Arrays.asList(Algorithm.SSH_RSA, Algorithm.RSA_SHA1, Algorithm.RSA_SHA256, Algorithm.RSA_SHA512)

https://github.com/joyent/node-http-signature/blob/529441d9d04a8ecb296a2a152929332526344673/lib/utils.js#L13

For this to work without algorithms rotations, i do the following after a signer creation:

Collection<Algorithm> algorithms = Collections.singletonList(Algorithm.RSA_SHA256);
Challenge challenge = new Challenge("<preemptive>", Constants.DEFAULT_HEADERS, algorithms);
signer.rotateKeys(challenge);

Is this how it is supposed to be used? Can't there be more "out of the box experience" for this?

Why SSHKey here must have public key?

It seems that presence of methods like canVerify and checks in verify method itself should prevent invalid use. Just curious. Use case is that a key used only for signing, not verifying.

@adamcin
Copy link
Owner

adamcin commented Mar 7, 2017

  1. The SSHKey piece is what I was working on independently before I refactored to support the Joyent spec, so the default primacy of the ssh-rsa algorithm is an artifact of that. I haven't had much feedback from users outside of my own tooling ecosystem, so the ergonomics of this library have not really followed the node-http-signature implementation very closely. I'm happy to keep incorporating your feedback as long as you are actively using this library. I can probably safely change the default signature algorithm for ssh keys to be rsa-256 or rsa-512 to match whatever is most commonly supported to reduce the need for rotation requests.
  2. I think the reason for requiring the public key in the constructor is that it is necessary to compute the key fingerprint. Looking at it now it doesn't make much sense to have that error message there.

@vonagam
Copy link
Author

vonagam commented Mar 8, 2017

  1. You can also add another two values to enum. Like DSA_SHA and RSA_SHA which would have only corresponding algorithms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants