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@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< ---