Re: uuencode -m - pitfall

markus reichelt wrote:
> I'm in the process of tinkering with slackware 12.0 and found a nasty
> pitfall. While 11.0 used "uuencode (GNU sharutils) 4.6.3", slackware
> 12.0 uses "uuencode - GMime 2.2.9"
> 
> The difference between those two is the length of output lines:
> 
> KvmUf1QL24tMm2WqNBngufef05ggcrePvKUj/InniYpWkkGvvVSWaD23PfjP
> 
> of GNU sharutils, and
> 
> tC22uMJKMY1Rnun/EptRojfTdeURMgF4ny/2Mne06sYOag5sSEgWE+BC6UM/yuDjRI0LOxg4otDu
> 
> of GMime 2.2.9
> 
> This broke several scripts on my system which relied on the length of
> output lines of GNU sharutils uuencode. Among them, the examples of
> loop-aes.readme

Thanks for reporting this.

gmime-2.2.9 version of uuencode still appears to be little bit goofy because
it appears to output empty "encoded" line if input data is integer multiple
of 57 bytes.

> As workaround for creating loop-aes v3 keys on systems with
> GMime-uuencode you can use instead
> 
> openssl rand -base64 3120 | head -n 66 | tail -n 65 | gpg ...
> 
> gpg --gen-random 1 3120 | openssl enc -base64 | gpg ...
> 
> head -c 3120 /dev/random | openssl enc -base64 | gpg ...

It is also possible to feed more random data to uuencode, because that
'head -n 66 | tail -n 65' will chop off extra unwanted lines. This works
for both versions of uuencode:

head -c 3705 /dev/random | uuencode -m - | head -n 66 | tail -n 65 \
    | gpg --symmetric -a >/a/usbstick/keyfile.gpg


2925 == 65 lines * 45 bytes of unencoded raw data
3705 == 65 lines * 57 bytes of unencoded raw data

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/