indygreg / cryptography-rs Goto Github PK

Running cargo deny on this crate shows that the transitive dependency through chrono crate yields a security advisory. Being more selective about the required features as shown in the warning text below should address that concern.

error[A001]: Potential segfault in the time crate
    ┌─ /.../cryptography-rs/Cargo.lock:155:1
    │
155 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ----------------------------------------------------------------- security vulnerability detected
    │
    = ID: RUSTSEC-2020-0071
    = Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
    = ### Impact

      Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

      The affected functions from time 0.2.7 through 0.2.22 are:

      - `time::UtcOffset::local_offset_at`
      - `time::UtcOffset::try_local_offset_at`
      - `time::UtcOffset::current_local_offset`
      - `time::UtcOffset::try_current_local_offset`
      - `time::OffsetDateTime::now_local`
      - `time::OffsetDateTime::try_now_local`

      The affected functions in time 0.1 (all versions) are:

      - `at`
      - `at_utc`
      - `now`

      Non-Unix targets (including Windows and wasm) are unaffected.

      ### Patches

      Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.

      Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.

      Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

      ### Workarounds

      A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.

      #### Examples:

      `Cargo.toml`:

      ```toml
      chrono = { version = "0.4", default-features = false, features = ["serde"] }
      ```

      ```toml
      chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
      ```

      Commandline:

      ```bash
      cargo add chrono --no-default-features -F clock
      ```

      Sources:
       - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)
       - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)
    = Announcement: https://github.com/time-rs/time/issues/293
    = Solution: Upgrade to >=0.2.23
    = time v0.1.45
      └── chrono v0.4.24
          ├── cryptographic-message-syntax v0.22.0
          ├── pgp v0.9.0
          │   └── pgp-cleartext v0.6.0
          ├── pgp-cleartext v0.6.0 (*)
          └── x509-certificate v0.19.0
              └── cryptographic-message-syntax v0.22.0 (*)

I'm wondering if it would be possible to break out the ASN1 primitives in the asn1 folder as their own independent crate or as a feature of the CMS crate that we could use independently? The rest of the crate brings in dependencies that we can't support (notably blocking calls on reqwest that can't compile on some of our targeted platforms).

I have tried to use the x509-certificate crate to verify a signed S/MIME file, but with no success. The file has two parts: a text/plain XML document and a PKCS#7 signature to prove the XML content's authenticity.

Please see my test program x509-test.

The test program has the following steps:

• Write the test data to temp files and use OpenSSL to check that they verify ok, so that the test inputs are sane. Capture the OpenSSL output for contents comparison.
• Use the mailparse package to extract the XML content and signature in PEM fromat.
• Modify parsed content newlines, because they do not survive MIME encode/decode intact.
• Check that our parsed content matches byte-by-byte OpenSSL output.
• Use cms package to decode the PKCS#7 signature block.
• Extract the SHA256 hash of the XML content from the signature.
• Compute the SHA256 hash from parsed content, and check that hashes are equal.
• Extract the ECDSA signature bytes, still keeping the "r" and "s" in ASN.1 encoding. This format is used, because of the ring documentation
• Use verify_signed_data_with_algorithm with ECDSA_P256_SHA256_ASN1 algorithm to verify content bytes against signature bytes.

The problem is that the verification always fails, but I cannot figure out why.

Am I perhaps trying to do a completely wrong thing here? Can you provide an example how the verification is supposed to be used?

I have generated ed25519 keys and I want to use that key to create a CSR. I used openssl to create a pkcs8 package, it is only the private key.
I checked to output in openssl and a online ASN1 parser and the public key data is NULL.
Any Ideas?

''''
let byts = parse(rd_file(pkcs8)).expect("Read or der failed");
println!("{:?}", byts);
let kp25519 = Ed25519KeyPair::from_pkcs8_maybe_unchecked(&byts.contents).expect("Can't read key");
let pubkey = kp25519.public_key().clone();
println!("{:?}", &pubkey);
let bob = InMemorySigningKeyPair::from(kp25519);
let mut cb = X509CertificateBuilder::new(KeyAlgorithm::Ed25519);
cb.subject().append_common_name_utf8_string("test").unwrap();
cb.subject().append_country_utf8_string("Cost Rica").unwrap();
let mut csr = cb.create_certificate_signing_request(&bob).expect("create csr failed");
'''
Pem { tag: "PRIVATE KEY", contents: [48, 46, 2, 1, 0, 48, 5, 6, 3, 43, 101, 112, 4, 34, 4, 32, 237, 85, 186, 145, 145, 165, 122, 115, 74, 44, 87, 99, 40, 101, 189, 120, 227, 124, 101, 232, 81, 202, 48, 219, 184, 29, 190, 158, 37, 197, 23, 114] }
PublicKey("5f72cfa65ba90c461c10ce2538f99b7817e3e81c2748db855c7b72e54e9c1b12")
"test/ed25519.crt"
PublicKey("5f72cfa65ba90c461c10ce2538f99b7817e3e81c2748db855c7b72e54e9c1b12")
Ed25519(Ed25519KeyPair { public_key: PublicKey("5f72cfa65ba90c461c10ce2538f99b7817e3e81c2748db855c7b72e54e9c1b12") })

-----BEGIN CERTIFICATE REQUEST-----
MIGmMFgCAQAwIzENMAsGA1UEAwwEdGVzdDESMBAGA1UEBgwJQ29zdCBSaWNhMCww
BwYDK2VuBQADIQBfcs+mW6kMRhwQziU4+Zt4F+PoHCdI24Vce3LlTpwbEqAAMAcG
AytlcAUAA0EAze2MXZHgG3CKN+ySlvjfAnNWJZK19YNaP0DgoRhg6LF2OWlm5iM2
g/8OTI19ggejf0uksB37TT6uquLy7Y3KCQ==
-----END CERTIFICATE REQUEST-----

I try to use cryptographic-message-syntax crate to verify a signature. While I can verify the signature proper, I cannot verify the validity of the embedded certificate. My scenario is a bit more complex (includes an intermediate CA), I created an example where the problem can be seen.

The sorting algortihm for SignedAttributes in cryptographic-message-syntax/src/asn1/rfc5652.rs uses only the values field of the attribute to generate a byte array for sort comparison. It omits the entire attribute encoding, which in turn skips the typ attribute as well. Therefore the set is sorted based on the der encoding of the values not the attribute itself.

However, the SignedAttributes ::= SET SIZE (1..MAX) OF Attribute which means, it needs to be sorted based on the encoded attribute (not encoded attribute.value).

This bug was detected during a comparison being made to the BouncyCastle

NLnet Labs’ bcder library up to and including version 0.7.2 panics while decoding certain invalid input data rather than rejecting the data with an error. This can affect both the actual decoding stage as well as accessing content of types that utilized delayed decoding.

https://nvd.nist.gov/vuln/detail/CVE-2023-39914

Currently x509-certificate crate has a dependency on bcder crate version 0.7.2. This is a request to update it to 0.7.3.
https://crates.io/crates/x509-certificate/0.20.0/dependencies

I am having a issue trying to add a Attribute using add_csr_attribute(Attribute)
The Attribute is something like.

OID: "2.5.4.20"
values: "999999999".to_string()

How do you convert a string to OID?
How do you convert a string of numbers to values?

Hi, i'm trying to create a sample TimeStampResp, but for some reason the const OID_CONTENT_TYPE_TST_INFO cannot be assigned to the content_type of the TimeStampToken.

It fails on the content_type, it's probably a stupid thing but I can't get it to work. Even assigning it to a temp Oid via Oid::<Bytes>::from(OID_CONTENT_TYPE_TST_INFO.0); didn't work. It seems that content_type and the const are of a different type but I'm unable to grasp why that is or how to convert one into the other.

let tst_response = TimeStampResp {
      status: PkiStatusInfo {
          status: PkiStatus::Granted,
          status_string: None,
          fail_info: None,
      },
      time_stamp_token: Some(
          TimeStampToken {
              content_type: OID_CONTENT_TYPE_TST_INFO, <-- expected struct `Bytes`, found `&[u8]`
              content: tst_capture,
          }
      ),
  };```