Are the tcl encrypt functions secure?

[supra]

I assume:
- aes256 > blowfish
- proven and cryptography implementations (like pgp/ssl) > own handmade implementation
- using the right tool for what it`s made > using something twisted
- the current implementation provides encryption, but no kind of authentication (an active man-in-the-middle attacker could store messages and send them later)

Just from what I read, I am not an expert.

That`s why I am about to suggesting to change the implementation off the tcl functions cbc_encrypt and cbc_decrypt.
- ssl has a lot of good cipher and is very well proven and used a lot but would be kinda overkill and only good for active sessions and not offline chats
- pgp is also not very user friendly, you have to learn to create a public and a private key and to give everyone your public key but still seams to be the most secure solution for chats if someone might be offline and the messages stored on a server
- otr looks also very interesting, although it`s not old and proven like pgp it can be very user friendly (users just have to check if a hash is ok over a pre-secure channel)

Just thoughts, discussion, no offence at all. What do you think?

[f0dder]

SSL is vulnerable to man-in-middle attack, PGP (asymmetric ciphers in general) would be pretty impractical and still has the problem of (public) key distribution.

Dunno about OTR, perhaps it's worth checking out?

[supra]

SSL is vulnerable to man-in-middle attack

On the web them use some "web of trust" system, like when you do internet banking. But do I really trust those "web of trust"? Not really.

From what I know you can use self-signed certificates without web of trust. Clients would need then to check each others sha1 hash over a pre-secure channel or in a meeting (or more unsecure on phone). After the sha1 hash is checked it should be perfect secure against man in the middle, or not?

I think SSL would be still nice to implement encrypted file transfer at protocol level. Sure you can still encrypt each file yourself and then send it, but that`s not a user-friendly solution. No doubt, encryption at protocol level would be nice.

From my researchs it should be even possible to wrap SSL so much that users just need to compare hashs. (it provides encryption and authentication) (still only works for active connections, not offline) (so this could be choose for encrypted file transfer)

PGP (asymmetric ciphers in general) would be pretty impractical and still has the problem of (public) key distribution.

Yes. PGP is for mails the only good thing but for chats not really good, maybe only if you are using it for mails already. It is to overload with features like signing others keys and such. You have also to use web of trust or exchange the public keys over an pre-secure channel (... same like above).

Dunno about OTR, perhaps it's worth checking out?

Absolutely, there is an good implementation for pidgin from the otr project itself. Just check it out. The "shared secret" feature is currently more confusing then helping but no must.

Checking each others hash is - at the moment - perfectly secure. Cryptography conversations are possible, full user support and them also offer support for implementing it.

It provides 4 cryptography features (encrypt, authenticate, deny, forward...) and seams well designed for messengers. But otr is also only for online messages, not offline message support.

...

A lot of kinda unsorted stuff inside my head and this posting. Lots of ideas but no ideal solution. The only correct toolkit would be ssl for filetransfer. The rest has kinda disadventages...