Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    str4d
    @str4d
    Noooo https://github.com/mit-plv/fiat-crypto/blob/5674566a11eafdbee87ea2730130fe396b09add8/fiat-rust/src/p256_64.rs#L17-L20
    Tony Arcieri
    @tarcieri
    hahaha
    str4d
    @str4d
    "Let's just pretend that an 8-bit number is a 1- or 2-bit number and hope our generation code doesn't overflow"
    I don't know whether the code is assuming that a cast to fiat_p256_i2 will mask out all but the lowest 2 bits, but it sure as hell isn't doing that.
    str4d
    @str4d
    @tarcieri I've sketched out a rough API for RSA signatures as a starting point for discussion: RustCrypto/RSA#34
    Tony Arcieri
    @tarcieri
    nice, looking now
    str4d
    @str4d
    Slightly slower having this conversation in the GH thread, but this is all very valuable :D
    Tony Arcieri
    @tarcieri
    yup
    it’s an annoying set of tradeoffs to square. unfortunately people seem dissatisfied with the solution of “focus on having one high-quality set of digest algorithms” :cry:
    which I can kind of get. there are the issues of architecture-specific SHA-NI-style instructions and whether e.g. the sha256 crate should support every variant of those under the sun or not
    str4d
    @str4d
    Something I realised while implementing RandomizedDigestSigner (which turns out I definitely need):
    It's unfortunate that there are two distinct use cases for the trait: for randomized signatures, and for deterministic but blinded signatures.
    Tony Arcieri
    @tarcieri
    I’d also be okay with splitting those use cases into separate traits...
    str4d
    @str4d
    Yeah; it's not clear to me how a user should distinguish between the two.
    This is also similar to the issue of the RSA NoneDigest problem
    Tony Arcieri
    @tarcieri
    RSA: why we can’t have nice things :weary:
    str4d
    @str4d
    (i.e. whether signature::Signer is for arbitrary-length messages only)
    Tony Arcieri
    @tarcieri
    that’s the intent, although for PKCS#1v15 I think it’d be fine to error on the message being the wrong length
    I guess overlong is the main error case?
    str4d
    @str4d
    This is my current thinking for strategy:
    • Signer is for arbitrary-length messages, and does whatever is appropriate to sign them. This fits with the auto-derive to DigestSigner underneath.
    • DigestSigner is the "main" interface; for RSA we impl Digest for NoneDigest to handle the directly-signed message case.
    • RandomizedDigestSigner is the interface for randomized signatures.
    • BlindedDigestSigner is an almost-identical interface (just trait method names are different) which is for deterministic signatures with blinding.
    "Overlong" is fine if Signer is only intended for directly-signing messages, but my concern is that confuses users given that other impls of Signer call through to DigestSigner due to the derive.
    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
    @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