iqlusioninc/community

Tony Arcieri

@tarcieri

that does make it a bit awkward with PKCS#1v15

str4d

@str4d

It would be useful to document this, because the trait currently gives no such indication

Tony Arcieri

@tarcieri

yeah there’s a whole bunch of design decisions which are presently undocumented :cry:

str4d

@str4d

The best thing for you to document first is the intended use cases for Signer and DigestSigner. Maybe open issues for documenting the rest

Tony Arcieri

@tarcieri

sounds good

str4d

@str4d

First chunk of work: RustCrypto/RSA#35

Tony Arcieri

@tarcieri

@str4d zomg: RustCrypto/elliptic-curves#5

Tony Arcieri

@tarcieri

@str4d looking at options for ChaCha20 and Poly1305 WASM to convert to core::arch/packed_simd

(Charles_K)

@charleschege

@tarcieri is there a way to store tai64 time as text in a text file when using serde serialize. Currently it's storing the time as binary. I want to also send it as json and all other contents that are being serialized to json are in text form

Tony Arcieri

@tarcieri

@charleschege TAI64(N) is a binary serialization. If you want something more text-friendly for JSON, you need to pick a text encoding e.g. hex

there’s no equivalent of e.g. RFC 3339 encoding

str4d

@str4d

Welp, found a minor bug in my manual port of Poly1305 SIMD that was breaking half the tests

Unfortunately that only shows that some of the finalize() method is working; still bugs elsewhere

Tony Arcieri

@tarcieri

@str4d are you trying to implement the UniversalHash trait or the (more extensive) current Poly1305 API?

str4d

@str4d

Both

Tony Arcieri

@tarcieri

aah

str4d

@str4d

But as a wrapper around an inner Poly1305State that operates on 4-blocks

Tony Arcieri

@tarcieri

looking at all these SIMD implementations… I’m like “well it’d be good if UniversalHash had a slice-oriented API"

for these sort of Poly1305 optimizations

but I’m also like “SIMD Poly1305 sucks compared to POLYVAL” :stuck_out_tongue_winking_eye:

str4d

@str4d

I figure the 4-block state API can be altered later to support a slice-oriented API

Tony Arcieri

@tarcieri

granted the latter is literally designed to optimize the implementation on (V)PCLMULQDQ-capable x86(_64) CPUs, but

ditto for ChaCha20 vs AES-NI

str4d

@str4d

The Goll-Gueron C code uses a pointer API and jumps to 8-block chunks if enough data is provided at once

Tony Arcieri

@tarcieri

yeah there’s all these branching cases to handle wider-than-block-sized chunks

str4d

@str4d

So we can likely do something similar

Tony Arcieri

@tarcieri

which makes sense… only for these sorts of algorithms

AES-NI and (V)PCLMULQDQ are optimized to work on m128i

str4d

@str4d

For now I'm focusing on refactoring the SIMD and documenting it, so I both understand it and hopefully find the remaining bugs

Tony Arcieri

@tarcieri

nice

yeah the paper you found seemed interesting at first and then I realized most of the complexity was microoptimizing the >128-bit case

str4d

@str4d

Yeah, and also required the whole length to be known

I suggested the paper mostly because it wasn't paywalled

Tony Arcieri

@tarcieri

yeah that’s doable for the AEAD cases but not given the current UniversalHash API

str4d

@str4d

(and they had code, which they obtained directly from Goll-Gueron)

Original:

    st->k = AND256(PERM32(k, SET32(3,7,2,6,1,5,0,4)), SET32(0,-1,0,-1,0,-1,0,-1));

Mine:

impl AdditionKey {
    pub(super) unsafe fn from_key(secret_key: __m256i) -> Self {
        // The addition key is the second half of the secret key; mask out the lower bits.
        let upper_bits = _mm256_and_si256(secret_key, _mm256_set_epi32(-1, -1, -1, -1, 0, 0, 0, 0));

        // Shuffle the 32-bit words so they can be read as 64-bit words:
        //     [k_3, k_2, k_1, k_0, 0, 0, 0, 0] -> [0, k_3, 0, k_2, 0, k_1, 0, k_0]
        let k = _mm256_permutevar8x32_epi32(upper_bits, _mm256_set_epi32(3, 7, 2, 6, 1, 5, 0, 4));

        AdditionKey(k)
    }
}

Tony Arcieri

@tarcieri

it is also true the AEAD case has… different requirements from the stream-cipher or universal-hash API

for the latter, it’s kind of captured in update_padded

which can be optimized for those wider-than-block-sized cases

Tony Arcieri

@tarcieri

wheee new cargo audit spotting yanked crates https://github.com/iqlusioninc/yubikey-piv.rs/commit/ed5134e9a26c5f6059d37858edcee9b61bc60f2f/checks?check_suite_id=419480114

Caleb Maclennan

@alerque

Nice Trogdor nod there in the logo ;-)

Tony Arcieri

@tarcieri

haha, thanks

mmacedo

@mmacedoeu

hi, is there any example for signal handling in abscissa core ?

Tony Arcieri

@tarcieri

unfortunately not. at some point I’ve been meaning to put together a GitBook that covers all of the existing features...

Zaki Manian

@zmanian

We have signal handling in the KMS

Might be a good example

Tony Arcieri

@tarcieri

well, we did, until that was implicated in several deadlocks and I ripped it out...

Zaki Manian

@zmanian

(Charles_K)

@charleschege

@tarcieri I am building an authentication system and I want to save time as TAI64 since I don't care about leap seconds or the time being human readable. Chrono is really big time library and I want something small so Tai64 crate seems like a good candidate. However, when I try to use it with Secrecy::Secret, it errors out with zeroize not implemented for Tai64N, I don't want time to be accessible from the console via debug, so is implementing Zeroize for Tai64 a good idea? Can the feature be added to the Tai64 crate?

Tony Arcieri

@tarcieri

sure, and yes

Where communities thrive

People

Repo info

Activity