4 ms·
I remember 3-4 years ago when I was working with a major wall street financial company to integrate with their credit card processing gateway, some of the priva
by devy 9y ago
I remember 3-4 years ago when I was working with a major wall street financial company to integrate with their credit card processing gateway, some of the private and sensitive information (contracts, testing reports etc.) had already been communicated with a similar but proprietary AES 256 based encryption on a static HTML page via email attachments as a way of secure communication. The intended recipients would get an invite to their site to register/login to get the passphrase to unlock the encrypted static HTML doc. This could have been the standard practices in many financial firms theses days (when they are not using PGP/GPG encrypted emails)
Edit: redacted the name of company.
- wyc 9y agoI believe SendSafely (https://www.sendsafely.com/ https://www.sendsafely.com/) claims to have a somewhat secure/streamlined implementation of this. Browser non-plugin JavaScript crypto is always sketchy, but possibly better than nothing if the limitations are correctly communicated to the user.
- devy 9y agoSendSafely's workflow is quite different[1] from what I described with the encrypted static HTML email attachment. And I don't like the idea of sharing the confidential data over 3rd part cloud storage even if it's encrypted. [1]: https://www.sendsafely.com/howitworks/ https://www.sendsafely.com/howitworks/
- wyc 9y agoI agree there are differences, including transit route and format. Here are the similarities I saw: - Payload is encrypted client-side by the sender - Encrypted payload is decrypted client-side by the receiver - 3rd party provides the unlock passphrase I think I'd much prefer standard AES to AES sprinkled with a bit of proprietary magic, as the latter is more likely to introduce new attack vectors than not.