Guest User

Developing A Secure Email/IM Replacement

a guest
Sep 6th, 2013
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.21 KB | None | 0 0
  1. Rethinking e-mail and IM for the "new" age of the Internet we've found ourselves in. Would appreciate feedback. First cut of a design:
  3. NuMail - secure e-mail / IM replacement for secure communications ('comms')
  5. General ideas:
  6. - server never sees plain-text comms
  7. - clients handle encryption/decryption
  8. - minimize attack vectors to client-only (keyloggers etc)
  9. - easy to use: users don't see private/public keys etc, they just need to remember one passphrase
  11. Account Creation:
  12. - client sends server:
  13. -- username
  14. -- scrypt(passphrase) ('hash')
  15. -- private key encrypted using hash
  16. -- plaintext public key
  17. - server generates salt, stores salt & scrypt(hash,salt), encrypted private key and plaintext public key
  18. - since hash was used to encrypt private key but server stores scrypt(hash,salt), server has just enough information to authenticate client but not enough to decrypt comms
  20. Have chosen scrypt as there are no known ASIC implementations.
  22. Login:
  23. - client sends server username and hash (via SSL - which CA's can be trusted?)
  24. - server checks that scrypt(hash,salt) matches stored data
  25. - upon success, client keeps in memory hash for duration of session.
  27. User A sends comms to User B (same server):
  28. - A's client asks server for B's public key (via SSL so no middle man can sub their own pub key)
  29. - A's client encrypts comms using B's public key => payload B
  30. - A's client encrypts comms using A's public key => payload A
  31. - A's client sends payloads B,A to server
  32. - Server stores payload B against B's account, payload A against A's account
  34. User A sends comms to User B (different server):
  35. - A's server asks B's server for B's public key, provides it to A's client
  36. - A's client encrypts comms using B's public key => payload B
  37. - A's client encrypts comms using A's public key => payload A
  38. - A's client sends payloads B,A to A's server
  39. - A's server stores payload A against account A, sends payload B to B's server which stores it against B's account.
  41. How Does B Read Payload B?
  42. - B asks server for B's encrypted private key
  43. - client uses in memory hash which was originally used to encrypt private key to now decrypt it, then uses decrypted private key to decrypt payload B
  44. - A can read payload A in the same way. Payloads A & B are identical in content
  45. when decrypted but require separate keys (A & B's respectively) to be decrypted by their owner
  47. Only way for server to spy on user comms would be to wait for user to login and record submitted hash, then use it to decrypt encrypted private key. This could be eliminated by storing encrypted private key client-side, but then the system becomes harder to use across multiple devices.
  49. I understand that javascript in it's current form isn't completely up to scratch for web-based client-side crypto ( But I don't think all of his points hold for this particular use case, particularly the point around using SSL making javascript crypto obsolete; not obsolete at all in the case of encrypting a message payload to ensure the server never receives and thus can never see/store/recover plaintext.
  51. Code would be open source. Anyone could host a NuMail server and charge for storage or other features.
  53. Thoughts?
Add Comment
Please, Sign In to add comment