Forums Community Zero-knowledge

This topic contains 4 replies, has 2 voices, and was last updated by  Davidabary 10 months, 1 week ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #6236 Reply



    I have had an idea about how AxCrypt can be made truly zero-knowledge. It integrates with the existing workflow and requires minimal development as all of the infrastructure is already in place.

    The security increase by implementing this would be substantial and reduce the risk of AxCrypt being subject to legal process or rubber hose cryptanalysis because the user’s password would never be sent to the server and any evil modification would have to occur within the source code which is freely available and thus detectable.

    It’s so simple that I wonder if I’m missing something obvious.

    1 – Bob logs into the AxCrypt application using only his email address
    2 – Server sends an authentication code to Bob’s email [1]
    3 – Bob enters the code and the server sends the key-pair to Bob’s device [2]
    4 – Server simultaneously sends any licence file plus a token [3]
    4 – AxCrypt locally requests password which Bob
    5 – Software now functions as it does currently

    [1] Most email is sent over TLS which offers reasonable security. (As the user’s encryption password is currently sent over TLS to AxCrypt it can’t be disputed that an authentication code over TLS would reduce security.)

    [2] Even if Mallory had access to Bob’s email the returned key-pair would be useless because the private key requires the password (known only to Bob) before it can be used to decrypt files.

    [3] The token could be valid for 1-year. Unless Bob changed computers he wouldn’t be required to request another authentication code because the token would persist. Even upon restart, log off, shutdown, screensaver activation he’d only be asked to enter his password. The exception to this would be if he cleared all settings.

    Password changes would only be allowed if the user was logged in to the application and online. The software would authenticate with the server (using the token) and upload any necessary files to the server but it wouldn’t need to transmit the password.

    Eventually, to offer the greatest assurance, AxCrypt should implement fingerprint validation: if necessary behind an ‘Expert Mode’ button. Some users will be familiar with this as popular messaging apps like WhatsApp already provide this.

    The only small issue I envisage is the free AxCrypt online Password Manager. I don’t know how popular this is but those users would have to use a different password for that. The side benefit is that if somebody forgot one password (e.g. the encryption password) they wouldn’t lose access to their passwords and vice versa. If you were really keen on one password for everything then you could send Bob an XML file of the passwords at step 4 above. The passwords would be useless without the encryption password (e.g. Mallory gained access to the authentication code). Hence whenever a user updated a password the encrypted XML would be sent back to the server and synchronised.

    You could in theory get rid of the online account area as it’d be unnecessary although if you do keep it then you could simplify logging in by using the authentication token – the user clicks an ‘Account’ button within the software and that opens the online account with no further request for a password. Any upgrades to Premium would be done like this as well. You could introduce an option to ‘Disable Computer’ (i.e. revoke the authentication token) although this’d be largely unnecessary because the application prompts for the password at regular intervals so the risk from Mallory gaining access to the online account is negligible.

    I’m posting this publicly so that any experts can comment on, criticise or improve this suggestion.

    #6237 Reply


    Thanks Hjalmar,

    Handling the key pair and licensing can absolutely be done with a zero-knowledge protocol, like yours or similar to it. Actually I think it can be made even more simple, by simply generating the key pair locally and only upload the encrypted private key, never generating or encrypting it on the server.

    The main problem you have already pointed this out – the online password manager. It gets so much more complicated and risky if the data is kept locally, and it completely (well, almost) removes the use of it with a simple web browser – which actually is a very important use case for it! Downloading and uploading updates is of course possible, but inefficient after some time, and a little risky.

    Another problem, but it can be handled, is the invitation process. Where Alice invites Bob to a document, and Bob does not have an account. What we do now, is we generate the key on the server, and keep it encrypted with a machine key utnil Bob sets his own password, at which point the key is re-encrypted with that password. Of course, that can be tweaked to only use it as a temporary key until Bob sets his password at which point we update the key pair on the server with a locally generated one. This would minimize the exposure, even if not remove it completely.

    Of course – if you don’t use the password manager or ever sign in on the web, we don’t need to see the password.

    However, it does get a little more complicated for users to understand what’s going on, and for us to support them.

    We have relatively few users actually requiring zero-knowledge at this time.

    Concerning fingerprint support etc, it requires a little bit of extra consideration. Please read my blog post on the subject for a longer discussion: .

    Further comments welcome. We will be developing along these lines, but we some other priorities currently – most notably Mac OS X support which is coming soon!

    #6238 Reply


    Concerning fingerprint support etc, it requires a little bit of extra consideration. Please read my blog post on the subject for a longer discussion: .

    I don’t think I made myself clear. 😉

    I was thinking more along the lines of a PGP-style fingerprint [thumbprint] to ensure that the user is certain he’s communicating with the correct user, e.g. 0x937261. I wasn’t thinking of a biometric system.

    I know AxCrypt is essentially a simplified (that’s a good thing!) version of PGP which is why I thought of hiding the fingerprint behind another menu; i.e. there for users who want to take the extra step but not visible by default to avoid confusion.

    AxCrypt in this regard suffers a similar problem to iMessage or Facetime: you can’t verify the fingerprint of the other party and thus the security is somewhat weakened. WhatsApp, Signal and other messaging apps do allow you to verify the fingerprint of the recipient.

    Further comments welcome. We will be developing along these lines, but we some other priorities currently – most notably Mac OS X support which is coming soon!

    I’ll watch this space. 👍

    #6239 Reply


    Hello Hjalmar,

    Aha! I see ;-) That kind of fingerprint!

    Well… The idea behind the AxCrypt PKI is that you trust the AxCrypt server (yes, I know, but we’re willing to make well-defined compromises to achieve a higher level of usability). So, if you know the recipients e-mail address and know that the entity behind this email is who you want to communicate with, that should suffice.

    Maybe I’m still not understanding? I will admit I respond perhaps a little more rapidly than your quite advanced suggestions require…

    #6240 Reply


    I know you can manually check your own fingerprint in the config – AxCrypt refer to it as a thumbprint – although it is ultimately a centralised system. Having a UI option to visually compare the string adds an extra layer of security.

    WhatsApp deal with it in their own way (see illustration) and it’s found under a secondary menu. Something similar in AxCrypt would reduce the overall risk profile because AxCrypt couldn’t be secretly compelled (if such a law even exists) to change the recipient or add another party without detection.

    However as I’m typing this I can see the potential problem if such a demand was made because your server is the trusted authority. Because of the design choices it’d only affect online users and primarily those who share files.

    I suppose that a user concerned about this would have to manually exchange his public key with the recipient. That’d seems like a suitable workaround.

    Example WhatsApp Security Code (Fingerprint)

Viewing 5 posts - 1 through 5 (of 5 total)
Reply To: Zero-knowledge
Your information: