dirs is unmaintained. dirs-next is the follow-up.

This adds a new Rust implementation, with support for v2 only.

Hi there!

I'm the author and maintainer of orion and recently came over this project, which is using the orion::aead API. First off, thanks for considering and using orion, that is very rewarding for me.

Second, I was wondering if you were aware that orion also provides a BLAKE2b implementation? The reason I'm asking is, because instead of using orion for BLAKE2b, the blake2_rfc crate is pulled in. So I'm wondering if there's something you dislike about the API provided by orion, which I might be able to improve? Of course, I'm also interested in any other reason for the current choice.

As an example, the orion::hazardous implementation for BLAKE2b could be used as such, where blake2_rfc is used now:

let hash_salt = SecretKey::from_slice(SIGNATURE_BLAKE2B_HASH_SALT)?;
let mut ctx = Blake2b::new(Some(&hash_salt), SIGNATURE_BLAKE2B_HASH_SIZE)?;
ctx.update(&packed_data)?;
let packet_hash = ctx.finalize()?.as_ref();

I heard there were some experiments with it, though I don't know if they have something working. In terms of using Argon2 in in sequential mode, this seems to be viable, but then we're just missing someone to implement it.

Thank you for the kind words.

The orion API is fine, though I would probably create an utility method to use it in a single function call like blake2_rfc.

That makes sense in this case, where you know all the parameters are valid (&packed_data would hardly exceed the size limit).

By the way, I also use argon2id and I see that orion offers argon2i only. Is there any reason for that, other than someone needs to implement it of course ?

Main reason was the need for additional dependencies to support the threading. Back when I looked into that, they all had varying degrees of unsafe code in use, which orion tries to abstain from. Of course someone would have to implement it as well. Is there any reason you require the id variant strictly over i?

Hi there!

I'm the author and maintainer of orion and recently came over this project, which is using the orion::aead API. First off, thanks for considering and using orion, that is very rewarding for me.

Second, I was wondering if you were aware that orion also provides a BLAKE2b implementation? The reason I'm asking is, because instead of using orion for BLAKE2b, the blake2_rfc crate is pulled in. So I'm wondering if there's something you dislike about the API provided by orion, which I might be able to improve?

As an example, the orion::hazardous implementation for BLAKE2b could be used as such, where blake2_rfc is used now:

let hash_salt = SecretKey::from_slice(SIGNATURE_BLAKE2B_HASH_SALT)?;
let mut ctx = Blake2b::new(Some(&hash_salt), SIGNATURE_BLAKE2B_HASH_SIZE)?;
ctx.update(&packed_data)?;
let packet_hash = ctx.finalize()?.as_ref();

ureq has a much smaller dependency tree as well as no unsafe code.

ureq has a much smaller dependency tree as well as no unsafe code.

⚠️ Dependabot is rebasing this PR ⚠️

If you make any changes to it yourself then they will take precedence over the rebase.

Updates the requirements on rpassword to permit the latest version. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/conradkleinespel/rpassword/releases">rpassword's releases</a>.</em></p> <blockquote> <h2>v5.0.0</h2> <p>There is 1 breaking change in this release.</p> <p>If you use the <code>read_password_with_reader</code> function, you will need to replace any calls to <code>read_password_with_reader(Some(reader))</code> with <code>read_password_with_reader(Some(&mut reader))</code>. This change allows calling <code>read_password_with_reader</code> multiple times with the same reader, which makes unit testing much easier (see <a href="https://github-redirect.dependabot.com/conradkleinespel/rpassword/issues/46">#46</a> for some background).</p> <p>Thanks <a href="https://github.com/dvermd">@dvermd</a> for this contribution!</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/conradkleinespel/rpassword/commit/c786de157b15ea326c5e21f6270b0b5ca1e498f9"><code>c786de1</code></a> Bump to v5 (<a href="https://github-redirect.dependabot.com/conradkleinespel/rpassword/issues/52">#52</a>)</li> <li><a href="https://github.com/conradkleinespel/rpassword/commit/ce2297cfbcbec0c55716fefd311fa15561ae6bb0"><code>ce2297c</code></a> Improve mock with enhanced_mock feature</li> <li><a href="https://github.com/conradkleinespel/rpassword/commit/acff1bd903692fe0327826b94d3523733817fbb4"><code>acff1bd</code></a> Various minor code cleanups (<a href="https://github-redirect.dependabot.com/conradkleinespel/rpassword/issues/47">#47</a>)</li> <li><a href="https://github.com/conradkleinespel/rpassword/commit/189c3888341f082738a3efbd7287aaf4ce64d792"><code>189c388</code></a> Skip calling Windows console api with piped stdin (<a href="https://github-redirect.dependabot.com/conradkleinespel/rpassword/issues/51">#51</a>)</li> <li>See full diff in <a href="https://github.com/conradkleinespel/rpassword/compare/v4.0.5...v5.0.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Fixed in https://github.com/brycx/checkpwn/commit/2efd0304fad60074c6958232da35b525c8d8df2a

This change allows empty input on AEADs sealing operation. The authentication tag is still calculated, using the optional AAD and is copied to the out parameters.

TODO:

• [X] Adjust fuzzing targets to allow empty inputs (See https://github.com/brycx/orion-fuzz/pull/8)
• [X] Figure out if empty input should be allowed in high-level API. If not, correct corresponding docs: I've found no use-case for this. Allowing empty input seems only relevant when implementing protocols etc, which the high-level interface is not intended for. So in that case, users will be using the hazardous interface anyway.

This change allows empty input on AEADs sealing operation. The authentication tag is still calculated, using the optional AAD and is copied to the out parameters.

TODO:

• [ ] Adjust fuzzing targets to allow empty inputs
• [ ] Figure out if empty input should be allowed in high-level API. If not, correct corresponding docs

I think it's obvious that I care based on how much this hurt and how fast I addressed the issues.

Let me clarify: I assumed you didn't care about how security issues were reported. I wasn't sure if we were talking about the same thing.

If you genuinely think there is value in your article, I suggest making it more generic (e.g. Bouncy Castle), removing my name from it, and switching to a more analytical tone. I think you owe me that.

I fail to see how Bouncy Castle has anything to do with this. Further, I'm left with little choice when the NuGet is released with a name that includes your own. There are many more popular NuGets listed, with millions of downloads, when searching for "IdentityModel" on nuget.org. To not specifically name yours fully throughout the entire post, but still not create confusion about what NuGet I was talking about, I also chose to shorten it:

"I’ll also be referring to this NuGet as just IdentityModel throughout the rest of this post."

My post outlines how severe issues can occur when basic testing is ignored, through critiquing a publicly released NuGet. Had there been similar NuGets, it could have been any of them. I don't see how I've done you wrong in this regard or owe you anything.

After looking around a bit I found https://github.com/paragonie/paseto/issues/103. According to this issue, the current way both Branca (I assume it was inspired by PASETO?) and PASETO attempt to protect against bad RNGs is not optimal.

Apart from the above, I think we should just stick with BLAKE2. It's older and therefore, probably more libraries support it, compared to BLAKE3. Generalising to BLAKE2 lets users choose between b/s according to their architecture. Functions that are used here should also be PRFs that can correctly take into account the use of the secret key. And I'm not familiar with the specifics thereof, or the SHA-3 standardisations, to make any attempts at recommendations here.

I would have loved some responsible disclosure.

There were mainly two reasons I opted for full disclosure. The first was that the NuGet seemed relatively new and unknown, few downloads and without any users. I searched around for users of this Branca implementation but found none (of course that doesn't mean there are none at all). I would've taken a different approach if it were more popular and used. Second, there was no information on how to report security vulnerabilities. I checked both this repository and the site of the blogpost linked, and I found nothing.

I see you've just added a SECURITY.md. Thanks for this. This will make it much clearer to people on how to handle situations like these in the future. I simply assumed, from the lack of policy, that you didn't care.

In hindsight, I should probably have tried to contact you to ask what you'd have preferred. I apologize for not having done so and I will keep that in mind for the future.

Please consider reaching out first next time and helping someone improve their personal project.

My post and these issues are an attempt to help. Both in making it clear what needed to be fixed but also how others can avoid similar situations in the future (main motivation behind the post). The latter will not be possible if the post is taken down.

I have updated this library's implementation of Branca to use libsodium as opposed to Bouncy Castle.

I just ran it through the first few tests from the JS implementation, and can confirm they now pass.

The issues you have described most likely affect all other Branca implementations using Bouncy Castle. For instance, this library ported the implementation found in the Java libraries and used test data generated by them.

If that is the case, the issues also need to be reported there of course.

The README refers to a non-existing License file. This should probably be added.

I think it would make sense to specifically state, that the expiration check for a token using a ttl should happen after authenticating and decrypting. If it happens before, a user would never know if an expired token they received was tampered into expiring, or actually did expire.

$size = CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES; $random = random_bytes($size); $nonce = sodium_crypto_generichash($payload, $random, $size);

I think it would be good to concretize this a bit to make it clearer, by specifically stating the algorithm this example uses (BLAKE2b IIRC). Also, what if sodium_crypto_generichash changes at some point? If we specifically state the algorithm tied to hashing for the nonce, we can tie that to the version and change it in the far future if need be.

In extension of #2, the current code in Branca allows attackers to modify any token's payload without invalidating the Poly1305 authentication tag.

The implementation fails to authenticate the ciphertext in CreateToken() at:

var poly = new Poly1305();
poly.Init(keyMaterial);
poly.BlockUpdate(header, 0, header.Length);
poly.DoFinal(ciphertext, plaintextBytes.Length);

var tokenBytes = new byte[header.Length + ciphertext.Length];
Buffer.BlockCopy(header, 0, tokenBytes, 0, header.Length);
Buffer.BlockCopy(ciphertext, 0, tokenBytes, header.Length, ciphertext.Length);

DoFinal() does not authenticate ciphertext. It writes the tag of the header into ciphertext. This is then later copied again to tokenBytes. The same issue is in DecryptToken().

PoC:

var handler = new BrancaTokenHandler();
var key = Encoding.UTF8.GetBytes("supersecretkeyyoushouldnotcommit");
var actualToken = handler.CreateToken("Test", key);
var decoded = Base62.Decode(actualToken);
decoded[decoded.Length - 17] ^= 1; // Last byte before the Poly1305 tag
Console.WriteLine("{0}", handler.DecryptToken(Base62.Encode(decoded), key).Payload);

Running it returns Tesu instead of Test.

In extension of #2, the current code in Branca allows attackers to forge authenticated tokens, if a user uses any given key more than once (see NaCl).

The issue lies in the use of the same key for both encryption and authentication of the token.

var keyMaterial = new KeyParameter(key);
var parameters = new ParametersWithIV(keyMaterial, nonce);

var engine = new XChaChaEngine();
engine.Init(true, parameters);

and

var poly = new Poly1305();
poly.Init(keyMaterial);

This will automatically be fixed, if the Branca implementation adheres to the specification.

I've been looking through the Branca implementation and seem to have found several issues. Branca is not implemented as defined in the specification. This issue would have surfaced much earlier, had there been test vectors from the other implementations.

XChaChaEngine and Poly1305 does not implement XChaCha20-Poly1305. XChaCha20-Poly1305 is implemented with HChaCha20 and ChaCha20-Poly1305. Please see the draft RFC and RFC 8439.

The Poly1305 authentication tags are not compared in constant-time, and can therefore leak information to an attacker through a timing side-channel.

This issue is the same as reported in #3, but new() was still using as_nanos().

Fix #7

Because the token expiration check is performed before authentication and decryption, it's impossible to know if an expired token is valid or invalid.

An attacker may modify the timestamp, in the header, to make the token expire but the user would never know that it had been modified.