Figaro's Password Manager

This is the reply from the secret-agent author. Looks like he's patched
up the bugs I found, and now I'd highly recommend we use gtksecentry.c
from that project (it is quite careful to avoid leaving copies of data
around in gtk calls---see previous posts).

In fact, if anyone reading this knows someone on the gtk team, I'd
recommend that gtksecentry.c be included in the gtk library---it would
have to be well commented that the underlying libX calls are not
secured, but at least its an effort!

John

Robert Bihlmeyer wrote:
> 
> Hi,
> 
> I'm sorry it took me so long to answer.
> 
> "J. Steele" <jhs28@...> writes:
> 
> > I'm hoping to use your gtk_secure_entry class in another application
> > with sensitive information (fpm.sourceforge.net).
> 
> You're welcome! I must check out fpm some time...
> 
> > Anyway, I was taking a look at how you used gtk for entry of sensitive
> > information. I had given up on trying to secure gtk_entry widgets, and I
> > see you have rewriten gtkentry.c into your gtksecentry.c to avoid calls
> > to the gtk_editable methods and to use secure memory which is wiped on
> > g_free calls).
> 
> That was the point, yes.
> 
> > 1. There is an insecure memcpy in gtk_secure_entry_insert_text (lines
> > 1786, 1802, 1810, 1820, & 1846 all deal with memory which typically
> > contains copies of "classified" information):
> 
> You're perfectly right, I missed these. That's fixed now.
> 
> > 2. Speaking of that gtk_secure_entry_key_press call in line 1271, isn't
> > the "classified" information provided in the event pointer given to the
> > gtk_secure_entry_key_press routine? The memory for this event structure
> > is allocated via gtk library calls, and therefore cannot be secure
> > (without changing the gtk library). My (less sophisticated) approach to
> > gtk insecurities may be the only way to address this insecurity. I am
> > considering redefining g_free to wipe _all_ memory allocated via a
> > g_malloc call on a glibc system.
> 
> That's certainly a good thing to do. The small performance loss is
> tolerable in a security application. I don't think there's a portable
> way to do that, though.
> 
> But even changing the glib (de)allocation functions will only get you
> one step further. Xlib will still copy the key through unsafe memory.
> So, for glibc systems, a better way is probably to hang yourself onto
> __free_hook. You can then wipe ALL memory going through the hands of
> the C library. I will look into doing that.
> 
> Finally, the X server, which may not even run on the same machine,
> certainly has a copy of the key as well. I don't think you can prevent
> this easily. One can only hope, that X will reuse the space as soon as
> possible.
> 
> > 3. Finally, you might also need to consider the security of the
> > gdw_mdstowcs in lines 1804-5:
> >     insertion_length = gdk_mbstowcs (insertion_text, new_text_nt,
> >                                    new_text_length);
> 
> Hmm, this function does use temporary storage as allocated by the X
> libs. So it is not safe, unless you wipe everything. Sigh.
> 
> > (I dislike dealing with unicode when it comes to security applications,
> > but I suppose any gtk widget needs to be able to accept it!)
> 
> I must admit that I have no experience with multibyte input methods. I
> think that's up to the Asian folk to decide. I don't know if they use
> double-byte letters in passphrases, for example.
> 
> > I hope at least some of this is useful to you. I'd be very interested in
> > knowing what you think of item 2. I was thinking I'd just use standard
> > gtk_entry widgets, redefine g_free to wipe all g_free calls, and then
> > tell users they must link against glibc to have a chance at a secure
> > app.
> 
> See my point about the X server. Of course, by just wiping memory, you
> miss out about the mlock support. Depending on how long-lived your app
> is, that may be an issue.
> 
> Alas, I wish we would all have systems with encrypted swap, and a C
> lib that would optionally wipe all freed memory. We wouldn't have to
> jump trough a lot of hoops.
> 
> --
> Robbe
> 
>   ------------------------------------------------------------------------
>                    Name: signature.ng
>    signature.ng    Type: application/pgp-signature
>                Encoding: 7bit

John,

Good questions. I know of two "standard" methods for passphrase hashing
(which have been analyized for their difficultly in mounting dictionary
attacks): PKCS #5 and OpenPGP/GnuPG.

There is PKCS a standard for this: PKCS #5 describes a method for
encrypting a string with a secret key derived from a password.
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html

PKCS #5 suggests new applications use encryption algorithm PBES2 (which
is an interated salted passphrase hashing followed by a conventional
block or stream cipher). The CFB cipher mode we'll used by GnuPG to
convert a block cipher into a stream cipher is another standard (but I
don't know where its defined).

The format for packing PCKS #5 messages is explained in that ASN format
language which I've never learnt. Basically, we need to communicate (in
cleartext) the salt, # of hashing iterations, along with the cipher,
cipher mode, key length and hash function. Luckily, we don't really need
to follow this part of the standard.

GnuPG's method is described in http://www.gnupg.org/rfc2440.html. It is
similar to PKCS, but is a more detailed specification since the spec.
also defines the data sizes (e.g. for salt) which are packed into the
encoded message.  Code is in g10/passphrase.c:hash_passphrase() n.b. The
default string to key mode, s2k->mode, is 3 (iterated + salted).


REGARDING FILE FORMATS.  

We could make the fpm-passfile format GnuPG compatible (so that gpg -d
filename would decrypt to the xml data). Check encode.c:encode_simple().
The OpenPGP spec contains standards for inserting all the information
you need to make the decryption key from the passphrase (e.g. salt,
etc). I believe we could also insert comments to declare the file is
from fpm. Also, OpenPGP spec. would allow us to optionally save in ascii
and/or do data compression (all with existing code).

I don't know which way to go on this. I honestly don't really see the
value in being able to decrypt with GnuPG (you just get xml out), but it
does prove standards compliance. I believe the code overhead would be
limited, but the code would be less direct (instead of opening a file
and dumping binary out, we'd need to write OpenPGP "packets" via calls
to GnuPG's iobuf commands).

Additionally, a commitment to the OpenPGP format would essentially tie
us to GnuPG code (although the bulk of the code could be replaced by the
gcrypt library if it becomes real). 

What do you think?

WHICH HASH?

As far as what hash to use, MD5 is not recommened for new applications.
In 1996, researchers proved a portion of the hash is susceptible to
collision generation (so message signing authority is under attack).
Since we are using the hash to whiten the key space given the colored
passphrase, I would suspect we only need to rely on strong one-way
function. Even so, most reputible documents recommend SHA-1 (a modified
version of SHA) or RIPEME-160 (hasn't been around as long as SHA-1, but
SHA-1 was invented by the NSA, so some conspiracy types don't like it.)

GnuPG hashing is user-defined (can be MD5, but defaults to RIPEMD-160). 

Lots more information is in the RSA FAQ above and
http://home.clara.net/scramdisk/pgpfaq.html

That's probably it from me until Wednesday (unless something comes up
today).

Regards,

		John

p.s.: I mailed SourceForge about the CVS commits showing at 0, and they
said it was a known bug. They may have changed something since they said
to "use" the account again and see if the numbers change. So next time
one of us does a commit...

John Conneely wrote:
> Speaking of which, it would be wise for us to do a little research and decide
> which hash function makes sense for us to use in FPM.  I originally used

> While you've poked around GnuPG, have you noticed how they handle their
> pass-phrase?  That may have been where I got the idea to use MD5... but if
> they use something else, I'd like to look at it.

This was one of my candidates when I originally wrote FPM.  I don't remember
why I rejected it; it might be, as you say, because a hash function didn't
exist.

Speaking of which, it would be wise for us to do a little research and decide
which hash function makes sense for us to use in FPM.  I originally used
MD5 because I've seen it used this way in the past, but I remember reading
somewhere (sorry, I don't remember where) that it had recently proven a
weak hash for certain types of cryptographic functions.  I'd like us to
understand what those are and decide if there is a better one.

While you've poked around GnuPG, have you noticed how they handle their
pass-phrase?  That may have been where I got the idea to use MD5... but if
they use something else, I'd like to look at it.

John

On Wed, Nov 15, 2000 at 05:59:22PM +0000, J.H. Steele wrote:
> I found the following crypto library, but I'm afraid that distribution
> (and, it seems, use and auditing) is limited now. Also, it doesn't have
> hash functions. I'm inclined to stay with statically linked GnuPG code for
> now.
> 
> 	http://mcrypt.hellug.gr/
> 
> John
> 
> _______________________________________________
> FPM-devel mailing list
> FPM-devel@...
> http://lists.sourceforge.net/mailman/listinfo/fpm-devel

I found the following crypto library, but I'm afraid that distribution
(and, it seems, use and auditing) is limited now. Also, it doesn't have
hash functions. I'm inclined to stay with statically linked GnuPG code for
now.

	http://mcrypt.hellug.gr/

John

On Tue, 14 Nov 2000, John Conneely wrote:

> I think your proposal sounds great, provided you are comfortable with
> the GnuPG code.  Even though I'm not terribly happy with the FSF right

I think the GnuPG code looks good, and I was previously only concerned
with how you were calling the low level portions of blowfish.c from
fpm_crypt.c (in 0.53). The GnuPG cipher.c implementation abstracts all the
issues of block sizes and such away so that init. vectors are dealt with
in what I believe is a standard way for block ciphers. (Thus you don't
have to worry about the length of the plaintext in relation to blocksize.)
By keeping all of the GnuPG tree unmodified, I'm comfortable that I can
implement a nice clean set of fpm_cipher routines that should be a no
brainer to audit (provided you trust GnuPG and our memory handling which
the GnuPG routines will be running).
  
> 
> Thanks for the good work!  I haven't personally been able to get as much
done
> as I'd like, but hopefully that will change later this week!
>

No problem! Remember, this is supposed to be fun. I probably won't do
anything until Sunday at best either.

John


p.s.: I agree on staying pure GPLed. Too much headache for others if we
made an exception. (And then we cut ourselves off from being able to
incorporate any pure GPL code.) Yuck---too much legal though this week
(esp. with the election!). BTW, do you happen to live in Florida? If so,
I hope the state is still running by the end of the week!

Regarding encryption:

I've had a preliminary look at GnuPG code. The frontend to ciphers,
message digests, and random numbers is remarkably similar to that of
openssl. Unfortunately, to get that front end, you need to include most
of cipher/ util/ and include/ directories (around 800K). 

GnuPG is quite close to being a good GPLed crypto library already.
Unfortunately I think it would take a good deal of work to make GnuPG
into library calls---esp with ensuring the secmen and logging mechanisms
are initialized and that secmem doesn't run out of memory! I don't think
I'm qualified to step up to this task.

I propose that fpm take the file size hit of including all the 800K of
GnuPG I mentioned above. I'd want to include _completely_ unmodified
code except for deleting the util/secmem.c file and defining wrappers to
our fpm_mem routines in fpm_mem.c or fpm_util.c.

After this, the encryption is simple as in GnuPG's tools/bftest.c
example:

    hd = cipher_open( algo, CIPHER_MODE_CFB, 0 );
    cipher_setkey( hd, *argv, strlen(*argv) );
    cipher_setiv( hd, NULL, 0 );
    while( (n = fread( buf, 1, size, stdin )) > 0 ) 
    cipher_encrypt( hd, buf, buf, n );
    cipher_close(hd);

Message digesting is similar. 

I'm comfortable with the security of this approach as we leave all the
bit feedback and init. vector handling to untouched GnuPG code.

What do you think?

John




"J. Steele" wrote:

> Sounds good to me to work off wrapped GnuPG code for now. Since I don't
> know much about the gtk stuff and libxml, I'll work on fpm_crypt then.
> (But first I'll probably fix up fpm_mem to do memory tracking so we can
> do memory clears on fatal signals.)
>

A few administrative questions:

1. How do you handle #ifdef options. (e.g. #ifdef FPM_MEM_WARN_ON_LEAK).
I suppose they should be documented in the .h file, but I'd suspect we
should do something like:

fpm.h
#define DEVELOPMENT_VERSION

fpm_mem.h
#ifdef DEVELOPMENT_VERSION
#define FPM_MEM_WARN_ON_LEAK
#endif

And then modifiy the Makefile.am to define DEVELOPMENT_VERSION on the
complier line. How do you do this?

2. More generally, how to you use automake? (I don't know where to start
reading docs.) We need to do have configure test if we're using GLIBC to
know if we should define FPM_REDEFINE_FREE.

(Sorry for the double post before---netscape crashed during the send, so
I fired up again and resent the draft. )

I just commited the g_hash memory tracking changes to CVS. As always,
make runs and all seems well. I've left a single non-#ifdef-ed
fpm_warning() message in fpm_mem_exit() so that we'll always see a
report on the number of "leaked" memory segments that were wiped up
before exiting.

Hope it looks good to you.

John


"J. Steele" wrote:
> 
> Sounds good to me to work off wrapped GnuPG code for now. Since I don't
> know much about the gtk stuff and libxml, I'll work on fpm_crypt then.
> (But first I'll probably fix up fpm_mem to do memory tracking so we can
> do memory clears on fatal signals.)
>

John Conneely wrote:
> 
> Well, I do believe in free software, and I believe in keeping free software
> free.  I just don't see why we can't dynamically link with other free libraries
> that just don't happen to use the FSF's license.
>
Dynamic linking is a big topic for licensing wars, so its not surprising
we've had a problem on this front. I do not pretend to understand how a
GPL program cannot link to OpenSSL, but can (seemingly) be legally
compiled with Solaris' proprietary complier. Perhaps that is not legal,
but even if you use gcc, at some point GPL code is calling Solaris
libraries. The accepted interpretation seems to be that it is safe to
link with OS libraries. Of course the nebulous part is the definition of
what constitutes an OS (e.g Microsoft with IE). I also don't see how
Wine can legaly use MS dlls (when surely the MS license precludes such
use).

> ...
> 
> How does this sound?

Sounds good to me to work off wrapped GnuPG code for now. Since I don't
know much about the gtk stuff and libxml, I'll work on fpm_crypt then.
(But first I'll probably fix up fpm_mem to do memory tracking so we can
do memory clears on fatal signals.)

Oh, during saves I think we'll need to use xmlDocDumpMemory() to write
the xml out to fpm memory so we can then pass this memory address and
length over to the encryption code. We might need to pad out the memory
to allow the use of block ciphers, unless we want to use stream mode.
More thought required regarding security.)

John


> 
> John
> 
> BTW - When picking encryption methods, we need to make sure we don't use
> algorithms which are encumbered by patents.  I forget... how does RC4 fare
> with this?
> 

Yes. I agree. I have assumed that since rc4 is GPLed in Netscape code,
that it was unencumbered. I might be wrong, but I think rc4 might be the
cipher that was leaked from RSA labs who then decided to release it to
public domain since the cat was already out of the bag... odd though.

John Conneely wrote:
> 
> Well, I do believe in free software, and I believe in keeping free software
> free.  I just don't see why we can't dynamically link with other free libraries
> that just don't happen to use the FSF's license.
>
Dynamic linking is a big topic for licensing wars, so its not surprising
we've had a problem on this front. I do not pretend to understand how a
GPL program cannot link to OpenSSL, but can (seemingly) be legally
compiled with Solaris' proprietary complier. Perhaps that is not legal,
but even if you use gcc, at some point GPL code is calling Solaris
libraries. The accepted interpretation seems to be that it is safe to
link with OS libraries. Of course the nebulous part is the definition of
what constitutes an OS (e.g Microsoft with IE). I also don't see how
Wine can legaly use MS dlls (when surely the MS license precludes such
use).

> ...
> 
> How does this sound?

Sounds good to me to work off wrapped GnuPG code for now. Since I don't
know much about the gtk stuff and libxml, I'll work on fpm_crypt then.
(But first I'll probably fix up fpm_mem to do memory tracking so we can
do memory clears on fatal signals.)

Oh, during saves I think we'll need to use xmlDocDumpMemory() to write
the xml out to fpm memory so we can then pass this memory address and
length over to the encryption code. We might need to pad out the memory
to allow the use of block ciphers, unless we want to use stream mode.
More thought required regarding security.)

John


> 
> John
> 
> BTW - When picking encryption methods, we need to make sure we don't use
> algorithms which are encumbered by patents.  I forget... how does RC4 fare
> with this?
> 

Yes. I agree. I have assumed that since rc4 is GPLed in Netscape code,
that it was unencumbered. I might be wrong, but I think rc4 might be the
cipher that was leaked from RSA labs who then decided to release it to
public domain since the cat was already out of the bag... odd though.

Well, I do believe in free software, and I believe in keeping free software
free.  I just don't see why we can't dynamically link with other free libraries
that just don't happen to use the FSF's license.

I'm certainly not asking you to surrender your copyright, though!  I'd much
rather work with you on licensing terms for FPM, and I'll risk not being able
to change the license later if I fail to convince at that time that it is a
good idea.  The only time I'd ask a contributer to surrender their copyright
is for very minor contributions.  I certainly wouldn't consider your
contributions to date minor.

I'm encouraged by your belief that we can work this out with well audited
GPL code.  If we really can, that would be ideal.

The benefit of using encryption code from GnuPG like I did in v0.53 is that
it reduces the dependencies FPM has.  The reason I went this route last time
was that openssl didn't come with most distributions and installing it wasn't
trivial, especially doing it legally in the US.  The downside to using GnuPG
code in this way is that we are more prone to opening security holes through
implementation problems, especially with the wrapper functions.

Anyway, how does this sound?  Let's start out with GPL, and retain shared
copyright.  We will start out with GnuPG code for the encryption as we do
now, but create wrapper functions for everything so that we can switch to
something else if we find we run into problems later.  In fact, we may want
to release the wrapper functions as a GGPL library so that other projects
can use it too that are in the same boat as us.  If we do this, we may
attract a better audit of the interface functions than FPM alone would
generate.  (We can't release the library under the LGPL because the GnuPG
encryption code is already covered under the GGPL.)

If over the next few weeks we run into problems with using the GnuPG code,
we just need to redefine the interface to bind to another library, like
openssl.  In this case, you and I would need to hash out how we would need to
amend the GPL to allow linking with openssl.  I think we both agree that we
want a license that keeps derivative works based on FPM as free software, but
allows us to create the most secure implementation possible.

After our initial release, I'd want to attract attention to our project and
attempt to get others to audit our code.  After I feel that at least a few
people have looked at the code, we will allow ourselves to commit to our
implementation and software license by being less careful of who owns the
copyright.

How does this sound?

John

BTW - When picking encryption methods, we need to make sure we don't use
algorithms which are encumbered by patents.  I forget... how does RC4 fare
with this?  



On Sat, Nov 11, 2000 at 05:03:52PM +0000, J.H. Steele wrote:
> John,
> 
> I'm sure we can work it out using well audited GPL code if you want (it'd
> just take a bit more effort). Afterall, both GnuPG and Netscape 6
> (specifically, its NSS security) are both GPLed. 
> 
> It seems the GPL TSL (SSL) library is hosted at:
> http://gnutls.hellug.gr/
> The following notice is posted at that site:
> "GNUTLS is far from being complete and it was never audited so you
> shouldn't use it in any real world projects, yet"
> 
> NSS is somewhat documented at
> http://www.mozilla.org/projects/security/pki/nss/release_notes_31.html. 
> Specific algorithms are listed at:
> http://www.mozilla.org/projects/security/pki/nss/algorithms.html.
> It seems this code provides triple DES or RC4-128 encryption. I have no
> idea how difficult this library is to build and/or use. It does have the
> potential for enormous distribution since it'll be bundled with Netscape
> (I assume in dynamic library form).
> 
> As a first strike, I'd be happy with completely unaltered GnuPG
> code. (Which seems very close to what you did in FPM-0.53.) Unfortunately,
> we'd probably need to build wrappers for the GnuPG util functions
> (esp. memory handling). I'll take a closer look at this code.
> 
> I agree that the situation is crazy, but that's the cost of the GPL. I
> suppose I might be selfish, but I'm fairly set on using the GPL (esp
> for crypto and for small projects which can be easily taken).
> 
> If that situation is unacceptable for you, then I would probably consider
> surrendering my copyright to you but not really working in earnest any
> more (not that I've done a whole lot of actual code to date!). Please
> understand, though---no hard feelings here if that's what you want.
> 
> Hope my proposal sounds good.
> 
> John
> 
> 
> 
> On Sat, 11 Nov 2000, John Conneely wrote:
> 
> > This is absolutely ridiculous!  OpenSSL now comes standard with Red Hat 7.0;
> > saying GPL programs can't use it doesn't make any sense, and is bad for free
> > software in general.
> > 
> > Since we are doing a complete rewrite, we have ultimate flexibility in our
> > license.  I'm open to suggestions for a substitute to the GPL.  I'd like to
> > use a license with the general intent of the GPL, but I don't want to be
> > told I can't use state of the art free encryption libraries.  If that means
> > taking a BSD style license and having our software vulnerable to having
> > derivative non-free works, so be it.  But I think it should be possible to have
> > a GPL like license that allows linking with non-GPL free libraries.
> > 
> > I read on slashdot that the FSF is working on the GPL, version 3.  I wonder
> > if that might lift some of these barriers.  We should probably write RMS and
> > let him know that this restriction is causing a free software project to have
> > second thoughts of using the GPL.
> > 
> > John, while we sort this out, let's be careful about submissions we accept on
> > FPM v0.60.  I want to retain the ability to change the license of FPM until I
> > feel comfortable with it.  For now, lets make sure any minor submission or
> > patches to FPM's code base include a transfer of the copyright of those
> > modifications to one of us.  That way, as long as we agree on license
> > modifications, we have the power to do it legally.  If someone contributes in a
> > more substantial way, we will consider adding them to our circle of trust.
> > Eventually, I hope these things get sorted out and we can commit to a license
> > by allowing even minor contributors to retain copyright on their modifications.
> > 
> > As for using OpenSSL: make the choice based on technical reasons, not legal
> > ones.  We will figure out what we need to do with the license to make it work.
> > 
> 
> _______________________________________________
> FPM-devel mailing list
> FPM-devel@...
> http://lists.sourceforge.net/mailman/listinfo/fpm-devel

John,

I'm sure we can work it out using well audited GPL code if you want (it'd
just take a bit more effort). Afterall, both GnuPG and Netscape 6
(specifically, its NSS security) are both GPLed. 

It seems the GPL TSL (SSL) library is hosted at:
http://gnutls.hellug.gr/
The following notice is posted at that site:
"GNUTLS is far from being complete and it was never audited so you
shouldn't use it in any real world projects, yet"

NSS is somewhat documented at
http://www.mozilla.org/projects/security/pki/nss/release_notes_31.html. 
Specific algorithms are listed at:
http://www.mozilla.org/projects/security/pki/nss/algorithms.html.
It seems this code provides triple DES or RC4-128 encryption. I have no
idea how difficult this library is to build and/or use. It does have the
potential for enormous distribution since it'll be bundled with Netscape
(I assume in dynamic library form).

As a first strike, I'd be happy with completely unaltered GnuPG
code. (Which seems very close to what you did in FPM-0.53.) Unfortunately,
we'd probably need to build wrappers for the GnuPG util functions
(esp. memory handling). I'll take a closer look at this code.

I agree that the situation is crazy, but that's the cost of the GPL. I
suppose I might be selfish, but I'm fairly set on using the GPL (esp
for crypto and for small projects which can be easily taken).

If that situation is unacceptable for you, then I would probably consider
surrendering my copyright to you but not really working in earnest any
more (not that I've done a whole lot of actual code to date!). Please
understand, though---no hard feelings here if that's what you want.

Hope my proposal sounds good.

John



On Sat, 11 Nov 2000, John Conneely wrote:

> This is absolutely ridiculous!  OpenSSL now comes standard with Red Hat 7.0;
> saying GPL programs can't use it doesn't make any sense, and is bad for free
> software in general.
> 
> Since we are doing a complete rewrite, we have ultimate flexibility in our
> license.  I'm open to suggestions for a substitute to the GPL.  I'd like to
> use a license with the general intent of the GPL, but I don't want to be
> told I can't use state of the art free encryption libraries.  If that means
> taking a BSD style license and having our software vulnerable to having
> derivative non-free works, so be it.  But I think it should be possible to have
> a GPL like license that allows linking with non-GPL free libraries.
> 
> I read on slashdot that the FSF is working on the GPL, version 3.  I wonder
> if that might lift some of these barriers.  We should probably write RMS and
> let him know that this restriction is causing a free software project to have
> second thoughts of using the GPL.
> 
> John, while we sort this out, let's be careful about submissions we accept on
> FPM v0.60.  I want to retain the ability to change the license of FPM until I
> feel comfortable with it.  For now, lets make sure any minor submission or
> patches to FPM's code base include a transfer of the copyright of those
> modifications to one of us.  That way, as long as we agree on license
> modifications, we have the power to do it legally.  If someone contributes in a
> more substantial way, we will consider adding them to our circle of trust.
> Eventually, I hope these things get sorted out and we can commit to a license
> by allowing even minor contributors to retain copyright on their modifications.
> 
> As for using OpenSSL: make the choice based on technical reasons, not legal
> ones.  We will figure out what we need to do with the license to make it work.
>

This is absolutely ridiculous!  OpenSSL now comes standard with Red Hat 7.0;
saying GPL programs can't use it doesn't make any sense, and is bad for free
software in general.

Since we are doing a complete rewrite, we have ultimate flexibility in our
license.  I'm open to suggestions for a substitute to the GPL.  I'd like to
use a license with the general intent of the GPL, but I don't want to be
told I can't use state of the art free encryption libraries.  If that means
taking a BSD style license and having our software vulnerable to having
derivative non-free works, so be it.  But I think it should be possible to have
a GPL like license that allows linking with non-GPL free libraries.

I read on slashdot that the FSF is working on the GPL, version 3.  I wonder
if that might lift some of these barriers.  We should probably write RMS and
let him know that this restriction is causing a free software project to have
second thoughts of using the GPL.

John, while we sort this out, let's be careful about submissions we accept on
FPM v0.60.  I want to retain the ability to change the license of FPM until I
feel comfortable with it.  For now, lets make sure any minor submission or
patches to FPM's code base include a transfer of the copyright of those
modifications to one of us.  That way, as long as we agree on license
modifications, we have the power to do it legally.  If someone contributes in a
more substantial way, we will consider adding them to our circle of trust.
Eventually, I hope these things get sorted out and we can commit to a license
by allowing even minor contributors to retain copyright on their modifications.

As for using OpenSSL: make the choice based on technical reasons, not legal
ones.  We will figure out what we need to do with the license to make it work.

John

On Fri, Nov 10, 2000 at 08:48:33PM +0000, J. Steele wrote:
> Bad news on the openssl front: It's incompatible with the GPL.
> 
> Truly a sad situation. I dread the concept of implementing (and
> auditing):
> 	*good pseudo-random number sources (is /dev/random good enough?)
> 	*proper message digest (hashing)
> 	*proper en/decryption
> 
> I suppose that means more digging into GnuPG code. I suppose fpm-0.53
> had md5 and blowfish from GnuPG. I am intrigued by the openssl PRNG
> functions for "cryptographically secure" sequences (there are separate
> calls for noncrypto. secure sequences)---makes me question just opening
> /dev/random and snarfing bytes.
> 
> Thats all for now.
> 
> John
> 
> Free Software Foundation wrote:
> > 
> > [ I apologize for the late response to this message.  Email to this address
> >   was backlogged, and we are struggling to catch-up. ]
> > 
> > J. Steele wrote:
> > > Free Software Foundataion Representative:
> > >
> > > I want to use the GPL for an application I am working on, but I need your help
> > > in understanding the implications of the license.
> > >
> > > I hope to use some of the cryptographic functions provided in OpenSSL
> > > (www.openssl.org). My understanding from their documentation is that OpenSSL has
> > > an "Apache style license" (which looks like an old style BSD license with the
> > > advertising clause).
> > 
> > The OpenSSL license is a free software license that is incompatible with the
> > GPL.
> > 
> > > May I dynamically link my GPL-ed application to OpenSSL?
> > 
> > You cannot do this without a special exception, lest redistribution of your
> > software will not be legal.
> > 
> > > If not, how are GPL developers expected to do crypto?
> > 
> > This is a real problem, That's why we have it on our task list (see
> > http://www.gnu.org/prep/tasks.html#SEC9).
> > 
> > > I know GnuPG writes it own code, but I do not want to copy the GnuPG
> > > crypto code into my development tree and then run the risk of implementing
> > > it incorrectly. Using crypto code correctly is critical to security, and I
> > > would prefer to have well defined libaries to which I can simply feed
> > > streams of data for encryption.
> > 
> > I believe we have some people who are working on a general cryptography
> > library that is under a GPL compatible license.  Would you like me to try to
> > get you in touch with them?
> > 
> > --
> > Bradley M. Kuhn
> > Free Software Foundation     |  Phone: +1-617-542-5942
> > 59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
> > Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org
> _______________________________________________
> FPM-devel mailing list
> FPM-devel@...
> http://lists.sourceforge.net/mailman/listinfo/fpm-devel

Bad news on the openssl front: It's incompatible with the GPL.

Truly a sad situation. I dread the concept of implementing (and
auditing):
	*good pseudo-random number sources (is /dev/random good enough?)
	*proper message digest (hashing)
	*proper en/decryption

I suppose that means more digging into GnuPG code. I suppose fpm-0.53
had md5 and blowfish from GnuPG. I am intrigued by the openssl PRNG
functions for "cryptographically secure" sequences (there are separate
calls for noncrypto. secure sequences)---makes me question just opening
/dev/random and snarfing bytes.

Thats all for now.

John

Free Software Foundation wrote:
> 
> [ I apologize for the late response to this message.  Email to this address
>   was backlogged, and we are struggling to catch-up. ]
> 
> J. Steele wrote:
> > Free Software Foundataion Representative:
> >
> > I want to use the GPL for an application I am working on, but I need your help
> > in understanding the implications of the license.
> >
> > I hope to use some of the cryptographic functions provided in OpenSSL
> > (www.openssl.org). My understanding from their documentation is that OpenSSL has
> > an "Apache style license" (which looks like an old style BSD license with the
> > advertising clause).
> 
> The OpenSSL license is a free software license that is incompatible with the
> GPL.
> 
> > May I dynamically link my GPL-ed application to OpenSSL?
> 
> You cannot do this without a special exception, lest redistribution of your
> software will not be legal.
> 
> > If not, how are GPL developers expected to do crypto?
> 
> This is a real problem, That's why we have it on our task list (see
> http://www.gnu.org/prep/tasks.html#SEC9).
> 
> > I know GnuPG writes it own code, but I do not want to copy the GnuPG
> > crypto code into my development tree and then run the risk of implementing
> > it incorrectly. Using crypto code correctly is critical to security, and I
> > would prefer to have well defined libaries to which I can simply feed
> > streams of data for encryption.
> 
> I believe we have some people who are working on a general cryptography
> library that is under a GPL compatible license.  Would you like me to try to
> get you in touch with them?
> 
> --
> Bradley M. Kuhn
> Free Software Foundation     |  Phone: +1-617-542-5942
> 59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
> Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org

I suppose the next work I'll do in fpm is fixing fpm_mem to use ghash lists so
that fpm_freeall can work. 

But I'd also like to start on fpm_crypt. I'd prefer to link with openssl, but
I'm no expert on the legalities of this. openssl is a BSD style license. By
dynamically linking, I don't know if we are "redistributing" openssl. Worst
case, I think we'd just need to credit the authors and include their license.

I'll email this question to the opensll dev list. If linking is okay, would you
be satisfied with using opensll? (I just feel much more comfortable using well a
well audited implementation than taking source code and calling it ourself.)

Also, I do not know the details of current US crypto export rules. I know that
we can release any code we want as long as it is open source. I don't know if
this requires filing a statement of classification with the Dept. of Commerce.

Sourceforge should maintain a FAQ on this---afterall they are liable if they
break export rules regardless of the source of the source code!

I suppose I'll ask the openssl developers about this, also.

John

Darn! I just committed my (sometimes extensive) changes to the following files
with the incorrect CVS comment:

M fpm_gui_gnome.c
M fpm_gui_gnome.h
M fpm_gui_list.c
M fpm_mem.c
M fpm_mem.h
M fpm_passfile.c
M fpm_passfile.h
M fpm_passitem.c
M fpm_passitem.h
M main.c
M HACKING
M Makefile.am

My emacs cvs commit was getting fouled up since my sourceforge ssh key hasn't
been accepted yet, so I was going along with standard command line cvs, and I'm
just not used to it (basic emacs cvs is quite strict about only commiting one
file at a time).

I'm terribly sorry.

Developers don't have shell access to cvs.sourceforge.net, so I can't go edit
the RCS diff files myself. I could commit a new version with the correct
comments, but I'll won't do this messiness unless you ask.

For now, I list what the comments should have been below.

John

M fpm_gui_gnome.c
M fpm_gui_gnome.h
Added outline for two functions needed for tty/gui password prompting logic.

M fpm_gui_list.c
Added GPL header.

M fpm_mem.c
M fpm_mem.h
Renamed most functions to avoid fpm_mem.
Changed fpm_strcpyover to return void.
Changed fpm_malloc to use g_malloc (not g_malloc0).
Added fpm_malloc0.
Added redefinition for libc free() which wipes before free (need to change
autoconf stuff to compile with -DFPM_REDEFINE_FREE).
Added in outline for several functions we need (fpm_mem_exit, fpm_freeall,
fpm_clear...)

M fpm_passfile.c
M fpm_passfile.h
Proposed a new struct, FpmDB, to hold all info regarding an open passfile (e.g.
filename, key, pass_list, etc). We could use this to allow multiple passfiles
open at once.
Added outline for functions to load salt, load data, and save.

M fpm_passitem.c
M fpm_passitem.h
Changes for fpm_mem_* function rename.
Added GPL header.


M main.c
Added in use of fpm_util functions to clean up code (e.g. drop privs, stop
coredumps).
Added in example of prompting for password. If controlling terminal is tty,
you'll get prompted on tty, otherwise (e.g. ./fpm < /dev/null), you'll get
prompted by the non-exisitant gui which then quits the program.

M HACKING
M Makefile.am
Added all the new files.

Where would you like function usage comment headers to go? I put them in .c
files, and make the .h files bare. 

But I could certainly see the argument for putting public functions' comments in
the .h file and then only commenting the private functions in the .c. 

With all those comments, the .h files then get cluttered...

Which do you prefer? 

John

In changes I just commited to cvs, please note the following important changes:

Most fpm_mem_* functions are now fpm_* (e.g. fpm_malloc).

fpm_malloc doesn't zero the memory (but there's now a fpm_malloc0).

Four messaging routines (defined in fpm_util.h):
	fpm_message
	fpm_warning
	fpm_error (This is NOT fatal, but perhaps it should be...)
	fpm_debug

A new structure for storing all the information relating to an open passfile:
FpmDB. (defined in fpm_passfile.h). Use of this struct would allow us to have
more than one file open at once (and encapsulate data better).

Some code in fpm_ui.c. Originally, fpm_ui.h was to be public prototypes for
generic ui code, but now that I've put tty prompting code in, we need logic code
for how to prompt the user (tty or gui). I figured fpm_ui.c was the most
appropriate place.

Wasn't sure about fpm_strcpyover returning char *, so I made it return void (it
actually didn't return anything before).

John

On Fri, Nov 03, 2000 at 11:38:15AM +0000, J. Steele wrote:
> After looking through the GnuPG code, I realized we need to install a signal
> handler so our program can exit securely. Luckily, GnuPG's signal.c is ready to
> use after just recoding the got_fatal_signal handler.
> 
> Of course, the two things we need to do on fatal signals are wipe the fpm
> allocated memory and securely exit the gui if possible. Does every window have a
> terminate function we can hook into? Also, is there a way to know what windows
> are open?

By a terminate function, do you mean a terminate signal handler or a function you
can use to send a terminate signal?  Either way, we should be set... both of these
are well supported as I recall.

As for knowing which gui screens are open, I suppose I could keep track of this
in gui global variables and provide you with an interface to them.  There may be
a way of getting gtk+ to do this automatically, but I'm not sure.  The manual way
would be simple enough for me.

I'm not absolutely sure what you are trying to do here... are you just trying to
make sure that all the fpm_mem_free() statements get executed, or are there more
benefits I'm missing when you manually terminate the opened GUI screens?

> 
> UNFORTUNATELY, this brings us back to memory mangagement! It now seems that fpm
> needs to keep track of any memory it has allocated so that an fpm_mem_terminate
> call can visit all allocated memory and wipe it. Could you re-send that mail
> from mid-Oct. where you proposed a g_hash or g_list to keep track of allocated
> memory? Such a structure is the only way I can fathom enabling this
> fpm_mem_terminate capability. I suppose this structure might as well keep the
> allocated memory size as well. What do you think? A nice hack would wipe the
> entire writeable address space of the application on a fatal signal (you can see
> this in /proc/$PID/maps), but I'm not up for this right now (and it's not
> portable).

I've attached the old functions.  Let me know if you would like me to merge this
in with the CVS version of fpm_mem.c.

> 
> Incidentally, the potential for fatal signal exits is a good reason to always
> use fpm_malloc-ed memory for sensitive information. Any fixed length buffers
> (e.g. char *secret[20]) cannot be wiped on a fatal signal exit.

Excelent point.  I'm not really using any of these in my code because I'm allowing
everything to be variable length strings, which of course aren't supported by fixed
length buffers.  Keep in mind that what is really important, however, is that you
use anonymous memory.  If you use a struct which contains a fixed length string
but you only allocate the struct anonymously with a malloc, you should still be
fine.

John

Well, you haven't heard too much from me in the last couple days either, and it is
doubtful I'll be able to do much meaningful work on FPM until next Saturday.  I'm
going to the Chicago area all next week on business.

I'll still be checking my email regularly, so keep the emails coming!  Then when
I get back I'll be ready to get to work.

John

On Fri, Nov 03, 2000 at 11:38:06AM +0000, J. Steele wrote:
> Sorry for the delay in replying. I needed to do a fair bit of thinking about
> securing tty input before replying. I'll post coding details in a separate post
> this weekend (well, maybe...)
> 
> John
> 
> 
> On Tue, 31 Oct 2000, John Conneely wrote:
> 
> > There always seems to be a tradeoff between security and usability.
> > What I'd like to do with FPM is to allow the user to intelligently
> > make decisions themselves whenever possible.  So, I'd like to:
> > 
> > 1) Allow multiple ways to enter the pass phrase.  I think in light
> >    of this stuff we have to give the user the option to enter the
> >    pass phrase from the command line.  The security issues involved
> >    with the command line seem to be simpler and better understood,
> >    so I expect the security conscious will choose this method.
> 
> I suppose I listed a lot of options and never really said what I liked. I think
> if we have a gtk_secure_entry based passphrase prompter along with a shell entry
> option. e.g. fpm fires up the gui, but if you set your preferences to use
> shell-entry passphrases, fpm writes to the shell it was launched from (with
> appropriate error detection for non-shell launches such as backgrounded tasks or
> window manager exec calls).
> 
> Most importantly for now, the passphrase gui layout needs to be made such that
> we can implement these options in the future, so it has to be able to see user
> preferences and to pass user input and system errors from the appropriate
> functions. 
> 
> For the next release goal, I'd be fine with a gtk_secure_entry
> interface---I really only want this on my home machine where I'm mostly
> concerned that the encryption is done correctly---of course others may
> complain here! (That said, I'm fast on the way to making tty input easily
> workable.)
> 
> The real value of the tty input is only realized if the entire program is in
> tty. I do see some solace in taking the precaution to guard the passphrase a bit
> better---The GUI will not reveal passwords by default, so any GUI insecurity can
> be contained while a passphrase leak is fatal! 
> 
> > 
> > 2) Communicate the risks involved in the GUI to the user.  I'd like
> >    to have a page on the web site that describes these issues, the
> >    balance FPM has chosen between security and usability, and
> >    highlight any choices the user has, such as input of the pass phrase.
> >    Should we also create popups dialogs that describe these issues
> >    which could have a checkbox for "Don't warn me about this again?"
> 
> Sounds good. Something about watching out you're on a multi-user system
> where you do not trust the other users. Of course, we'd need to stress
> that all contemplated precautions have been taken, but that the GUI
> libraries are not security audited, so a copy of the passphrase may be
> retained in memory which other users could read.
> 
> > 
> > Below I'll respond to your proposals...
> > 
> > 
> > > 1. Redefine g_free as planned to wipe all g_malloced memory on glibc
> > > systems.
> > > 
> > > 2. Redefine free() similar to g_free. Need to call the real free via
> > > __libc_free().
> > 
> > Yep, these sound like good ideas.
> 
> I'll add these to fpm_mem then. This type of hook will also fix realloc calls
> (since free or g_free is called if the new memory is allocated).
> 
> 
> > 
> > > 
> > > 2. Consider using Secret Agent's gtk_secure_entry widgets which seem
> ...
> > 
> > I'm interested in this.  Let me know if you hear back from the author.
> 
> I hope he replies!
> 
> 
> 
> > > 6. Consider using straight libX calls (basically just take the code from
> > > x11-ssh-askpass in openssh. I don't know if the X widgets will be any
> > > better and
> > > I'm not volunteering to try to audit that code!
> > 
> > I'd consider doing this if I could hear a good case for why the direct
> > X widgets would give a significantly higher degree of security.  But
> 
> Oh, I certainly meant to do this only for the passphrase capture. I agree that
> its a wash on security, and I dislike libX anyway!
> 
> 
> 
> > > 
> > > 7. Consider using Secret Agent to provide the passphrase to fpm.
> > 
> > I'm going to need to take a look at secret agent.  
> 
> I personally would never use Secret Agent to pass my passphrase to
> fpm---just too many things to go wrong. Secret Agent looks to be a great program
> for automatic entry of frequently used passwords (such as when using GnuPG). I
> was just mentioning it as an alternative.
> 
> This makes me think that the launcher side of fpm could eventually be
> extended to feed Secret Agent passphrases which could then be used inside Secret
> Agent aware programs. Secret Agent would probably need a bit of modification
> (e.g. accepting input from stdin) to accept non-interactive input  from fpm, but
> it is feasible... (esp if the Secret Agent author is interested).
> 
> 
> 
> > > 
> > > 8. Consider using grabbing the passphrase from the command line.
> > > OpenSSH, GnuPG,
> > 
> > Yes.  The gnome version of FPM needs to have an option to get the
> > pass phrase from the command line.  I'd say we should define the
> > command line get in the core of FPM, and allow the user interface
> > to optionally override it.
> 
> Okay, this is where I had to do a lot of thinking. It turns out, the tty input
> call can be as simple as 
> 	pass = fpm_tty_get_pass(char *prompt);
> Unfortunately, we'd like to be able to "fall back" onto the gui if there's no
> tty. (What irony---most of the tty code I looked at is falling back to tty if
> there's no DISPLAY!) So I think something like 
> the following is cleanest:
> 
> We'll probably need global variables for items like ui preferences. I would like
> to avoid globals as much as possible, but ui's always end up needing settings
> and such global.
> 
> fpm_ui.h:
> 	char *pass 
> 	fpm_get_passphrase(const char *prompt);
> 
> fpm_ui.c: 
> I think we need a c file to provide a place to put "tty exist" logic to call tty
> or gui routines. If someone wanted a tty only fpm, they could strip this file
> down to just call the tty routines instead.
> 
> 	/* TTY-aware get_passphrase routine. Looks at 			         *
> glb_no_tty_prompting to determine what ui to call.
> 	 *  Contains logic to "fall back" to GUI if no tty exists.
> 	 */
> 	char *pass 
> 	fpm_get_passphrase(const char *prompt)
> 
> 	
> fpm_tty.c:
> 
> 	char *pass
> 	fpm_tty_get_passphrase(const char *prompt)	
> 
> 	Plus lots of functions built upon GnuPG's ttyio.c.
> 
> fpm_gui.c:
> 
> 	char *pass
> 	fpm_gui_get_passphrase(const char *prompt)	
> 
> 
> > 
> > > 
> > > 9. Considering all these considerations, how about a flexible
> > > fpm_get_passphrase
> > > call which can use any of above alternatives (or ones available in the
> > > future).
> > > 
> > 
> > This sounds like something we should define in fpm_ui.h.
> 
> See above. 
> 
> > 
> > > 10. Ask someone who knows more about this stuff for advice!
> > 
> > This is a great idea.  I'm not currently reading much in the way of
> > news groups... do you know which news groups this might be relevant
> > to?  Any other ideas of who might be good to talk to?
> > 
> 
> No and Nope. Once we get some more code written, I can send it out. Luckily,
> most of this stuff is taken from existing GPL-ed programs (GnuPG and Secret
> Agent).
> _______________________________________________
> FPM-devel mailing list
> FPM-devel@...
> http://lists.sourceforge.net/mailman/listinfo/fpm-devel