Integrate OAEP and PSS into existing interface #43

dignifiedquire · 2020-03-06T20:13:05Z

This integrates #18 and #26 by expanding the use of PaddingScheme to capture all optional values for the different schemes.

It is not ideal, but it works well and keeps in line with the existing API for now. I think we should still continue to improve on the api and think through #34 more, but in the meantime this a version that folks can start to use, and isn't too different from the existing api

Removes the PublicKey trait, using Deref to provide the RSAPublicKey methods to RSAPrivateKey.

Test assertion is manual and done with openssl

str4d · 2020-03-06T21:06:07Z

Hmm, pulling in 2462f1d from #18 goes in the opposite direction to #42. It looks like the main thing it does (remove PublicKey trait) is not present in the overall PR, and I can't find where that is undone, but I think it's in the refactor commit? GitHub isn't helping much here. There are other effects of that commit that are not undone (in particular, it makes public keys non-generic in pkcs1v15, the opposite of what I've done in #44).

How painful would it be to just drop that commit entirely? It would likely make the history clearer.

str4d · 2020-03-06T21:10:17Z

Hmm, the change in that commit to store an RSAPublicKey inside RSAPrivateKey does make sense to me. I'd personally alter that commit to only contain the pieces we want, but that's probably more hassle than it's worth, so just reverting changes we don't want is probably fine.

dignifiedquire · 2020-03-06T21:14:29Z

Yeah, I changed a lot of things during the merge, which is..unfortunate. So at this point I am thinking of squashing this into two commits at the end likely (1) for oaep and (2) for pss, after doing/undoing all things we want to do.

dignifiedquire · 2020-03-06T22:11:26Z

@str4d I made the OAEP and PSS impls generic over the Key traits now

roblabla

Hey that looks great! I have a couple suggestions

src/key.rs

roblabla · 2020-03-07T15:34:10Z

src/padding.rs

+                write!(f, "PaddingScheme::PKCS1v15({:?})", hash)
+            }
+            PaddingScheme::OAEP { ref label, .. } => {
+                // TODO: How to print the digest name?


Could make it Box<dyn DynDigest + Debug> if really necessary. AFAIK all the digest crates have debug unconditionally implemented on them.

that doesn't work, the compiler is upset about more than one non auto trait :(

Ah right, it's possible to make your own trait (e.g. trait MyDynDigest: DynDigest + Debug {}) and then use that as a Box<dyn MyDynDigest>, but at this point it's too much boilerplate just for the sake of getting the digest name to show IMO.

src/padding.rs

Cargo.toml

tarcieri · 2020-03-08T23:31:48Z

Relevant to the PSS use case: final two week comment period for shipping signature 1.0: RustCrypto/traits#78

str4d · 2020-03-09T05:32:08Z

src/key.rs

@@ -94,6 +97,13 @@ impl Drop for RSAPrivateKey {
    }
 }

+impl Deref for RSAPrivateKey {


Now that we have PrivateKey: PublicKeyParts, this impl Deref should be removed.

Not quite, removing this, removes the ability to call .verify on a private key

src/key.rs

str4d · 2020-03-09T05:49:28Z

src/raw.rs

+        if pad_size < ciphertext.len() {
+            return Err(Error::Verification);
+        }


Should this check also be in raw_decryption_primitive?

src/key.rs

src/pss.rs

dignifiedquire · 2020-04-10T12:41:44Z

@str4d thanks for the review, I think I addressed all important things

str4d · 2020-04-10T22:36:23Z

src/padding.rs

+    /// Encryption and Decryption using PKCS1v15 padding.
+    PKCS1v15Encrypt,
+    /// Sign and Verify using PKCS1v15 padding.
+    PKCS1v15Sign { hash: Option<Hash> },


The hash: None case appears to still be necessary for unpadded signatures (at least, that's what the test case in src/pkcs1v15.rs leads me to believe).

Yes, which is why it is still an Option, not sure what you mean.

I was just noting this because it wasn't immediately obvious during review that the Option<Hash> was necessary besides enabling the prior encryption case to specify None.

src/algorithms.rs

str4d

I made a close review pass over the RSAES-OAEP implementation, comparing it against RFC 8017 section 7.1.

src/oaep.rs

Co-Authored-By: str4d <[email protected]>

dignifiedquire · 2020-04-11T12:55:46Z

@str4d applied the new round of CR

str4d

These are causing the current CI failure.

benches/key.rs

str4d

I made a close review pass over the RSASSA-PSS implementation. The relevant sections of RFC 8017 were already inlined as comments.

str4d · 2020-04-12T01:54:34Z

src/pss.rs

+        None => (0..=em_len - (h_len + 2))
+            .rev()
+            .try_fold(None, |state, i| match (state, db[em_len - h_len - i - 2]) {
+                (Some(i), _) => Ok(Some(i)),
+                (_, 1) => Ok(Some(i)),
+                (_, 0) => Ok(None),
+                _ => Err(Error::Verification),
+            })?
+            .ok_or(Error::Verification)?,


Is there precedent for detecting the salt length? I know it is possible due to the structure of DB, but there is no mention of doing so in RFC 8017. I can't read the IEEE documents that reference different possible salt lengths, which maybe discusses this. As is, we never exercise the explicit-salt-length case below.

I don't know @roblabla I believe you wrote this code initially, do you have any answer to this?

str4d · 2020-04-12T01:55:16Z

src/pss.rs

+    salt_len: Option<usize>,
+    digest: &mut dyn DynDigest,
+) -> Result<Vec<u8>> {
+    let salt_len = salt_len.unwrap_or_else(|| priv_key.size() - 2 - digest.output_size());


Is there precedent for this default salt length? The RFC mentions that common choices are digest.output_size() and 0, while this is selecting the salt to be as large as could fit. I can't read the IEEE documents that reference different possible salt lengths. In any case, I don't think there's a problem with this, given that we are detecting the salt length in verify.

str4d · 2020-04-12T02:23:40Z

src/pss.rs

+    // 1. If the length of M is greater than the input limitation for the
+    //     hash function (2^61 - 1 octets for SHA-1), output "message too
+    //     long" and stop.


Length is not checked, but with the current API we never actually see the message.

str4d · 2020-04-12T02:23:51Z

src/pss.rs

+    // 1. If the length of M is greater than the input limitation for the
+    //    hash function (2^61 - 1 octets for SHA-1), output "inconsistent"
+    //    and stop.


Length is not checked, but with the current API we never actually see the message.

str4d · 2020-04-12T02:26:48Z

src/pss.rs

+    // 5. Let maskedDB be the leftmost emLen - hLen - 1 octets of EM, and
+    //    let H be the next hLen octets.
+    let (db, h) = em.split_at_mut(em_len - h_len - 1);
+    let h = &mut h[..(em_len - 1) - (em_len - h_len - 1)];


This would be clearer (and closer to the spec):

Suggested change

let h = &mut h[..(em_len - 1) - (em_len - h_len - 1)];

let h = &mut h[..h_len];

str4d · 2020-04-12T02:56:03Z

src/pss.rs

+        None => (0..=em_len - (h_len + 2))
+            .rev()
+            .try_fold(None, |state, i| match (state, db[em_len - h_len - i - 2]) {


Suggested change

None => (0..=em_len - (h_len + 2))

.rev()

.try_fold(None, |state, i| match (state, db[em_len - h_len - i - 2]) {

None => (0..em_len - h_len - 1)

.try_fold(None, |state, i| match (state, db[i]) {

this change results in failures, haven't debugged why, gonna leave the logic as is for now

str4d · 2020-04-12T03:06:51Z

src/pss.rs

+            for e in &db[..em_len - h_len - s_len - 2] {
+                if *e != 0x00 {
+                    return Err(Error::Verification);
+                }
+            }
+            if db[em_len - h_len - s_len - 2] != 0x01 {
+                return Err(Error::Verification);
+            }


Suggested change

for e in &db[..em_len - h_len - s_len - 2] {

if *e != 0x00 {

return Err(Error::Verification);

}

}

if db[em_len - h_len - s_len - 2] != 0x01 {

return Err(Error::Verification);

}

let (zeroes, rest) = db.split_at(em_len - h_len - s_len - 2);

if zeroes.iter().any(|e| *e != 0x00) || rest[0] != 0x01 {

return Err(Error::Verification);

}

str4d · 2020-04-12T03:08:00Z

src/pss.rs

+    let h0 = hash.result_reset();
+
+    // 14. If H = H', output "consistent." Otherwise, output "inconsistent."
+    if Into::<bool>::into(h0.ct_eq(h)) {


Suggested change

if Into::<bool>::into(h0.ct_eq(h)) {

if h0.ct_eq(h).into() {

str4d · 2020-04-12T03:10:00Z

src/pss.rs

+        return Err(Error::Internal);
+    }
+
+    let (db, h) = em.split_at_mut(em_len - s_len - h_len - 2 + 1 + s_len);


Suggested change

let (db, h) = em.split_at_mut(em_len - s_len - h_len - 2 + 1 + s_len);

let (db, h) = em.split_at_mut(em_len - h_len - 1);

str4d · 2020-04-12T03:13:37Z

src/pss.rs

+    // 8.  Let DB = PS || 0x01 || salt; DB is an octet string of length
+    //     emLen - hLen - 1.
+    db[em_len - s_len - h_len - 2] = 0x01;
+    db[em_len - s_len - h_len - 1..].copy_from_slice(salt);


We're assuming here that the em buffer passed into emsa_pss_encode is already zeroed. This happens to be the case, but given that emsa_pss_encode is only called from one place, and this PR isn't attempting to be no-std compatible, it would be clearer if em was constructed and returned from this function. Non-blocking.

roblabla and others added 11 commits September 26, 2019 14:49

Implement PSS

5d28baf

Remove PublicKey trait, use deref.

2462f1d

Removes the PublicKey trait, using Deref to provide the RSAPublicKey methods to RSAPrivateKey.

Avoid using vectors to store the asn1 prefixes

071f07f

Use separate functions for different padding schemes

527acfc

Add new sign_pss/verify_pss

b821cc6

Fix the tests

30220cf

Move copy_with_left_pad to algorithms

610c4cc

Add oaep encrypt and only with sha1 digest

79439a0

Test assertion is manual and done with openssl

refactor: bring oaep implementation into the regular interface

b50fa52

Merge branch 'pss' into oaep-dig

476f642

update readme

0b9564c

dignifiedquire requested review from str4d and tarcieri March 6, 2020 20:13

This was referenced Mar 6, 2020

Implement PSS #26

Closed

Add OAEP Encryption & Decryption #18

Closed

dignifiedquire added 2 commits March 6, 2020 21:24

fix benches

062ab54

update serde test

bc9749e

dignifiedquire added 2 commits March 6, 2020 22:49

Merge remote-tracking branch 'origin/master' into oaep-dig

167080e

make oaep and pss generic over keys

11500ed

roblabla reviewed Mar 7, 2020

View reviewed changes

tarcieri reviewed Mar 7, 2020

View reviewed changes

Cargo.toml Outdated Show resolved Hide resolved

str4d requested changes Mar 10, 2020

View reviewed changes

dignifiedquire added 2 commits April 10, 2020 14:34

apply CR

668e9dd

document padding schemes

40d7be0

roblabla mentioned this pull request Apr 10, 2020

Implement NPDM support MegatonHammer/linkle#39

Open

str4d reviewed Apr 10, 2020

View reviewed changes

str4d requested changes Apr 10, 2020

View reviewed changes

src/algorithms.rs Outdated Show resolved Hide resolved

str4d requested changes Apr 11, 2020

View reviewed changes

dignifiedquire and others added 2 commits April 11, 2020 14:35

Update src/algorithms.rs

2ae5f33

Co-Authored-By: str4d <[email protected]>

CR for oaep

f3f794d

str4d requested changes Apr 11, 2020

View reviewed changes

benches/key.rs Outdated Show resolved Hide resolved

benches/key.rs Outdated Show resolved Hide resolved

str4d requested changes Apr 12, 2020

View reviewed changes

str4d mentioned this pull request Jun 10, 2020

Release v0.3.0? #50

Closed

dignifiedquire added 3 commits June 11, 2020 13:20

fix benchmarks

84bfd0d

feat: update dependencies to rustcrypto 0.9 releases

f3e99b4

apply CR for pss implementation

a2bafc0

dignifiedquire merged commit 3bd9795 into master Jun 11, 2020

dignifiedquire deleted the oaep-dig branch June 11, 2020 11:58

	let h = &mut h[..(em_len - 1) - (em_len - h_len - 1)];
	let h = &mut h[..h_len];

	let (db, h) = em.split_at_mut(em_len - s_len - h_len - 2 + 1 + s_len);
	let (db, h) = em.split_at_mut(em_len - h_len - 1);

Integrate OAEP and PSS into existing interface #43

Integrate OAEP and PSS into existing interface #43

Conversation

dignifiedquire commented Mar 6, 2020

str4d commented Mar 6, 2020

str4d commented Mar 6, 2020

dignifiedquire commented Mar 6, 2020

dignifiedquire commented Mar 6, 2020

roblabla left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tarcieri commented Mar 8, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dignifiedquire commented Apr 10, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

str4d left a comment

Choose a reason for hiding this comment

dignifiedquire commented Apr 11, 2020

str4d left a comment

Choose a reason for hiding this comment

str4d left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment