From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4725 invoked from network); 17 Mar 2023 09:49:48 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 17 Mar 2023 09:49:48 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 9front; Fri Mar 17 05:48:15 -0400 2023 Message-ID: Date: Fri, 17 Mar 2023 10:48:04 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <4da1abf2-25e8-471d-9ecf-bc09ea182933@sirjofri.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: distributed pipelining injection persistence optimizer Subject: Re: [9front] Totp in factotum Reply-To: 9front@9front.org Precedence: bulk so the key is base32 encoded binary, but the code uses strlen() on the binary output? the rfc uses hex encoding, not sure what is used in practice. the issue with base32 is that there are many different alphabets for it. it is not as standartized as base64. this looks extreamly fishy and wrong. what if the binary secret contains nuls? how's the secret generated? rfc6238 says it should be random binary. so i think the functions needs to take a uchar* for the key and a key-length field, which you get from dec32() return value. -- cinap