Score:0

openssl functions randomly returns warning: command substitution: ignored null byte in input

im flag

I try to encrypt some loads, here is a minimum working example (is RSA private key)

 to_be_signed="2f93992bb1db9cab0b3b8fc2de0a2863"
 #to_be_signed="7d6d2a584a227574e1c113aab56ea490"
 # Sign poly_1305 with private key
 signature=$(openssl dgst \
   -sha256 \
   -sign ${privkey} \
   <(echo "${to_be_signed}")
 )
 if [ ${?} -eq 0 ]; then
    echo "[*] to_be_signed correctly signed"
 else
    echo "ERROR signing to_be_signed" && exit 2
 fi

First to_be_signed does not generate any warning, second to_be_signed does: warning: command substitution: ignored null byte in input

What on hell does that mean? For some particular values, i get this bash-related warning; is there any flow on the way i use to sign the value ?

I definitely need to play with variables in order to keep their values in memory, i.e. not stored in temporary files on disk. This is a strong requirement.

anx avatar
fr flag
anx
Carefully review your code so fulfilling the "keep it off-disk" requirement does not trick you into restructuring your code to instead put sensitive data into (system-wide visible) *command line arguments*, which then as part of audit/error logging get persisted to disk anyway (if not generally then still occasionally).
im flag
Thank you, i was turning crazy. This has definitely solved the issue i was having. For now, private key is indeed on disk, next step now is to use private key from smartcard. Do you mind copying your comment as an answer? So that i can accept it as solved.
Score:1
fr flag
anx

Your shell will treat some characters different - and a binary signature could contain arbitrary data.

  • If you meant to work with [a-f0-9] (as your input suggests) add -hex to the dgst call.
  • If you meant to work with binary data, change how you pass the null-containing value around. Piping will work, directly using null-byte-containing strings as command arguments or assigning to shell variables will not.

Hint: Use the program shellcheck to generate automatic warnings about this - and all such syntax where your code is likely to trigger unexpected shell parser oddities/features.

dave_thompson_085 avatar
jp flag
`-hex` can work. Quoting a value containing a null byte does not work in bash (or any shell but zsh TTBOMK). And quoting `${var}` or `$(cmd)` used as value in assignment is never necessary; that value is not subject to further expansion. Neither is a herestring. Only _as the command name or an argument, or filename in a redirection_ are they at risk of wordsplitting and globbing.
anx avatar
fr flag
anx
@dave_thompson_085 .. and even if quoting helped with reading, it still would not guarantee the same for using the value. Feel free to edit further if you think my edited version is still incorrect (question is tagged *bash*).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.