starred/SMSSync

Fork 0

mirror of https://github.com/ushahidi/SMSSync.git synced 2026-04-25 15:55:57 +03:00

[GH-ISSUE #148] Secret key for AES encryption #115

New issue

Open

opened 2026-02-28 01:23:15 +03:00 by kerem · 6 comments

kerem commented

2026-02-28 01:23:15 +03:00

Owner

Originally created by @9px on GitHub (Apr 1, 2014).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/148

using of valid HTTPS is not free, and using of HTTP is insecure.

also SECRET key can be listening by an attacker over HTTP.

it is desirable to use SECRET-key as key for encrypt exchanged data with method such as AES.

if this feature request approved, you can add an option to disable this as default for compatibility with older version PHP code.

Originally created by @9px on GitHub (Apr 1, 2014). Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/148 using of valid HTTPS is not free, and using of HTTP is insecure. also SECRET key can be listening by an attacker over HTTP. it is desirable to use SECRET-key as key for encrypt exchanged data with method such as AES. if this feature request approved, you can add an option to disable this as default for compatibility with older version PHP code.

kerem commented

2026-02-28 01:23:16 +03:00

Author

Owner

@eyedol commented on GitHub (Apr 17, 2015):

@9px asking for more clarification. You saying we should replace the use of secret with SECRET-key as the request variable?

@eyedol commented on GitHub (Apr 17, 2015): @9px asking for more clarification. You saying we should replace the use of `secret` with `SECRET-key` as the request variable?

kerem commented

2026-02-28 01:23:16 +03:00

Author

Owner

@9px commented on GitHub (Apr 17, 2015):

@eyedol first; thanks for your attention.
no. i suggest an option to adding in SMSSync setting: AES secret key
if user set the option, data exchange with server will be encrypt by the AES secret key instead of current plain data exchange.
naturally; for URL-safe data exchange, encrypted data must be encoded by base64.

@9px commented on GitHub (Apr 17, 2015): @eyedol first; thanks for your attention. no. i suggest an option to adding in SMSSync setting: `AES secret key` if user set the option, data exchange with server will be encrypt by the `AES secret key` instead of current plain data exchange. naturally; for URL-safe data exchange, encrypted data must be encoded by base64.

kerem commented

2026-02-28 01:23:16 +03:00

Author

Owner

@rjmackay commented on GitHub (Apr 20, 2015):

@9px Am I right that you're asking for us to encrypt the secret key when in transit between SMSSync and the server?
I'm not really sure we have the expertise / bandwidth to build something like that.. unless theres some existing encrypted auth scheme and libs we could rely on..

Aside: there are a number of free SSL cert providers now.

@rjmackay commented on GitHub (Apr 20, 2015): @9px Am I right that you're asking for us to encrypt the secret key when in transit between SMSSync and the server? I'm not really sure we have the expertise / bandwidth to build something like that.. unless theres some existing encrypted auth scheme and libs we could rely on.. Aside: there **are** a number of free SSL cert providers now.

kerem commented

2026-02-28 01:23:16 +03:00

Author

Owner

@9px commented on GitHub (Apr 20, 2015):

@rjmackay no. i say: instead of send/get sms text to/from server in simple plain text, send/get it with an encryption method. (such as AES).

this is very safe against sniffing HTTP trafic or MITM attack in HTTPS.

@9px commented on GitHub (Apr 20, 2015): @rjmackay no. i say: instead of send/get sms text to/from server in simple plain text, send/get it with an encryption method. (such as AES). ![sms encryption](https://stat-9px.rhcloud.com/smssync.gif) this is very safe against sniffing HTTP trafic or [MITM](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) attack in HTTPS.

kerem commented

2026-02-28 01:23:16 +03:00

Author

Owner

@redbullpeter commented on GitHub (Apr 20, 2015):

Some crypto info here: https://www.owasp.org/index.php/Java_Security_Frameworks

You could use this library: https://github.com/google/keyczar on the client end. To keep it simple, you could for example fix the encyption algorithm and use only a symmetric key system. The complexity starts on how to decrypt on the server end as that's not something you will have control over. Depending on the server environment the necessary libraries may not be installed.

@redbullpeter commented on GitHub (Apr 20, 2015): Some crypto info here: https://www.owasp.org/index.php/Java_Security_Frameworks You could use this library: https://github.com/google/keyczar on the client end. To keep it simple, you could for example fix the encyption algorithm and use only a symmetric key system. The complexity starts on how to decrypt on the server end as that's not something you will have control over. Depending on the server environment the necessary libraries may not be installed.

kerem commented

2026-02-28 01:23:16 +03:00

Author

Owner

@9px commented on GitHub (Apr 20, 2015):

thanks @redbullpeter. in server side usualy available encrypt/decrypt function/module for each language. for example in PHP we have some built-in function to do this, also in python, nodejs, etc.

@9px commented on GitHub (Apr 20, 2015): thanks @redbullpeter. in server side usualy available encrypt/decrypt function/module for each language. for example in PHP we have some built-in function to do this, also in python, nodejs, etc.