Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tony Arcieri
    @tarcieri
    are you saying the Signer and DigestSigner relationship is reversed versus… every other signature algorithm in the universe that uses Fiat-Shamir?
    str4d
    @str4d
    I'm going off the current reality, which is that if a type that impls Signature also impls DigestSignature, then they get an auto-derived impl Signer that calls through to DigestSigner
    And I'm trying to square that with how users interpret the traits
    Tony Arcieri
    @tarcieri
    you don’t have to use the derive if you don’t want to
    str4d
    @str4d
    As an implementer of a specific signature, no. But as a user of signatures implemented by other people, what do I expect the traits to mean?
    Tony Arcieri
    @tarcieri
    it might make sense for PKCS#1v15 (and only PKCS#1v15) to impl signer, then impl DigestSigner in terms of Signer
    I mean, PKCS#1v15 is broken and vulnerable to BB’06 and really shouldn’t be used and if it’s confusing I honestly don’t care
    str4d
    @str4d
    That is fair
    Tony Arcieri
    @tarcieri
    but then we have Peter Gutmann telling people it’s better than PSS 🙄
    DigestSigner is trying to be a ROM trait for Fiat-Shamir
    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
    Tony Arcieri
    @tarcieri
    @str4d looking at options for ChaCha20 and Poly1305 WASM to convert to core::arch/packed_simd
    #[DEV43_]
    @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