[Pkg-shadow-devel] Linking Shadow to OpenSSL

[Robert Connolly]

On Monday August 25 2008 03:28:30 pm you wrote:
> > The advantage is that OpenSSL's libcrypto has
> > everything Shadow could possibly want from a crypto
> > library, and almost everyone already has it
> > installed.
>
> But being installed under /usr it's not suitable for
> login/su/passwd... Static linking with libcrypto will
> add about 2 megabytes (IIRC) to all these binaries.

/usr/lib/libcrypto.a can be linked to a dynamically linked /bin/passwd 
(linking a static library to a dynamically linked program). This is very 
common. libcrypto.a is about 48k, and 'strip --unneeded' will remove a bit.

> > > > random sources for salt,
>
> I dismiss all my objections to having random salt. I've
> just had a look at crypt(3) and my /etc/shadow to
> notice that salt is stored as part of the "encrypted
> password" field.
>
> But, as far as I remember, libcrypto doesn't have any
> useful and simple API for getting random data (I mean
> there's no function like get_random_bytes() which
> automatically initializes PRNG by trying /dev/urandom
> first on systems that have it, then resorting to
> /dev/srandom, /dev/random, seeding off the stack
> garbage (like in the mentioned Debian bug), then to
> gettimeofday/clock + pid + hash_of_hostname + whatever
> else). RAND_poll() was the closest such thing IIRC?

As far as I know... RAND_bytes will use /dev/random and will fail otherwise. 
RAND_pseudo_bytes will try to use /dev/urandom, and will also use 
gettimeofday+getpid. Both will attempt to reopen the devices every time the 
program is run.

> In openssl you need to explicitly seed PRNG from
> /dev/urandom, from stack or from time + pid, then you
> can call RAND_bytes. Looks like there's not any
> advantage versus reading from /dev/urandom directly by
> Shadow binaries... Mayby quality of PRNG itself on
> systems that do not have any of the /dev/*random?

See above. RAND_bytes and RAND_pseudo_bytes both initialize themselves.

Using /dev/urandom directly would also be a good idea. I believe 
RAND_pseudo_bytes is a slightly better idea because it is more robust... it 
will still return unique integers even if /dev/urandom is symlinked 
to /dev/null. OpenSSL passes the /dev/*random, and/or gettimeofday+getpid, 
seeds to arc4random() so that the data from RAND_*bytes can not be reverse 
engineered. Whether they can be predicted or not depends on if the attacker 
can determine that the system was misconfigured at the time the password was 
made. The Debian bug was a type of misconfiguration, but hopefully this is 
fixed and will never happen again... and avoiding using RAND_*bytes is not a 
solution... what if the bug was on /dev/random.

This could also be optional via a ./configure option. I'm sure users who do 
not want to link to OpenSSL would like to have the option of 
using /dev/urandom.

So:
--with-openssl
--with-rng-device=/dev/random
--with-openssl-rng (default with --with-openssl)

> > Shared and static linking to OpenSSL could be
> > ./configure options.
>
> Agreed. I suggest just to try to do this and see how
> much will static linking add to shadow binaries.

If shadow-devel is willing to move foreward with adding OpenSSL, I can provide 
the line numbers in OpenSSL's source to prove how it behaves. Please keep in 
mind that the behavior I stated above is from my memory, and it may be 
slightly incorrect (but I doubt it). I can also try out linking libcrypto.a. 
RAND_bytes appears to be in libssl.a (388k), but the majority of libssl.a 
will probably be stripped out of Shadow's programs. I would also like 
a ./configure option for --with-openssl-shared, because there are non-Debian 
users like me who are willing to move OpenSSL to /lib (I have other plans for 
OpenSSL integration).

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20080825/5f2bbf3b/attachment.pgp