mandos-client suppresses NULL characters from passphrases

Zen Fu zen at torproject.org
Tue Jul 14 20:33:18 CEST 2026


Hello, Teddy!

Thanks a lot for reviewing this. i think you're right, we had one
password with the NUL character that worked with Mandos before we
started using Debian's keyscript=decrypt_keyctl[1] and started failing
after that.

[1] https://cryptsetup-team.pages.debian.net/cryptsetup/README.keyctl.html

i'll route the bug report to the appropriate place, sorry for the noise
and thanks again for your time on this on checking, answering, etc!

--

Teddy Hogeborn <teddy at recompile.se> writes:

> "Zen Fu" <zen at torproject.org> writes:
>
>> Hello, Mandos devs!
>>
>> We're using passphrases randomly generated from /dev/random, and i
>> noticed that mandos-client suppresses NULL characters before handing
>> the passphrase to stdout. With --debug, the passphrase is printed
>> correctly in the output log, but for some reason when printing the
>> passphrase to stdout the NULL character is not printed, resulting in
>> the wrong passphrase.
>>
>> I hope this is the correct place to report bugs.
>
> Yes, it is.
>
>> Steps to reproduce:
>>
>> - generate a passphrase with a NULL character (that's hex 00)
>> - use mandos-client to retrieve it
>> - see that the passphrase output suppresses the NULL character
>
> I'm sorry to report that I cannot reproduce this.  I can generate a
> password containing NUL characters, and it is output correctly by
> mandos-client.  I have also reviewed all the code involved in the
> copying of the password bytes, and all of the code handles the password
> as a buffer of bytes with a length, and never looks at the actual bytes.
>
> I strongly suspect that it's whatever you have reading the password
> which is suppressing the NUL character.  I do note that the systemd
> Password Agents protocol¹ might be interpreted as implying (but does not
> explicitly state) that NUL bytes terminates the password.  Regardless,
> when using a systemd-based initramfs image, we do send the entire
> password (NUL bytes and all) to the indicated socket (including an
> additional terminating NUL byte, as allowed by the protocol), but the
> recieving end might do anything.
>
> 1. <https://systemd.io/PASSWORD_AGENTS/>
>
> /Teddy Hogeborn
>
> -- 
> The Mandos Project
> https://www.recompile.se/mandos
> _______________________________________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se
> https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev
-- 
Zen Fu


More information about the Mandos-Dev mailing list