[vlc-devel] 0.8.6d Release schedule

[Rafaël Carré]

Le vendredi 23 novembre 2007 à 18:14 +0200, Rémi Denis-Courmont a
écrit :
> Le Friday 23 November 2007 17:55:42 Rafaël Carré, vous avez écrit :
> > > > What would be the extra weight of embedding cryptographic software in
> > > > VLC, and then just serve checksums and their signature over an insecure
> > > > channel, then the client do check the checksums' signature with the
> > > > embedded public key ?
> > >
> > > OpenPGP is not trivial to implement, or even integrate.
> > >
> > > > My point is: TLS is used for transport, but I would prefer a solution
> > > > like the GPG-signing of debian APT repositories.
> > >
> > > Of course, OpenPGP would be a lot better than TLS here.
> > > But it ain't going to happen within 0.9.0 let alone 0.8.6d timeframe.
> >
> > libgcrypt can do public key verification, and is already used in gnutls.
> 
> libgcrypt provides the *raw* DSA and RSA algorithms. That's pretty far from 
> what, say, gnupg does.

I understood the basis of libgcrypt, and successfully verified a DSA
signature made by myself :)

Here are the steps:
0/ read rfc 2440 OpenPGP Message Format
1/ Build the public key in VLC (4 DSA MPI: p,q,g,y which are 128, 20,
128, and 128 bytes long)
3/ Download the binary files
2/ Download a gpg signature for each file (.sig format, .asc is just
a .sig base64 encoded)
	Extract some info from the signature:
	* the timestamp when the sig was created
	* the signature type (signature type of a file is always 0x00)
	* 2 bytes (extra check)
	* 2 MPI numbers r and s, used in DSA signing
	* we can also check the algorithm used to sign (should be SHA-1) and
the Public key ID (should be VideoLAN's one). That doesn't add extra
security, but it can save some CPU time if the sig was corrupted.
3/ Start the real work, for each file,
	* Do a SHA-1 hash (with libgcrypt) of the file itself, concatenated
with 5 bytes: the signature type (0x00) and the timestamp of the
signature (4 bytes).
	* Verify that the 2 first bytes of the hash are the 2 bytes we kept
from the signature.
	* Ask libgcrypt to verify if the (built in) public key is associated to
the private key which generated the signature (r and s) from the hash
(we just computed)

And that's all folks !

DSA is used with SHA-1, the length of q (public key) must be the same
than the bit-length output of SHA-1.

An alternative would be to only sign a SHA-256 checksum of the binary
files to be downloaded, but that just adds an extra work (doing the
SHA-256 verification), and really don't know if that's worth, we just
could generate a DSA key using SHA-256 (don't know if that's really
possible... must check)

Wikipedia says SHA-1 is "somewhat compromised" i.e. it's crackable in
less-than-a-billion-year and SHA-256 should be preferred, but we're
using SHA-1 everyday when signing our mails, so I don't know if we can
safely use this.

I strongly believe we can implement public key cryptography to securely
verify binary updates in VLC 0.8.6d

Please comment.

If you're interested in helping, and have trouble understanding
libgcrypt, I'll be happy to share my experience.

-- 
Rafaël Carré <funman at videolan.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071124/1b12a340/attachment.sig>