Moreover, the id system that you use is actually not very convincing for people because someone could guess a random id and log into someone's account (even if the attempt fails up to 3 times, this is still vulnerable) and this application is paid which for some people is quite annoying .
Please note that Apple is using the same 4 digit code system to end-to-end encrypt your iCloud data, when it is synched with your phone. It is not using OPAQUE, it is using Secure Remote Password (SRP) protocol which is conceptually just like OPAQUE but has an extra leg of communication and does not have a security proof. I could have used SRP too, but I chose to use the newer OPAQUE which is still in an RFC draft, now in 11th iteration.
See page 35,36 of this document, which describes Apple security in 2014:
https://www.apple.com/mx/privacy/docs/iOS_Security_Guide_Oct_2014.pdf# Escrow security
iCloud provides a secure infrastructure for keychain escrow that ensures only authorized
users and devices can perform a recovery. Topographically positioned behind iCloud
are clusters of hardware security modules (HSM). These clusters guard the escrow
records. Each has a key that is used to encrypt the escrow records under their watch,
as described previously.
To recover a keychain, users must authenticate with their iCloud account and password
and respond to an SMS sent to their registered phone number. Once this is done, users
must enter their iCloud Security Code. The HSM cluster verifies that a user knows his or
her iCloud Security Code using Secure Remote Password protocol (SRP); the code itself
is not sent to Apple. Each member of the cluster independently verifies that the user has
not exceeded the maximum number of attempts that are allowed to retrieve his or her
record, as discussed below. If a majority agree, the cluster unwraps the escrow record
and sends it to the user’s device.
Next, the device uses the iCloud Security Code to unwrap the random key used to
encrypt the user’s keychain. With that key, the keychain—retrieved from iCloud key
value storage—is decrypted and restored onto the device. Only 10 attempts to
authenticate and retrieve an escrow record are allowed. After several failed attempts,
the record is locked and the user must call Apple Support to be granted more attempts.
After the 10th failed attempt, the HSM cluster destroys the escrow record and the
keychain is lost forever. This provides protection against a brute-force attempt to
retrieve the record, at the expense of sacrificing the keychain data in response.
In summary, Apple considers 4 digits to be secure enough, just like a bank.
When you argue that a 4 digit PIN is too short, are you arguing that a conventional password in its place would also be too weak? In that case, you are challenging the security of SRP and OPAQUE protocols, not merely Crosspass.
If you are not comfortable with 4 digits, then you can transfer 3 random keys, then combine them (by e.g. SHA or XOR) to get a new key. This way you increase the difficulty of guessing to a 12 digits password. That's 11.5 x 3 = 35 coin flips which the MITM must guess in 1 attempt. Using Crosspass 3 times in a row is still easier than PGP or Diffie-Hellman.
If you want an open source tool implementing OPAQUE, my patent would not stop you. My patent, in fact, does not limit to OPAQUE use, but says that any PAKE (Password Authenticated Exchange) can be used. So what is my innovation then, and why was I given a patent? My innovation is that I put it into a mobile phone form-factor. From the patent's abstract,
This invention enables asynchronous encrypted communication under a protection of a simple password which must be communicated out-of-band. The password is easily communicable in-person, by telephone or by a text message. The invention assumes that one of the parties has an online device, such as a smartphone. After the encrypted session has been established, it can be used for a variety of cryptographic applications, such as encrypting or decrypting messages, sharing of cryptographic keys, and verifying data. The invention also has the secondary benefit of authenticating both parties to each other.
About the bugs:
One thing I know that Crosspass has bugs currently:
- Crosspass is still Beta.
- The iOS version is more stable than the Android version.
- We are working on the bug found by @dkbit98 to improve error message, so that we can see what actually happened (I suspect it was related to app permissions).
- Known bugs are likely UI only and have no security implications. The protocol encryption itself is implemented in Go and is plugged into both iOS and Android apps as a library. Doing it this way allows to test the encryption by unit tests, offline and outside the app.
Here's a list of public dependencies from go.mod:
filippo.io/edwards25519 v1.0.0 // indirect
github.com/borisreitman/crypto v1.0.1 // indirect
github.com/cronokirby/saferith v0.33.0 // indirect
github.com/mtraver/base91 v1.0.0 // indirect
github.com/pylls/basket2 v0.0.0-20161221160633-eafbfb819e44 // indirect
github.com/twystd/tweetnacl-go v0.0.0-20210413205227-681aa97ec383 // indirect
gitlab.com/yawning/edwards25519-extra.git v0.0.0-20220726154925-def713fd18e4 // indirect
golang.org/x/crypto v0.0.0-20221012134737-56aed061732a // indirect
golang.org/x/mobile v0.0.0-20220928052126-fa6bcb076835 // indirect
golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e // indirect
