Reply To: AxCrypt Portable – truly standalone?

[SvanteSpectator]

Hello Hjalmar,

Thanks again for your input. Yes, the SSL/TLS issue is frequently debated and many distrust it for the reasons you describe, and with reference to various conspiracy theories.

I like your idea of using AxCrypt to encrypt the password as it is sent to the server, we’re actively trying to make the analysis as simple as possible, and that entails using / relying on as few mechanisms as possible. We’ve already discussed various ways of strengthening the protocol, including making a zero knowledge variant. (The problem with that is that some other things become less convenient. But that’s a longer discussion.)

The problem that will have to be investigated is just how robust such a large HTTP header is in practice. For it to be a relatively “simple” fit, I’d like to continue using basic authentication, and this entails sending the password in a HTTP header. A minimum AxCrypt file right now weighs in at about 5K, this can probably be reduced a little by extending AxCrypt to support a file-less format (that’s useful for other situations as well, such as AxCrypt-encrypting pure text etc), thus reducing the amount of headers etc, and perhaps even skipping the redundant headers in the trailer. But then it has to be Base-64 encoded, so it grows again. In the end the header will probably be on the order of 4K. To be honest, I just don’t know how will this will work. A mitigating factor is that it’s still inside a SSL/TLS connection so it should not be affected by intermediate stuff.

Still, I like it. Even better, it can be added without any problem for existing clients. The server can easily distinguish between the cases.

See:

https://bitbucket.org/axantum/axcrypt-net/issues/276/filter-out-components-from-the-user-email

https://bitbucket.org/axantum/axcrypt-net/issues/277/implement-file-less-axcrypt-encryption

https://bitbucket.org/axantum/axcrypt-net/issues/278/investigate-and-possibly-implement-axcrypt

Thanks!