powered by Jive Software

New Jabber client client using 128bit TripleDES

Hey all,

I’‘m almost finished building a Jabber Windows client at work, using Jive as our server (Jive just rocks, I mean seriously), and I’‘ve got 128bit TripleDES encryption to encrypt all messages (message body that is) before they are sent out, then decrypted when they arrive at their destination. It uses password derived 128bit keys for encryption/decryption. I know, why not use SSL? I don’‘t know, I thought it’‘d be cool to have my own built-in encryption. I plan on releasing this client for free once I’‘m done (licensed under the GPL). What do you guys think of 128bit TripleDES over SSL? If a server is spoofed, they won’'t be able to decrypt the messages without the password derived key anway . . .

P.S. It has a setup wizard that says “Please enter the URL of your Jive server or other XMPP compliant server (such as Jabber)” - free plug =^)

What do you guys think of 128bit TripleDES

over SSL? If a server is spoofed, they won’'t be

able to decrypt the messages without the password

derived key anway . . .

Sounds cool. Have you looked at any of the e2e (end 2 end) encryption JEP’‘s that have been proposed at jabber.org. There’'s one that uses standard XML encryption, another that uses PGP, etc.

P.S. It has a setup wizard that says "Please enter

the URL of your Jive server or other XMPP compliant

server (such as Jabber)" - free plug =^)

Nice. However, could you make it "… of your Jive Messenger server… " instead of just “Jive”? We have a bunch of “Jive” projects and products so try to use the full name to prevent confusion.

Regards,

Matt

Nice. However, could you make it "… of your Jive

Messenger server… " instead of just “Jive”? We have

a bunch of “Jive” projects and products so try to use

the full name to prevent confusion.

Not a problem Matt!

Sounds cool. Have you looked at any of the e2e (end 2

end) encryption JEP’'s that have been proposed at

jabber.org. There’'s one that uses standard XML

encryption, another that uses PGP, etc.

I have not looked at either of these, but will as soon as I’'m done posting this! Thanks for the input!!

I definitely see this filling a niche. In cases where you can’‘t do transport-layer crypto, this message crypto could be combined with an authentication mechanism that is still strong to have fairly decent end-to-end confidentiality. It could help get through fascist corporate perimeters that won’'t let IM traffic through unless the content can be inspected at the application level.

And having said that, allow me to suggest extension of this project to utilize a better cipher (perhaps Blowfish, Twofish or AES). 3DES is kind of “20 years ago.” Unless you’'re using some native Windows libraries that can only do 3DES (Like the same code that enables EFS? Not sure about the internals.)

And of course, the other half of the niche is that PGP just isn’'t a user-friendly paradigm. Especially for this type of application, the requirements are overbearing. I mean, I have a lot of keys on my keyring, but if I had to keep a key for everybody I talk with on IM, that would pretty much suck.

And having said that, allow me to suggest extension

of this project to utilize a better cipher (perhaps

Blowfish, Twofish or AES).

I’'m building a library right now implementing AES, so I can use that in my app as well. Blowfish is a good idea also . . .

3DES is kind of "20 years

ago." Unless you’'re using some native Windows

libraries that can only do 3DES (Like the same code

that enables EFS? Not sure about the internals.)

As far as my implementation of 3DES - I’‘m using the System.Security.Cryptography namespace built into the .NET Framework, which essentially interacts with the underlying unmanaged API directly (I can’'t stinkin find the MSDN article where this is discussed right now). Even though 3DES is aged, I think its still an excellent choice for lightweight encryption without too much complexity.

I definitely see this filling a niche. In cases

where you can’'t do transport-layer crypto, this

message crypto could be combined with an

authentication mechanism that is still strong to have

fairly decent end-to-end confidentiality. It could

help get through fascist corporate perimeters that

won’'t let IM traffic through unless the content can

be inspected at the application level.

I agree - E2E encryption is an excellent choice, especially for operating over public servers. I’‘ve used E2E encryption implementations many times, even in web services I’'ve built.

Hi

Just some thoughts.

The problem with using TripleDES (symmetrical algorithm) is that both parties have to share the same private keys. How you you exchange these keys securely? In the banking industry, there are a lot of processes to achieve this, eg using a 3-9 separate parts transported by different trusted persons, and receiving party combines the parts to make up the key. This is a simplistic view, but they have $250,000+ black boxes that are dedicated to build and exchange private keys.

For your case, you can of course use public key cryptography (ie RSA) to securely exchange keys. Or alternatively, just to SSL certificates. SSL uses both public key cryptography for key exchange and symmertical cryptography for data encryption.

http://it-solutions.gsa.gov/itss/v41_HELPDOCS.NSF/0/a4f6bdb7e2735f6c8825691b0077 2153?OpenDocument&Highlight=2,ssl

Hope this helps.

Regards

Keith