Skip to content

API: minor corrections after beta 2 #83

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

Conversation

gilles-peskine-arm
Copy link
Collaborator

@gilles-peskine-arm gilles-peskine-arm commented Mar 11, 2019

  • Minor corrections noticed after beta 2 was finalized.
  • Specify psa_generator_import_key for most key types.

Validated by

perl -ne 'if (/^\/\*\*/) {%param=(); @p=()} if (/\\param.*? (\w+)/) {$param{$1}=1} while (/\\p \*?(\w+)/g) {push @p,[$1,ARGV->input_line_number()]} if (/^\ \*\//) {foreach (@p) {if (!$param{$_->[0]}) {printf "%s:%d: bad \\p %s\n", $ARGV, $_->[1], $_->[0]}}} close ARGV if eof' include/psa/*.h
@gilles-peskine-arm gilles-peskine-arm added writing Documentation wording and formatting api-spec Issue or PR about the PSA specifications labels Mar 11, 2019
psa_generator_import_key() was only specified for "symmetric keys",
and there were some mistakes in the specification. Rewrite the
specification and extend it to other key types.

* For most private key types, specify that the function draws a byte
  string repeatedly until the byte string is suitable.
* For DES, despite being a symmetric key type, re-drawing is
  necessary.
* For Montgomery curves, despite being asymmetric, no re-drawing is
  necessary.
* Specify the behavior for every standard key type other than RSA.
  An implementation doesn't have to support all key types, but if it
  does, it's better to have a standard.
yanesca
yanesca previously approved these changes Mar 11, 2019
Copy link
Collaborator

@yanesca yanesca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

For DH, ECC (Weierstrass curves) and DSA, specify that the re-drawing
method is the one defined by NIST as
"key-pair generation by testing candidates", and describe it
unambiguously.

Also specify DES explicitly.
* (the prime *p* for Diffie-Hellman, the subprime *q* for DSA,
* or the order of the curve's coordinate field for ECC).
* Add 1 to the resulting integer and use this as the private key *x*.
* This is the method described as
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The method described in the standard is more relaxed in some cases (for example when generating DH keys the standard allows going for shorter private keys than the size of the prime). I think writing something like "This method allows for compliance with NIST and FIPS standards, see:" would be more accurate.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tweaked the wording.

* in big-endian order. Discard it if it is not in the range
* [0, *N* - 2] where *N* is the boundary of the private key domain
* (the prime *p* for Diffie-Hellman, the subprime *q* for DSA,
* or the order of the curve's coordinate field for ECC).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case of ECC the boundary is the order of the curve's base point (here I use the term curve in the sense of the set of cryptographic domain parameters and not as a mathematical object, but I assume that is what we do throughout this documentation).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Fixed, thanks.

* Add 1 to the resulting integer and use this as the private key *x*.
* This is the method described as
* "key-pair generation by testing candidates"
* This method allow compliance to NIST standards, specifically
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: allow -> allows

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amended

@gilles-peskine-arm gilles-peskine-arm force-pushed the psa-api-1.0-beta-beta2_minor_fixes branch from 431ea53 to 5579971 Compare March 12, 2019 10:54
yanesca
yanesca previously approved these changes Mar 12, 2019
Copy link
Collaborator

@yanesca yanesca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@gilles-peskine-arm gilles-peskine-arm merged commit 9b542de into ARMmbed:psa-api-1.0-beta Mar 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-spec Issue or PR about the PSA specifications writing Documentation wording and formatting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants