Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    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
    Oh
    (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
    just add a zeroize feature to tai64
    i.e. add zeroize as an optional dependency
    (Charles_K)
    @charleschege
    @tarcieri I have implemented the zeroize feature, all checks have passed except the code coverage one, I am unable to solve that and would like some help
    (Charles_K)
    @charleschege
    @tarcieri I have a project that requires a value to be hashed into a hashmap, but the value is of secrecy::Secret<T>. Would there be a security problem if I implement Hash for Secret<T>?
    Tony Arcieri
    @tarcieri
    that’s a tricky question, as used incorrectly it could leak information about the secret. Ditto for Ord
    something like DebugSecret that marks the underlying impl does constant-time comparisons or hashing could work
    Santiago Torres
    @SantiagoTorres
    hey, I've been trying zero-out the emmc on an usbarmory by following the instructions in here https://github.com/iqlusioninc/usbarmory.rs/tree/develop/firmware/usbarmory#setting-up-an-emmc-boot
    for some reason minicom doesn't seem to be working (on this line minicom -b 115200 -D /dev/ttyUSB2), I don't get any echo back. I wonder what'd be a good place to start debugging my situation
    Zaki Manian
    @zmanian
    Hi!
    Santiago Torres
    @SantiagoTorres
    zmanian: hey! :D
    Zaki Manian
    @zmanian
    So one thing is the the basic examples with the USB runner will work without zeroing the eMMC if it’s a fresh from box device
    Santiago Torres
    @SantiagoTorres
    I'm still rather worried that I may not have been setting the debugger dongle properly :(
    Santiago Torres
    @SantiagoTorres
    I'm starting to think that my u-boot build is proabbly what's bork