profile
viewpoint

brycx/orion 167

Usable, easy and safe pure-Rust crypto

brycx/checkpwn 58

Check Have I Been Pwned and see if it's time for you to change passwords.

brycx/rigel 14

[UNMAINTAINED] HMAC-SHA512 implementation optimized for embedded devices

brycx/pasetors 7

PASETOrs: PASETO tokens in pure Rust

brycx/Test-Vector-Generation 2

Various generated test vectors.

brycx/advisory-db 0

Security advisory database for Rust crates published through crates.io

brycx/awesome-cryptography-rust 0

Collect libraries and packages about cryptography in Rust.

brycx/bcrypt-pbkdf 0

[UNMAINTAINED] The bcrypt_pbkdf password hashing algorithm in pure Rust.

brycx/branca 0

Authenticated and encrypted API tokens written in Rust. A secure JWT alternative.

brycx/branca-spec 0

Authenticated and encrypted API tokens using modern crypto

create barnchbrycx/rustls

branch : orion

created branch time in an hour

fork brycx/rustls

A modern TLS library in Rust

fork in 3 hours

issue openedbrycx/checkpwn

Switch from dirs to dirs-next

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

created time in 4 days

created tagbrycx/orion

tag0.15.5

Usable, easy and safe pure-Rust crypto

created time in 8 days

release brycx/orion

0.15.5

released time in 8 days

delete branch brycx/orion

delete branch : update-deps

delete time in 8 days

push eventbrycx/orion

brycx

commit sha 26ddab91a6d873048cbfb49a7cbfd074680a538c

Update base64 -> 0.13.0

view details

brycx

commit sha f854a7d3e77789cb5c1112e012fd74d5f8d190a7

0.15.5

view details

push time in 8 days

create barnchbrycx/orion

branch : update-deps

created branch time in 8 days

PR opened paragonie/paseto-io

Add new Rust implementation

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

+25 -0

0 comment

1 changed file

pr created time in 8 days

push eventbrycx/paseto-io

brycx

commit sha 01a4bae90f53c9a963c9bd332bd7379ab622e75a

Add brycx/pasetors to implementations list

view details

push time in 8 days

PublicEvent

issue closednorgance/Norgance

Question regarding use of Orion

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();

closed time in 10 days

brycx

issue commentnorgance/Norgance

Question regarding use of Orion

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.

brycx

comment created time in 12 days

push eventbrycx/orion

brycx

commit sha 97eccd25e100c646e112bbc0215bc58b0f92e15a

Doc: Fix aead doctest for MSRV

view details

push time in 14 days

issue commentnorgance/Norgance

Question regarding use of Orion

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?

brycx

comment created time in 14 days

push eventbrycx/orion

brycx

commit sha 15eebbda08aef9956f5addb8bc55a99207c597d3

Doc: Tidy aead doctests

view details

push time in 15 days

issue openednorgance/Norgance

Question regarding use of Orion

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();

created time in 16 days

created tagbrycx/orion

tag0.15.4

Usable, easy and safe pure-Rust crypto

created time in a month

release brycx/orion

0.15.4

released time in a month

push eventbrycx/orion

brycx

commit sha c77647efdd742fbd2ed74d53ecf1ded94a1c4e1a

0.15.4

view details

push time in a month

delete branch brycx/orion

delete branch : msrv-bump

delete time in a month

push eventbrycx/orion

brycx

commit sha 1b1cc79c7490934fd21412618740aa1ba933c80e

Bump MSRV -> 1.41.0 due to bump in subtle

view details

push time in a month

create barnchbrycx/orion

branch : msrv-bump

created branch time in a month

release brycx/checkpwn

0.4.0

released time in a month

created tagbrycx/checkpwn

tag0.4.0

Check Have I Been Pwned and see if it's time for you to change passwords.

created time in a month

push eventbrycx/checkpwn

brycx

commit sha 13a2d5d2ab0469c7e46ffb7e8ef8020965e807b4

0.4.0

view details

push time in a month

delete branch brycx/checkpwn

delete branch : ureq

delete time in a month

push eventbrycx/checkpwn

Johannes

commit sha 5621149f874c34f876c9cbefbe573968c55e2a0e

Switch from rewest to ureq (#33)

view details

push time in a month

PR merged brycx/checkpwn

Switch from reqwest to ureq

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

+43 -85

0 comment

3 changed files

brycx

pr closed time in a month

delete branch brycx/checkpwn

delete branch : hibp-api-v3

delete time in a month

delete branch brycx/checkpwn

delete branch : api-header

delete time in a month

delete branch brycx/orion

delete branch : update-getrandom

delete time in a month

PR opened brycx/checkpwn

Switch from reqwest to ureq

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

+43 -85

0 comment

3 changed files

pr created time in a month

push eventbrycx/orion

brycx

commit sha 9ec5d9612f1f453034d53d30e8ebf80b48a5790e

Update getrandom

view details

push time in a month

create barnchbrycx/checkpwn

branch : ureq

created branch time in a month

created tagbrycx/checkpwn

tag0.3.9

Check Have I Been Pwned and see if it's time for you to change passwords.

created time in a month

release brycx/checkpwn

0.3.9

released time in a month

push eventbrycx/checkpwn

brycx

commit sha bfbcf3f26c3882ff62fbc2bddb9a4cb46372fd29

0.3.9

view details

push time in a month

delete branch brycx/checkpwn

delete branch : dependabot/cargo/rpassword-5.0.0

delete time in a month

PR closed brycx/checkpwn

Update rpassword requirement from 4.0.5 to 5.0.0 dependencies

⚠️ 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>

+1 -1

1 comment

1 changed file

dependabot-preview[bot]

pr closed time in a month

pull request commentbrycx/checkpwn

Update rpassword requirement from 4.0.5 to 5.0.0

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

dependabot-preview[bot]

comment created time in a month

push eventbrycx/checkpwn

brycx

commit sha 2efd0304fad60074c6958232da35b525c8d8df2a

Update rpassword

view details

push time in a month

delete branch brycx/orion-fuzz

delete branch : corpus-min

delete time in a month

push eventbrycx/orion-fuzz

Johannes

commit sha 39602b94d170104da990d6c417b4a2cbdb77f2d7

Corpus minimization (#9) * Minimize corpus * Corpus minimization * Corpus minimization

view details

push time in a month

PR merged brycx/orion-fuzz

Corpus minimization
+54 -511

0 comment

2228 changed files

brycx

pr closed time in a month

PR opened brycx/orion-fuzz

Corpus minimization
+54 -511

0 comment

2228 changed files

pr created time in a month

create barnchbrycx/orion-fuzz

branch : corpus-min

created branch time in a month

create barnchbrycx/orion

branch : update-getrandom

created branch time in a month

delete branch brycx/orion-fuzz

delete branch : aead-allow-empty-pt

delete time in a month

push eventbrycx/orion-fuzz

Johannes

commit sha b2c0c4c93cbd792aadf8d777eaf48d64d926233d

aead: Allow empty input plaintext for hazardous interface (#8) * aead: Allow empty input plaintext for hazardous interface * Re-point to master branch, update dependencies and README

view details

push time in a month

push eventbrycx/orion-fuzz

brycx

commit sha 0c3cdb18d6527b8fc0443d475ed4e0243e1880b4

Re-point to master branch, update dependencies and README

view details

push time in a month

delete branch brycx/orion

delete branch : aead-empty-input

delete time in a month

push eventbrycx/orion

Johannes

commit sha 540474936bde6c08442546d3778e398d4571d404

aead: Allow empty input when sealing (#127)

view details

push time in a month

PR merged brycx/orion

Allow empty input when sealing with AEADs in hazardous

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.
+58 -137

1 comment

5 changed files

brycx

pr closed time in a month

create barnchbrycx/orion-fuzz

branch : aead-allow-empty-pt

created branch time in a month

startedhacspec/hacspec

started time in a month

PR opened brycx/orion

WIP: Allow empty input when sealing with AEADs

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
+58 -137

0 comment

5 changed files

pr created time in 2 months

create barnchbrycx/orion

branch : aead-empty-input

created branch time in 2 months

issue commentscottbrady91/IdentityModel

Multiple issues with Branca spec conformance

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.

brycx

comment created time in 2 months

issue commenttuupola/branca-spec

Suggestion to optional nonce protection

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.

brycx

comment created time in 2 months

issue commentscottbrady91/IdentityModel

Multiple issues with Branca spec conformance

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.

brycx

comment created time in 2 months

issue openedtuupola/branca-spec

Missing License file

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

created time in 2 months

issue openedtuupola/branca-spec

Suggestion to expiration check

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.

created time in 2 months

issue openedtuupola/branca-spec

Suggestion to optional nonce protection

$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.

created time in 2 months

fork brycx/branca-spec

Authenticated and encrypted API tokens using modern crypto

https://branca.io/

fork in 2 months

issue openedscottbrady91/IdentityModel

Unauthenticated ciphertext - attackers can modify tokens

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.

created time in 2 months

issue openedscottbrady91/IdentityModel

Poly1305 key misuse - attackers can forge authenticated tokens

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.

created time in 2 months

issue openedscottbrady91/IdentityModel

Multiple issues with Branca spec conformance

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.

created time in 2 months

push eventbrycx/brycx.github.io

brycx

commit sha 05ae38334b64c93bf6fec1615b8485ce8063dab8

Add 'Rolling your own crypto gone wrong: A look at a .NET Branca implementation'

view details

push time in 2 months

PR opened return/branca

Use as_secs() in new()

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

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchbrycx/branca

branch : fix-new-timestamp

created branch time in 2 months

PR opened return/branca

Perform token expiration check after authentication

Fix #7

+34 -16

0 comment

1 changed file

pr created time in 2 months

issue openedreturn/branca

Impossible to know if expired token is valid or not

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.

created time in 2 months

PR opened return/branca

Add some test vectors from the JS implementation
+67 -0

0 comment

1 changed file

pr created time in 2 months

create barnchbrycx/branca

branch : test-vectors

created branch time in 2 months

create barnchbrycx/branca

branch : fix-timestamp-validation

created branch time in 2 months

push eventbrycx/branca

Mihajlo Kocić

commit sha 5aee7ba1054b09e79fa28731e3ca144bfd4f3d71

Fix incorrect summaries for TTL (#5) The summaries list TTL as "milliseconds", this is not correct.

view details

Calvin Hill

commit sha e33e5908b62f978b3188028f2af4a24af9c38ed0

Update branca dependencies

view details

Calvin Hill

commit sha 3f151e863545a39e62f8ff7ad53b58fbf33e271f

Add initial Github Actions CI

view details

Calvin Hill

commit sha afe38bde8b20aaa803f234b09fba69d2bbb1f00b

Use GitHub Actions and remove Travis

view details

Calvin Hill

commit sha 798cf926bb09020999eeb9028bfde934e5550be4

branca: v0.9.1

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha d6291e1d550e3c132b0dfd77c0552d8112b39dfc

Tests: Fix remaining invalid paths

view details

brycx

commit sha 604804478e9159313a63e97b54fb83a5f15644ec

Tests: Refactor tests for Poly1305 with BoringSSL.

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha aba65855736537c729289e2ffa237220377f2600

Tests: Delete duplicate test file also existing in /original where it belongs

view details

brycx

commit sha 30de49777f3548fe461b0c83810205c535cfc053

Tests: Reorganize test data folders

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha 96bbfa94f8929213e00a2f6f6ddab35b503e3209

Tests: Refactor BoringSSL tests for (X)ChaCha20Poly1305

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha 7b422400c6c3074620a2ea7c2bac161279673fa7

Tests: Refactor NIST tests for HMAC.

view details

push time in 2 months

create barnchbrycx/orion

branch : refac-tests

created branch time in 2 months

startedpornin/bingcd

started time in 2 months

push eventbrycx/checkpwn

brycx

commit sha ceeba3a189aa9e63f47efc9b799e5b656ea8d076

Point Security Audit workflow to correct branch

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha 21f59c9eb7ab499573602054bbe2cfea90d9e244

CI: Point Security Audit workflow to correct branch and fix daily tests release arguments

view details

push time in 2 months

created tagbrycx/orion

tag0.15.3

Usable, easy and safe pure-Rust crypto

created time in 2 months

release brycx/orion

0.15.3

released time in 2 months

delete branch brycx/orion

delete branch : main

delete time in 2 months

delete branch brycx/orion

delete branch : crates-published

delete time in 2 months

create barnchbrycx/orion

branch : main

created branch time in 2 months

delete branch brycx/orion

delete branch : main

delete time in 2 months

create barnchbrycx/orion

branch : main

created branch time in 2 months

push eventbrycx/orion

brycx

commit sha 5cfbef3baeb77911209eaf47c2b3f899edaf5788

Add bagde for daily test workflow

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha bf08740285e410729fe295bdb22cc9097bfd7039

Create daily tests workflow for GH Actions

view details

push time in 2 months

push eventbrycx/orion

brycx

commit sha 146d4aa5b031ded9f2b2ddc0d1cdc2958b953068

0.15.3

view details

push time in 2 months

delete branch brycx/orion

delete branch : alloc-feature

delete time in 2 months

more