KDE Cryptography Module
thiago at kde.org
Wed May 23 18:22:31 BST 2007
Alon Bar-Lev wrote:
>1. We have some kind of low level cryptography library, let's call
>this CRYTPO for now, so we don't argue whether it is QCA or anything
QCA isn't a low-level cryptography library. It's an abstraction layer upon
Aside from that semantic distinction, we can take your CRYPTO proposal
>2. We have TLS/SSL socket implementation that uses CRYTPO in order to
>do private key operations, we will call this CRYPTO_TLS
Ok. This is what interests me. I have no idea how the rest works (I'm the
socket guy, not the cryptography guy). This is also why QSslSocket is
good enough for my purposes.
>We need to implement the following into KDE:
>1. Modify the KControl crypto section, to allow managing the CRYPTO
>attributes, including managing hardware devices.
Ok, this is important. We have some dialogs already for manipulating some
settings and the certificate store, but we need to switch the backend. As
for manipulating/configuring external devices, we have nothing yet. This
would have to be written.
>2. Introduce KDE dialogs for "token prompt" and "passphrase prompt" to
>be used as callbacks of CRYPTO, when token is needed or when
>passphrase is needed (software and hardware).
You're talking about obtaining a passphrase to unlock a private key,
>3. Modify the TLS/SSL provider in KDE to use the CRYPTO_TLS and the
>callbacks from (2), this will enable any TLS/SSL application to
>benefit from CRYPTO features, without any modification.
The current TLS/SSL provider is KSSL but its socket implementation simply
must go. It's incompatible with QtNetwork. So, for all purposes, there is
no TLS/SSL provider in KDE.
Now, this is where QSslSocket and QCA overlap: both provide sockets.
>4. Modify KWallet implementation so that it use CRYPTO in order to
>encrypt/decrypt sensitive data. This will enable all application that
>store sensitive data to automatically be smartcard enabled.
No comment on that. George knows what it is about.
>5. Write kdm greeter that uses CRYPTO and handle smartcard logon, this
>is optional dynamic loaded component.
Again, no idea.
>6. Scan all KDE code base and migrate any OpenSSL/GnuTLS/whatever
>crypto code into CRYPTO.
Thankfully, we have close to none of other libraries. The only program I
know of to be using cryptography of an external library is Kopete, but
it's QCA that it is using.
The rest of the programs must be using KSSL. That means the interface they
are using will go away and they'll have to be ported. This is important,
>7. Approach kmail to use CRYPTO_SMIME, so that gnupg**5 processes will
>not be required for S/MIME configuration.
No idea about this one.
>What do you think?
Now we're getting somewhere. I call this productive now.
First things first: we're almost two months past the deadline for major
frameworks in KDE 4.0. So the CRYPTO framework we're discussing now is a
KDE 4.1 thing.
However, this has impacts on KDE 4.0: more specifically, on KSSL. As
George said, he wants most of KSSL to be hidden and made private. Only
the bare minimum should remain. I don't know how this public API would
look like yet.
The way I see it, KDE 4.0 can't do without the secure sockets. All of the
rest can reasonably wait for KDE 4.1 and a proper CRYPTO. As I said
before (probably before we switched the thread to k-c-d), applications
should not change certificates, policies or settings on the sockets.
That's user configuration and/or KDE-wide policy.
We have a choice before us: either we use one of the existing socket
classes or we don't. The latter choice means we'd write our own secure
socket wrapper, descending from QTcpSocket.
Frankly, I'd rather avoid adding that class to KDE code, first because it
would be something more to maintain until KDE 5.0. Second, because we
already have two classes to choose from.
Whichever form we choose, we have to make the choice before KDE 4.0 is
out, since the class we choose will be used by applications and we'll
have to keep on supporting it (even if as a compatibility mode) until KDE
Right now, in code, the choice is QSslSocket. And Mailody is already using
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel