On Wed, Feb 23, 2022 at 7:00 PM Robert Sparks <rjsparks@xxxxxxxxxxx> wrote: > If you didn't see the exchange between Carsten et.al. on this point, it > is compelling. > > See https://mailarchive.ietf.org/arch/search/?q=draft-faltstrom-base45 Good thread. Given that this encoding is a fait accompli, discussion of the merits is somewhat moot; that said, it's perhaps useful as a warning about the questionable level of care put into the design. > > * Why is > > Space included as a character? This renders the encoding fragile in many string > > handling contexts. > Well, it also requires encoding of buffers that contain nulls, so > fragility abounds. "Everything is b0rken, so ¯\_(ツ)_/¯" is not really a good response, but my point from above also applies here: there's no point in arguing about it any further. That ship has sailed, the train has left the station, the horse has left the barn, etc. > Show your math (or at least reading of the logic in the draft) a bit > more? Good catch. Let me show you where I went wrong: "QED8WEJ6" [26 14 13 8 32 14 19 6] [[26 14 13] [8 32 14] [19 6]] Base45: [ 26981, 29798, 289 ] where: 26981 = 26+14*45+13*45*45 29798 = 8 + 32*45 + 14*45*45 289 = 19 + 6*45 Bytes: [[105 101] [116 102] [1 33]]** where: 105 = floor(26981 / 256); 101 = 26981 % 256 116 = floor(29798 / 256); 102 = 29798 % 256 1 = floor(289 / 256); 33 = 289 % 256 **Note [1 33] rather than [33 1] for the last pair. Which of course makes this not start with "ietf!", no matter how the decoder behaves. Apologies for the confusion. That said, there is still the potential for a limited covert channel here for some strings. Assume the octet stream you're trying to encode is of odd length and ends in '\x01' or [1]. The proper encoding of this is: Bytes: [1] Base45: [1] [[1 0]] where 1 = 1 + 45*0 [1 0] "10" What if instead you send "W5"? There's no way to get this string via proper encoding, but if you decode naively, you get: "W5" [32 5] [[32 5]] Base45: [ 257 ] where: 257 = 32 + 5*45 Bytes: [[1 1]] where: 1 = floor(257/256); 1 = 257 % 256 which is '\x01\x01' if the decoder outputs both bytes, '\x01' if it outputs only one byte, or results in failure if you do the 257 < 256 check. My point before screwing up the example in my original review was mainly that simply saying "For decoding a Base45 encoded string the inverse operations are performed" doesn't, in my judgment, sufficiently cover this case. FWIW, the decoder I am using properly rejects "W5", but the issue is not the behavior of any particular decoding implementation, but rather of making it clear in the specification that any proper decoder MUST reject such input. I think the document would be improved by a section explicitly describing decoding, of which such a check would be a natural part. Kyle -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
