Monday, September 19, 2022< ^ >
synp has set the subject to: LAMPS Interim Meeting 2022-Apr-20
Room Configuration
Room Occupants

[13:01:46] <zulipbot> (Sean Turner) morning, afternoon, evening, night, really late night to all
[13:02:20] <zulipbot> (Tim Hollebeek) Good whatever to everyone!
[13:04:07] <zulipbot> (Mike Ounsworth) I could take notes, ... once I figure out my audio issues
[13:07:08] <zulipbot> (Mike Ounsworth) I there a way to have Etherpad *and* slides on your screen at the same time?
[13:07:57] <zulipbot> (Mike Ounsworth) Ah yes, HedgeDoc has a Open in New Tab button.
[13:11:05] <zulipbot> (Mike Ounsworth) +1 for adding id-PBMAC1 support to PKCS#12; we are doing the exact same change to CMP in CMP Algorithms / 4210bis that Hendrik has been leading.
[13:12:42] <zulipbot> (Tim Hollebeek) The FIPS compliance problem is the use of obsolete algorithms?
[13:13:58] <zulipbot> (Dmitry Belyavskiy) No. The whole PKCS#12 KDF is not standardized
[13:14:15] <zulipbot> (Tim Hollebeek) well, yes, but how is that a FIPS problem?
[13:14:57] <zulipbot> (Dmitry Belyavskiy) It can't be used in FIPS mode. But the format is quite necessary for interoperability
[13:15:59] <zulipbot> (Mike Ounsworth) @tim If it's like CMP, then the existing passwordBasedMAC is probably PBKDF1-like, and when you try to FIPS-certify that, the FIPS Lab says "but that's not a thing according to our docs"
[13:17:39] <zulipbot> (Tim Hollebeek) Right - FIPS is a very limited set of things, you can't just validate something new.
[13:18:04] <zulipbot> (Tim Hollebeek) That why you see lots of people implementing PBKDFs (for example) a layer above their FIPS module
[13:18:17] <zulipbot> (Tim Hollebeek) And, often, not running in strict FIPS
[13:23:06] <zulipbot> (Hubert Kario) 140-3 Service Indicators also make use of non-FIPS compliant crypto easier to spot
[13:23:19] <zulipbot> (Uri Blumenthal) Given that NIST-selected PQ KEMs all have internal KDF, what's the purpose of the extra KDF?
[13:23:19] <zulipbot> (Hubert Kario) FIPS 140-3*
[13:24:48] <zulipbot> (Tim Hollebeek) yeah, I have to catch up on FIPS 140-3.  My brain is still mostly only 140-2 compliant.
[13:25:05] <zulipbot> (Tim Hollebeek) which is ancient and mostly useless at this point
[13:26:35] <zulipbot> (Mike Ounsworth) @uri - I believe that is an open design question. The NIST KEMs are explicitely ok for their output to be used directly as a symmetric key, but it's not clear that that's a general property of all KEMs, so adding a KDF here is a conservative choice. ... open for discussion I believe.
[13:26:49] <zulipbot> (Uri Blumenthal) What would be the purpose to extend to non-NIST KEMs?
[13:27:28] <zulipbot> (Scott Fluhrer) The purpose for non-NIST KEMs - not all the world is the US; some people may prefer to use their own crypto
[13:28:47] <zulipbot> (Uri Blumenthal) I thought the PQC was international, and the winners were not designed or proposed by the US?
[13:29:06] <zulipbot> (Jonathan Hammell) We will be using the OIDs specified by NIST, though, right?
[13:29:41] <zulipbot> (Mike Ounsworth) @uri the KDF also avoids length mismatch issues where the output length of your KEM does not match the key size of the WRAP. ... that issue would go away with Russ' suggestion to specify triples / doubles: KEM,KDF,WRAP, or KEM,WRAP
[13:29:58] <zulipbot> (Tim Hollebeek) +1 for only standardizing what NIST has selected
[13:30:11] <zulipbot> (Uri Blumenthal) @Mike, yes that would make sense.
[13:30:36] <zulipbot> (Tim Hollebeek) if someone has a good reason to go beyond those, it might make sense, but a good reason is needed, not just "I want to use something else"
[13:31:14] <zulipbot> (Florence D) NIST have put some of the KEMs from round 3 through to further study.
[13:31:32] <zulipbot> (Florence D) Separate from the new signatures process.
[13:31:56] <zulipbot> (Florence D) Nonetheless, I agree with Tim and others on sticking to Kyber for now.
[13:32:09] <zulipbot> (Scott Fluhrer) Uri, BIKE, HQC and ClassicMcEliece going on to round 4
[13:36:03] <zulipbot> (Uri Blumenthal) @Scott, yes - but the likelihood of those being standardized is probably low enough.
[13:36:16] <zulipbot> (Massimiliano Pala) @uri: Is it your point that we should not try to fix KEMs that do not have the property but just require it?
[13:37:09] <zulipbot> (Uri Blumenthal) So, let's stick with KEM that has security properties of Kyber, and *document* them. Thus, any new KEM considered would be at least comparably strong.
[13:38:27] <zulipbot> (Uri Blumenthal) @Massimiliano, PRECISELY. With the current state of the art in Cryptography, we don't need to bend over backwards to salvage broken KEM, Hash, Block-ciphers - there's plenty of "unbroken" ones to choose from.
[13:38:43] <zulipbot> (Mike Ounsworth) I think I'm siding with Uri: we don't need to solve this problem in the abstract; if we pick Kyber1024, then we can pick an AES size than lines up and we're done.
[13:39:29] <zulipbot> (Tim Hollebeek) @Uri, doesn't a new KEM need to have some additional advantages over an existing one?  Otherwise we end up with lots of vanity algorithms and minor variations, which increases complexity and negatively impacts interoperability.
[13:39:48] <zulipbot> (Jonathan Hammell) If there is a goal to align with RFC 9180 (HPKE), then one needs to also consider specification of the various modes (e.g. base, psk, auth, auth_psk).
[13:40:20] <zulipbot> (Uri Blumenthal) @Mike, thanks. Is there any reason for us to consider ciphers with key size less than 256 bits? Or does anybody in the right mind want a *larger* symmetric key size? So, why not settle on 256-bit symmetric key size, and get rid of another unnecessary "degree of freedom"?
[13:40:55] <zulipbot> (Tim Hollebeek) I would be open to thinking about specifying 256-bit symmetric as THE WAY.
[13:42:27] <zulipbot> (Uri Blumenthal) @Tim, +1. Re. new KEM - *if* it's better than the existing one(s), then it *better* be equally strong - aka, possess the security properties of the current .
[13:43:34] <zulipbot> (David Cooper) If you're signing email, you're signing the signedAttributes, not the 25 MB contents of the email.
[13:43:47] <zulipbot> (Dmitry Belyavskiy) This pattern will not also work with FIPS-140-3 requirements
[13:44:00] <zulipbot> (Tim Hollebeek) @Uri: agree completely on must have the same security properties ... definitely necessary, but is it sufficient?  Can I just come up with something that's as good as Kyber, but no better?  That doesn't seem worth allowing to me.  More options with no upside.
[13:45:20] <zulipbot> (Hubert Kario) to add to Dmitry point: the problem is passing in the hash as a string is problematic, passing abstract hash object/handle that the module keeps internal is fine for FIPS 140-3
[13:47:27] <zulipbot> (Michael Richardson) I'd like to spend more time in a future meeting about question 2.
[13:47:49] <zulipbot> (David Cooper) DIlithium shouldn't be a problem since the hash is just of the public key and the message.
[13:48:02] <zulipbot> (Florence D) @Tim -  I think I agree with the sentiment but what's the definition of better here?
[13:48:03] <zulipbot> (Michael Richardson) Does r||hash(r||m)) mitigate our dependance upon the cillison resistant?
[13:48:28] <zulipbot> (Uri Blumenthal) @Tim, you probably could - it's not impossible. But the important security properties would have to stay true. Is it sufficient? I think yes. Re. "as good but no better" - if it is truly "no better" in all aspects, then who in the right mind would accept and use it?
[13:49:02] <zulipbot> (Tim Hollebeek) @Flo: I think that's up to the proposer to claim and for the group to evaluate.  I don't think we can objectively specify "better" beyond what Uri already has (the security properties better not be WORSE ...)
[13:50:37] <zulipbot> (Tadahiko Ito) I am wondering that some method need randomness for pre-hash. I am not sure if there is any problem to generate random number on prehash environment (outside of signing environment). I was trying to think that, but could not find answer, if anyone have any opinion, I would like to here.
[13:50:53] <zulipbot> (Florence D) @Tim: Fair.
[13:54:20] <zulipbot> (Mike Ounsworth) @tadahiko I think that you can do a randomized digest in a protocol envelop format, and then let, for example, FALCON do its randomized digest internally then you get both: an external hash that does not rely on collision-resistance of the hash function AND you can FIPS-validate the whole thing because the FALCON primitive is entirely contained inside the crypto module boundary.
[13:54:39] <zulipbot> (Uri Blumenthal) Early? Unheard of! 😆
[13:55:07] <zulipbot> (Uri Blumenthal) @Mike, yes what you described would work.
[13:55:58] <zulipbot> (Tim Hollebeek) thank you everyone
[13:56:11] <zulipbot> (Hubert Kario) Thank you, see you later!
[13:56:11] <zulipbot> (Quynh Dang) Thank you all
[13:56:24] <zulipbot> (Jan Klaußner) bye!