see Bug 58632  and Bug 58849
Anyway, since theses two plugin are supposed to be totaly independent, it's difficult to act.

Yes, I noticed. However I can bet such issues will arise in the future as well, so maybe there shall be "Plugins cannot use each other features" issue shall be filled as general case?

Kopete 0.8.1's History still stores messages crypted, which is extremely useless.

I see two structural solutions to this issue:

1) Save a number of message flag in the history, kind of like mime-types, and let each plugin register it's own type so every plugin can check how to handle certain types it can't handle itself

2) Use a generalized displaying engine, so that history displays get parsed by the same thing that parses the live incoming messages, and handles them the same way.

Will be fixed post-3.3 by the message filter API.

*** Bug 88394 has been marked as a duplicate of this bug. ***

*** Bug 68947 has been marked as a duplicate of this bug. ***

And also:
* Latex and cryptography  (the old Bug 88394 )
* Autoreplace text and cryptography (the old Bug 77482)
* Translator and Cryptography
* ....

I vote for this bug as all my conversations on Jabber are encrypted as they are professional chats. I find this VERY annoying not to be able to read easily encrypted history.

Kopete is really a great application !

Go on with your good job !

* For security reasons, I think the history should be kept encrypted.
* We can keep the actual view of viewing encrypted messages, 
* But we should have a "Decrypt History" button that ask for passphrase and decrypt all the history.

Richard Smith:
> Will be fixed post-3.3 by the message filter API.

So, will it be fixed in KDE 3.4? Just out of curiosity.

*** Bug 97824 has been marked as a duplicate of this bug. ***

> So, will it be fixed in KDE 3.4? Just out of curiosity

Maybe.
The new fileter message API already exist, but is sitll not used.

I very much agree with #9 that "For security reasons, I think the history should be kept encrypted". 

Messages cannot continue to be stored as they are now, however, since they use a  private/public-key system. This makes it impossible to decrypt outgoing messages.

I don't know the inner workings of Kopete, but I would suggest that messages are first decrypted, and only then stored in its decrypted form in the history. There could then be an option for encrypting the history. This makes the two plugins totally independent. I think that encrypting the history but not the communication could be desirable (even default!).

And another idea: Encryption of history could probably be nicely done in CTR mode (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29), to allow encrypting the whole history (including to,from,message length, etc.), and still have random access to the history. This is of course only one of many ways to do it, but I urge the one implementing this to at least use a symmetric cipher and not public/private key. The latter solution will really slow down searching the history.

"This makes it impossible to decrypt outgoing messages." -> this is true, however it can be simply worked around by encoding outgoing messages with sender's public key too.

> "This makes it impossible to decrypt outgoing messages." -> this is true,
> however it can be simply worked around by encoding outgoing messages with
> sender's public key too.
True. But again, IMO a symmetric cipher is far better for history purposes. Decrypting and searching through, say, 1000 messages encrypted with PGP is just a too heavy operation. Who wants to wait more than a second these days? Not me :)

I just upgraded from my ancient Celeron 600 so I don't care that much, but aside j the joke - I'd like to have a support for this sonner than later. I can stand waiting longer since I don't search the history that often (not to mention kopete history browser simply sucks). So whatever it will be done I won't be complaining for now. Frankly speaking I am not using encrypted messages that often recently so I doubt I got 1000 messages ;)

Marcin:
Seriously? What your saying sounds to me like: "Ok, so that hack may be a bad solution, but let's just get it done, and someone may fix it one day?" Because you know, it's so much harder to fix a broken thing, than making it good the first time. Should we solve this the Linux way or the M$ way? (ok, I admit that point is a bit prejudiced)

But this is not only about speed. Look at the points I made in #13 about how this could separate the crypto and the history plugin. And how this gives the opportunity to encrypt the history even though the original communication was unencrypted.

That said, I'm not the one to implement it (in fact, maybe I should - but I'm too afraid of that big ol' source), so I cannot push my solutions onto everyone.

No, I'm just saying I don't need high-speed-optimised-and-efficient solution from the scrath. I assume that encrypted messages was a thing nobody foreseen designing history management in kopete, hence current problems. We need something to handle that, no doubts, but whatever you do it will be kind of revolution since some backward compatibility will probably be broken and some older messages (outgoing mostly) may stay encrypted. Crypting whole history ain't good solution either as disallows you to append new mesaages to it w/o prior decrypt, which consumes CPU. So whatever will be done it rather have to be done right way otherwise ppl will keep complaining.

> whatever you do it will be kind of revolution since some backward 
> compatibility will probably be broken and some older messages (outgoing 
> mostly) may stay encrypted
True. Too late to do anything about that :(

> [en]crypting whole history ain't good solution either as disallows you to 
> append new mesaages to it w/o prior decrypt
False. If you use a block cipher in e.g. CTR-mode, appending will not require any decryption, only encryption of the added text.

>  So whatever will be done it rather have to be done right way otherwise ppl
> will keep complaining.
Agreed. But I don't think my solution takes more time to implement than yours.

ps! Is this the right place for this discussion? Or are people annoyed because of all the mails? I'll try to reduce my comments...

On Thursday 27 January 2005 11:54, Joffen wrote:
> And how this gives the opportunity to encrypt the history even though the
> original communication was unencrypted. 
In my opinion this is a bad idea. With this logic any program would have to 
include functionality to encrypt all its data because it's potentially 
private.
I don't think kopete should implement an own encryption backend. The messages 
in the history should be saved exactly as they were sent (i.e. gpg 
encrypted), or optionally in decrypted form.

If you want to protect all your sensitive data it simply doesn't make sense to 
enrypt it individually in all the programs you use. What does make sense on 
the other hand is to have an encrypted partition. It's really not that 
difficult to set up. My encrypted home partition is mounted automatically at 
login (by pam_mount).

from #20
> With this logic any program would have to include functionality to encrypt all 
> its data because it's potentially private. [...] What does make sense on
> the other hand is to have an encrypted partition.
Ok, I agree. Good point!

> The messages in the history should be saved exactly as they were sent (i.e. 
> gpg encrypted)
In a way I think this contradicts your previous point: You just suggested that encryption of stored data is not a job for each application, but an optional thing for the filesystem or similar. So let's just store it unencrypted. You'll probably oppose me here, with the argument that it's already encrypted, but still: Encryption has to be done in a _different_ fashion than now (for outgoing messages) if it is to be readable for the sender. And that fashion requires even more computations.

Some other points about storing gpg messages as sent:

1. How does this allow for new ways of encrypting data?
Poorly. A new/different crypto plugin would also need to be implemented for the history plugin (unless the history plugin uses the crypto plugin). Also, all methods of encryption has do be done in such a fashion that both sender and receiver are able to decrypt it.
   Even worse, decryption has to be done on a /per message/ basis. What if I want to make an encryption plugin that initiates a TLS communication between the two parties (via the IM-channel). The history+encryption-plugin would have to browse through messages to find the start of the TLS-stream, etc.

2. [repeated] Can I search the history? Yes, but this is slow. Maybe not everyone has 1000+ messages in history, but should we forget about those? If another solution exist, I say clearly we shouldn't!

3. [repeated] Modularity. Ah, now that's a fine concept! Just let the history plugin be unaware of crypto plugins and how your home partition is encrypted. Let history be history: "What was really said?", not "HOW was this said?".

4. What do you want to protect? In many cases what you want to protect is not WHAT you said. It's to whom you said it and when, how often this communication is taking place, how much information is transmitted. Storing the gpged messages doesn't help against these attacks. The headers are still unencrypted. I say this gives a false sense of security.


Excuse me while I go encrypt my home folder...

> > The messages in the history should be saved exactly as they were sent
> > (i.e. gpg encrypted)
>
> In a way I think this contradicts your previous point: You just suggested
> that encryption of stored data is not a job for each application, but an
> optional thing for the filesystem or similar.
My interpretation of a history is in fact that of an archive: What is being 
sent over the communication channel is stored without change. That's also the 
way kmail handles encrypted e-mails. If I want to look something up, I know I 
have an exact copy of the message that left my computer.

> So let's just store it 
> unencrypted. You'll probably oppose me here, with the argument that it's
> already encrypted
In fact I would be in favour of having two options:
* store messages unencrypted and leave it to the user to encrypt them if
  necessary (encrypted partition etc.)
or
* store them as is.

The first would have the advantage of faster search than decrypting gpg 
messages on the fly.
The second would be best for archival purposes. (Of course, this would require 
some searching functionality in gpg messages.)

> 1. How does this allow for new ways of encrypting data?
> Poorly. A new/different crypto plugin would also need to be implemented for
> the history plugin (unless the history plugin uses the crypto plugin).
> Also, all methods of encryption has do be done in such a fashion that both
> sender and receiver are able to decrypt it. Even worse, decryption has to
> be done on a /per message/ basis. What if I want to make an encryption
> plugin that initiates a TLS communication between the two parties (via the
> IM-channel). The history+encryption-plugin would have to browse through
> messages to find the start of the TLS-stream, etc.
I'm not sure I understand what you mean. I don't think the IM protocols allow 
direct TLS communication between clients. IMO there's nothing wrong with gpg 
since it's independent of the IM protocol. Furthermore, I agree that it would 
be stupid to store the TLS stream since that's the channel not the actual 
message data.

> 2. [repeated] Can I search the history? Yes, but this is slow. Maybe not
> everyone has 1000+ messages in history, but should we forget about those?
> If another solution exist, I say clearly we shouldn't!
My proposal addresses this nicely: add on-the-fly decryption for gpg messages. 
If that's too slow, store them unencrypted (and encrypt your partition).
That way, each user can handle encrypted messages as he wishes.

> 4. What do you want to protect? In many cases what you want to protect is
> not WHAT you said. It's to whom you said it and when, how often this
> communication is taking place, how much information is transmitted. Storing
> the gpged messages doesn't help against these attacks. The headers are
> still unencrypted.
That's true, but _complete_ encryption is done most elegantly by encrypting 
your partition (or only certain directories: fuse and encfs are very 
interesting projects). Otherwise kopete would have to implement similar 
functionality, but in a completely non-standard way.

> I say this gives a false sense of security.
If even this metadata is sensitive information, there's no way around 
encrypted partitions and encrypted swap. And if security is such a concern, I 
guess the user is aware of these issues.

Schintgen: I can't seem to understand why you want to log what the encrypted data looked like at the time. You write:
> I don't think kopete should implement an own encryption backend. The messages
> in the history should be saved exactly as they were sent (i.e. gpg
> encrypted), or optionally in decrypted form.
I tend to interpret the term "exactly as it was sent" in a different way, namely what was written. What was written and what was read is the real content I want to log. Cryptography should be transparent.


> Furthermore, I agree that it would be stupid to store the TLS stream since
> that's the channel not the actual message data.

In other words:
1) The actual message data is the real content, the semantics
2) TLS encryption is not a part of this, it is not semantics
3) I only want to log the actual message data

Generalised:
1) The conversation is semantics
2) The encryption is not
3) I only want to log the semantics

Why, then, do you want to log GPG encryption?

You compare kopete's history log to a sent e-mail folder. This is not fair, because the one is connection oriented and the other is not. Besides, mails are often stored on remote computers.


Also, Joffen's point, if the history plugin starts to treat GPG messages specially, the two plugins are intwined. If cryptography is a transparent layer the history plugin may do whatever it will with encryption, and need not be suited to the crypto plugin. Furthermore, the crypto plugin is free to act on its own. This is better if, some time in the future, some IM protocol specifies how encryption should be implemented.

This is clearly a better way to separate the two plugins. Encryption in the one does not imply anything about encryption in the other.

*** Bug 95363 has been marked as a duplicate of this bug. ***

> Generalised:
> 1) The conversation is semantics
> 2) The encryption is not
> 3) I only want to log the semantics
>
> Why, then, do you want to log GPG encryption?
I've done some thinking about this whole issue, and guess what, the more I 
think about it, the more I see that the fundamental reason I wanted to keep 
the messages encrypted as is, is simply to have an additional layer of 
encryption. Even though I'm using an encrypted home directory this additional 
layer makes sense because the data is only decrypted on access. (Unlike the 
partition)

Of course, this argument is exactly the one behind Joffen's wish... So, you're 
both right on this one.

> This is clearly a better way to separate the two plugins. Encryption in the
> one does not imply anything about encryption in the other.

I agree, yet I have some real concerns: as I've already stated I don't think 
each application should implement its own encryption backend for local 
storage. One reason I was arguing in favour of keeping gpg messages is that 
it's a _standard_ tool: I can always get access to the encrypted messages 
_without_ using kopete.
A further advantage of gpg is portability.

An KDE-wide encryption framework could be quite nice, but that's wishful 
thinking.

In the meantime I would be more than happy to have at least the option to 
store messages unencrypted. I could always resort to encfs to encrypt kopete's 
history directory. The current situation (unable to access the history) is 
somewhat frustrating.

Gilles

IMHO the needed functionality is encryption of the message while _sending_ it, while encryption of the messages on your harddisk is a task which is probably better done by a specialized application (e.g. encrypted partition). So the cryptography plugin just needs to encrypt the message sent, while the history can be unencrypted.

At least please make encryption of the history optional, since (at least with each single message being gpg-signed) it would increase by a factor of at least 5 in size.

CVS commit by ogoffart: 

When using the crypto plugin, store the message uncrypted in the history.

BUG: 77482

Having it encrypted is fully useless. You can't even read again message you sent because they are generally not encrypted with your own key (doing it may result in too big messages for some protocols)

If you want to keep the history secure:  1) don't log at all.  2) use an encrypted partition. so that it it secure.


  M +1 -0      historylogger.cpp   1.29
  M +2 -2      historyplugin.h   1.12


--- kdenetwork/kopete/plugins/history/historylogger.cpp  #1.28:1.29
@@ -499,4 +499,5 @@ QValueList<Kopete::Message> HistoryLogge
                                                         Kopete::Message::RichText
                                                 );
+                                                msg.setFg( fgColor );
                                         }
                                         else

--- kdenetwork/kopete/plugins/history/historyplugin.h  #1.11:1.12
@@ -2,5 +2,5 @@
     historyplugin.h
 
-    Copyright (c) 2003 by Olivier Goffart             <ogoffart@tiscalinet.be>
+    Copyright (c) 2003-2005 by Olivier Goffart       <ogoffart at kde.org>
               (c) 2003 by Stefan Gehn                 <metz AT gehn.net>
     Kopete    (c) 2003-2004 by the Kopete developers  <kopete-devel@kde.org>
@@ -65,5 +65,5 @@ public:
         int filterPosition( Kopete::ChatSession *, Kopete::Message::MessageDirection )
         {
-                return InStageStart;
+                return Kopete::MessageHandlerFactory::InStageToSent+5;
         }
 };

Thanks.

And all it took was two lines of code! Amazing :)