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/
