From marc.vieuille at polytechnique.org Tue Jun 10 23:38:45 2025 From: marc.vieuille at polytechnique.org (Marc Vieuille) Date: Wed, 11 Jun 2025 09:38:45 +0300 Subject: [noise] [ Loading user credentials in the course of a noise protocol handshake] Message-ID: Hello, I am developing a server that allows setting a noise transport "tunnel" over plain HTTP. As part of doing this I need to authenticate a user (acting as noise responder) preserving privacy. User has an account with the server with depending upon case (userId, static Keypair) or (userId, psk) credentials. Server for its part has a static Keypair. I am trying to determine an efficient way to use those credentials for setting the tunnel, ensuring mutual authentication of the peers. I have understood that a possible way forward would be transmitting the userId as encrypted payload of last message of a first handshake (say IN), load user credentials using transmitted userId and then starts a second handshake that uses Server and User credentials. I am thinking of another approach which aims at minimizing the number of messages. Do you see issues with what is described below, or do you envision simpler alternatives ? Thanks for your suggestions. Bests, Marc === here is a brief outline of how this could work. # (userId, static Keypair) case We introduce "u" a new pattern token that works like "s" but replace transmitting static PublicKey by transmitting userId. We assume userId has constant IDLEN size ... ## Changes to WriteMessage(payload, buffer) (spec section 5.3) * For "u" : Appends EncryptAndHash(u.userId) to the buffer. Call MixHash(u.public_key) * For "eu", "ue", "su", "us" same as "es", "se", "ss"... ## Changes to ReadMessage(message, payload_buffer) (spec section 5.3) * For "u": Sets temp to the next IDLEN + 16 bytes of the message if HasKey() == True, or to the next IDLEN bytes otherwise. Sets userId to DecryptAndHash(temp). Load u.public_key using userId. Call MixHash(u.public_key). Set rs (which must be empty) to u.public_key... * For "eu", "ue", "su", "us" same as "es", "se", "ss"... # (userId, psk) case We introduce "upsk" a new pattern token that works like "psk" but requires transmitting userId prior to mixing the psk. We assume userId has constant IDLEN size ... ## Changes to WriteMessage(payload, buffer) (spec section 5.3 and 9.2) * For "upsk": Appends EncryptAndHash(u.userId) to the buffer. Call MixKeyAndHash(u.psk) ## Changes to ReadMessage(message, payload_buffer) (spec section 5.3 and 9.2) * For "upsk": Sets temp to the next IDLEN + 16 bytes of the message if HasKey() == True, or to the next IDLEN bytes otherwise. Sets userId to DecryptAndHash(temp). Load u.psk using userId. Call MixKeyAndHash(u.psk).