 |
GSoC idea 2: Improved (more elegant) keygeneration in KMail/Kleopatra
Application/component: KDEPIM/KMail and Kleopatra
Brief explanation:
Signing and encrypting emails is very old, however only a minority is using it. One reason might be, that it is not easy enough for regular users to use it. The importance for private and business users is still high. Private companies started to sell proprietary, secure e-mail services (e.g. in Germany DE-Mail and e-brief). There are good key creation, signing and other key management functions present in KDE software. The goal of this proposal is to make it easy and fast to work with signed and encrypted emails.
Expected results:
- Analyze and optimize the key creation, signing etc processes, make it dumb easy to create and use a key/signature. One way could be to add a button “Generate Key” (next to “Change”) in the KMail – Identity settings – Cryptographie; start the key creation wizard from Kleopatra and take the name and email address from that identity (at the moment you have to enter them manually). The user just has to enter the passphrase and is done. Offer a button “Save private key and revoke key on usb” or something like this and “send public key to server” / “Make key public”. Add the key creation (or import possibilities) into the identity / account creation wizard of KMail. Add the possibility to create revoke keys within the gui (when sending the key to the server, there is an information message yet.)
- Guide the user through the whole process of signing and encrypting/decrypting emails. Offer possibilities to learn about the topic in an easy and fast way (offline help, online help / wiki, videos, tutorials etc). Show how they use the keys, how they get their keys signed, how they sign other keys etc.
- Integrate other free/open services like CAcert.
5 comments:
What about making it as easy as just asking the user "Do you want to send the emails encrypted?", maybe with the options "when possible" and "always" and if answered "yes" generating a key from the users login-settings.
I know it's crazy to use the same password for login, disk-encryption (as is automatically done by some distributions) and email-encryption, but since many users wouldn't bother the tiniest bit, this may have a huge impact on a macroscopic scale.
Another point to make it as hassle-free as possible would be to only encrypt, if it can be determined that the other side can decrypt the message, which could be done e.g. by looking up the recipient on public key-servers, looking in the "Client"-part of the mail or figuring out if the mail-provider has some means of encryption (web.de enables you to use S/MIME for example).
There were(is?) a wish on kde brainstorming forum about this.
And it was shot down as the result was that the current email/file encryption and decryption is already easy.
I argued same thing as you did that it is too difficult
It really should be easy as just first giving a new password for the encryption email address and other needed information and then encrypting files or emails should be easy as drag'n'dropping files or copy-paste them.
You nailed the point directly... The encrypting is very old technology and very rarely used. I do not know anyone else than me from my friends or family who use it on their own computers (non-corporation setups). And among them all, I know only one who has very secure encryption on his work laptop, but he works on IBM networking and they have this fancy fingerprint+PIN encryption key on their keychain what is needed to open first to get 16 letter code from it to open company own networks/emails etc.
I really would argue that KDE SC needs a application what makes encrypting/decrypting very easy, with very standard/wide used technology what is possible to use anywhere.
I think that we need very nice wizard to generate a:
PGP key for files/emails
SSH key for remote connections
XYZ key for XYZ
It really should be such that it does not use the same password what user use for own personal account. Every password really should be different, that is the corner stone of the security. At homes, it really is not so bad that the password is written to piece of paper under the keyboard, as the mostly data capture is really happening at network.
@malte: Nice ideas.
The security level (use same pwds) of the passwords surely could be discussed. Perhaps it could be integrated into kwallet or something to make it simpler if you want to.
(I am not sure if more people use email encryption or disk-encryption. Both would be big numbers.)
@Fri13: Ups. I haven't checked the brainstorm forum. But I am a little bit sad to hear the response. Hopefully more people (esp. developers) will see the possibilities we gain with a even easier encryption handling. A GSoC would be really rocking!
I think, there should exist identity-key relation. Each identity can have on key and many keys could been assembled to many identities.
Identities would be:
Default e-mail address, sign, key to crypt and digital sign e-mail.
Post a Comment