[RCD] GnuPG/PGP plugin for roundcube

Maximilien Cuony [The_Glu] maximilien at theglu.org
Thu Jul 30 19:10:41 CEST 2009


Hi,

> great. i agree with you that client side key storage is more secure in
> many cases, but sometimes it is not an option at all. 

Yep of course, that why we need both methods and users use the best they feet 
for them. (And btw, using client side will have to be securised too 
(https+auth of the roundcube installation, something like this)) With an 
abstract layer ;)

> yes, you're correct. that's the list of basic functions needed. if we
> support key management (it's needed for server-side keyring storage at
> least) we also would need edit(privatekey, ...), delete(key) and
> delete(privatekey).

And generate() too, very important. Problem is that generate a key could be 
long => php's timeouts ? (Not a question but a potiental problem :P)

About storing keyrings, I think files should be in the database, and only in 
the database, but of course that not possible for gnupg to works with that (or 
somebody has an idea ?). And write them on the disk just for gnupg operation 
won't change the problem, a deamon can watch files and read them just when gpg 
is executed.

Btw, is a check of the database corruption usefull ? If someone has access to 
the files, first thing I will do is to steal private keys :P

Regards,

On Thursday 30 July 2009, Jonas Meurer <jonas at freesources.org> wrote :
> hey,
>
> On 30/07/2009 Maximilien Cuony [The_Glu] wrote:
> > > but i'm not sure yet whether an abstract encryption plugin with drivers
> > > for different encryption mechanisms (gpg, s/mime, ...) would be useful.
> > > i simply don't know s/mime enough, but i fear that key management etc
> > > differs to much from gnupg to create an abstract layer for both.
> >
> > I want to implement gpg's features on the users side {With FireGPG}. (I
> > personaly think it's better (storage of the private key, etc.)).
>
> great. i agree with you that client side key storage is more secure in
> many cases, but sometimes it is not an option at all. for example if
> people don't want to connect storage devices to public computers for
> security reasons. it may be more secure to trust the remote webserver
> than to trust the public computer. any you can use encrypted connection
> (https) and virtual mouse keyboards for passphrases to prevent man-in-
> the-middle attacks as well as keyloggers.
>
> > So an abstract layer whould be good as I could query the user with
> > javascript and a specific protocol. That mean we should think about a
> > abstract layer who can as the user (and not a server-only layer) :p
> >
> > About the strucutre of this layer, we simply need (at last) 4 {6}
> > functions: encrypt(text, keys), decrypt(text), sign (text, privatekey),
> > verify(text). And optionnaly, {signandencrypt(text, keys, privatekey),
> > import(text), export(key)}. For key management, if need (should we or not
> > ?) listkey and listprivatekey too.
> >
> > For the layer who manage mails, you will probably need need to:
> >
> > - Decrypt an inline encrypted mail
> > - Decrypt an openpgp/mime encrypted mail
> >
> > - Verify an inline signed mail <- this part is painfull. Realy. Every
> > mail client has is own logics...
> > - Verify an openphp/mime signed mail
> >
> > - Encrypt or sign a mail in openpgp/mime standards
> >
> > - Modify data of the mail to encrypt or sign it with inline.
>
> yes, you're correct. that's the list of basic functions needed. if we
> support key management (it's needed for server-side keyring storage at
> least) we also would need edit(privatekey, ...), delete(key) and
> delete(privatekey).
>
> and i'd like to have options to set default signing key as well as
> encryption/signing defaults for new mails and replies to encrypted/
> signed messages.
>
> but the real problem for me right now is rather how to manage the
> different roundcube users. we'd have to manage secring.gpg and
> pubring.gpg for every roundcube user seperately.
>
> greetings,
>  jonas
>
>
>
>  --- 8< --- detachments --- 8< ---
>  The following attachments have been detached and are available for
> viewing. http://detached.gigo.com/rc/Gy/qEXhG0Is/signature.asc
>  Only click these links if you trust the sender, as well as this message.
>  --- 8< --- detachments --- 8< ---
-- 
Maximilien Cuony [The_Glu]
http://theglu.org



 --- 8< --- detachments --- 8< ---
 The following attachments have been detached and are available for viewing.
  http://detached.gigo.com/rc/PN/AXja9xc7/signature.asc
 Only click these links if you trust the sender, as well as this message.
 --- 8< --- detachments --- 8< ---

-------------- next part --------------
_______________________________________________
List info: http://lists.roundcube.net/dev/


More information about the Dev mailing list