Encrypted message exchange
Locked
 
|
Hi We have a client app and would like to have bidirectional encrypted message exchange with a server. As I understand from reading the Security doc the recommended way is to use a symmetric key cipher to encrypt the message and then encrypt the key using an asymmetric key cipher and send them as one message. The security doc refers to this as a digital envelope. Typically, the symmetric key is encrypted using the public key and decrypted with the private key. However, this does not address sending a message in the other direction. I would like to also encrypt with the private key and decrypt with the public key. My client would have only a public key. Does anyone know if there are any problems with this approach? Thanks. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Best is to use standard protocols, security is hard to do right and if it's not done right it's mostly pointless. It sounds like you want end-to-end encryption not point-to-point. You can use SSL/TLS for the latter but there isn't anything available out of the box for the former. There is a PGP implementation floating around, but if that isn't workable, I'd at least try to emulate what PGP does (http://www.pgpi.org/doc/pgpintro/).
If you're using public keys for encryption, the recipient has to use the corresponding private key to decrypt, so you'll need two key pairs, one for each direction. Note however that the primary purpose of public key schemes is to simplify key management in complex relationship networks (i.e. many senders/ many recipients). If you're dealing with a straightforward setup with few nodes only, it may not buy you much. Simply set up all nodes with a secret (symmetric) key and the message doesn't include the key, just the ciphertext. Only someone who has the secret key should be able to decrypt it. I'd recommend also hashing the plaintext and attaching the hash to it before encryption so that you can verify integrity on the other end. And of course you should prepend some randomized input to each message so that encrypting the same message doesn't yield the same ciphertext every time, and of course use the bulk cipher properly (encryption mode, IV, etc). Maybe consider using PKCS! 5, although out-of-the-box it provides only fairly weak ciphers (adding new ones isn't hard, just a matter of finding the standards defining them, e.g. PKCS#11,12 ...). Again you could just emulate it. No matter which solution you go with, you still have to think about how you'll manage the keys securely. How is a key generated and distributed to the nodes involved? How often is it refreshed? Is it handled securely by the nodes? How will you handle key compromise? ... The level of paranoia required depends on the security requirements of your application, but should be generally fairly high, otherwise there's not much point playing the security game. HTH, Martin "Terry Raymond"<[hidden email]> wrote: > We have a client app and would like to have bidirectional encrypted message > exchange with a server. > > As I understand from reading the Security doc the recommended way is to use > a symmetric key cipher to > > encrypt the message and then encrypt the key using an asymmetric key cipher > and send them as one message. > > The security doc refers to this as a digital envelope. Typically, the > symmetric key is encrypted using the public key > > and decrypted with the private key. > > > > However, this does not address sending a message in the other direction. I > would like to also encrypt with the > > private key and decrypt with the public key. My client would have only a > public key. > > > > Does anyone know if there are any problems with this approach? > > > > Thanks. > > > > Terry > > > > =========================================================== > > Terry Raymond > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > =========================================================== > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Encrypted message exchange
|
|
In reply to this post by Terry Raymond
Terry,
There are many ways to do it. And I personally tried few of them. The easiest by far would be to use some light weight messaging like the XML RPC over the HTTPS. The client has everything to use HTTPS, the server probably should be behind the web server like Apache to handle incoming and outgoing HTTPS communication. I know there are ways to eliminate the Apache from that picture, but I newer tried it myself. The beauty of this is - you are using most of the standard protocols so you do not need to implement your own Public/private key encryption. One thing you can do also, is to install only your server SSL certificate into your client and this way you will make sure that your client can talk only to your server and nobody else. --Mark Terry Raymond wrote: > > Hi > > We have a client app and would like to have bidirectional encrypted > message exchange with a server. > > As I understand from reading the Security doc the recommended way is > to use a symmetric key cipher to > > encrypt the message and then encrypt the key using an asymmetric key > cipher and send them as one message. > > The security doc refers to this as a digital envelope. Typically, the > symmetric key is encrypted using the public key > > and decrypted with the private key. > > However, this does not address sending a message in the other > direction. I would like to also encrypt with the > > private key and decrypt with the public key. My client would have only > a public key. > > Does anyone know if there are any problems with this approach? > > Thanks. > > Terry > > =========================================================== > > Terry Raymond > > Crafted Smalltalk > > 80 Lazywood Ln. > > Tiverton, RI 02878 > > (401) 624-4517 [hidden email] > > =========================================================== > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi Terry,
I'd also go Mark way, using SSL therefore for encrypted channel. SSL has also a n optional client authentication with a digital certificate, besides mandatory server cert. For messaging over SSL I'd go with new WebSocket protocol, to which a plain HTTPS is upgraded at the request. Added benefit is that it goes through firewals as plain HTTPS go. WebSocket is namely bidirectional full duplex messaging, contrary to HTTP, which is unidirectional, half-duplex. In Smalltalk Swazoo has already a WebSocket support and there are WebSocket clients like WebClient in Squeak and I think Zync will have it too. Swazoo have plans to add back SSL support as well. Best regards Janko Dne 05. 04. 2012 17:01, piše Mark Pirogovsky: > Terry, > > There are many ways to do it. And I personally tried few of them. > The easiest by far would be to use some light weight messaging like the > XML RPC over the HTTPS. > The client has everything to use HTTPS, the server probably should be > behind the web server like Apache to handle incoming and outgoing HTTPS > communication. > I know there are ways to eliminate the Apache from that picture, but I > newer tried it myself. > The beauty of this is - you are using most of the standard protocols so > you do not need to implement your own Public/private key encryption. > > One thing you can do also, is to install only your server SSL > certificate into your client and this way you will make sure that your > client can talk only to your server and nobody else. > > --Mark > > Terry Raymond wrote: >> >> Hi >> >> We have a client app and would like to have bidirectional encrypted >> message exchange with a server. >> >> As I understand from reading the Security doc the recommended way is >> to use a symmetric key cipher to >> >> encrypt the message and then encrypt the key using an asymmetric key >> cipher and send them as one message. >> >> The security doc refers to this as a digital envelope. Typically, the >> symmetric key is encrypted using the public key >> >> and decrypted with the private key. >> >> However, this does not address sending a message in the other >> direction. I would like to also encrypt with the >> >> private key and decrypt with the public key. My client would have only >> a public key. >> >> Does anyone know if there are any problems with this approach? >> >> Thanks. >> >> Terry >> >> =========================================================== >> >> Terry Raymond >> >> Crafted Smalltalk >> >> 80 Lazywood Ln. >> >> Tiverton, RI 02878 >> >> (401) 624-4517 [hidden email] >> >> =========================================================== >> >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Encrypted message exchange
|
|
Thanks Janko,
Can you give more details on the WebSocket -- where can you find it a and how one can use it ? -- Mark Pirogovsky Janko Mivšek wrote: > Hi Terry, > > I'd also go Mark way, using SSL therefore for encrypted channel. SSL has > also a n optional client authentication with a digital certificate, > besides mandatory server cert. For messaging over SSL I'd go with new > WebSocket protocol, to which a plain HTTPS is upgraded at the request. > Added benefit is that it goes through firewals as plain HTTPS go. > WebSocket is namely bidirectional full duplex messaging, contrary to > HTTP, which is unidirectional, half-duplex. > > In Smalltalk Swazoo has already a WebSocket support and there are > WebSocket clients like WebClient in Squeak and I think Zync will have it > too. Swazoo have plans to add back SSL support as well. > > Best regards > Janko > > > Dne 05. 04. 2012 17:01, piše Mark Pirogovsky: >> Terry, >> >> There are many ways to do it. And I personally tried few of them. >> The easiest by far would be to use some light weight messaging like the >> XML RPC over the HTTPS. >> The client has everything to use HTTPS, the server probably should be >> behind the web server like Apache to handle incoming and outgoing HTTPS >> communication. >> I know there are ways to eliminate the Apache from that picture, but I >> newer tried it myself. >> The beauty of this is - you are using most of the standard protocols so >> you do not need to implement your own Public/private key encryption. >> >> One thing you can do also, is to install only your server SSL >> certificate into your client and this way you will make sure that your >> client can talk only to your server and nobody else. >> >> --Mark >> >> Terry Raymond wrote: >>> Hi >>> >>> We have a client app and would like to have bidirectional encrypted >>> message exchange with a server. >>> >>> As I understand from reading the Security doc the recommended way is >>> to use a symmetric key cipher to >>> >>> encrypt the message and then encrypt the key using an asymmetric key >>> cipher and send them as one message. >>> >>> The security doc refers to this as a digital envelope. Typically, the >>> symmetric key is encrypted using the public key >>> >>> and decrypted with the private key. >>> >>> However, this does not address sending a message in the other >>> direction. I would like to also encrypt with the >>> >>> private key and decrypt with the public key. My client would have only >>> a public key. >>> >>> Does anyone know if there are any problems with this approach? >>> >>> Thanks. >>> >>> Terry >>> >>> =========================================================== >>> >>> Terry Raymond >>> >>> Crafted Smalltalk >>> >>> 80 Lazywood Ln. >>> >>> Tiverton, RI 02878 >>> >>> (401) 624-4517 [hidden email] >>> >>> =========================================================== >>> >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |