SecureJoin exchanges data via a separate channel, usually scanning QR codes to swap keys. Would it be possible to additionally exchange a one-time pad?
It would be discouraging if an attacker, after considerable trouble and expense breaking the encryption, sometimes only got streams of random characters.
Encrypting the first message via the QR code sounds like a good idea. I’d have thought Deltachat a good place to implement a optional one-time pseudorandom pad layer protocol, given its target audience, but I trust you have reasons.
If they key is completely random and you have to exchange the key between all devices in advance via second channel, then one-time pad is not practical because you need to transmit as much key data as you are going to transmit messages in advance and will eventually run out of the key. And if the key for “one-time pad” is pseudo-random and infinite, then it is essentially a bad stream cipher missing all the protections against common vulnerabilities such as accidental key reuse which can easily happen if you setup a second device by transferring a backup, has no integrity protection etc.
If I am transmitting text messages, a key the size of a year’s conversation is not all that long. To clarify, I’m not suggesting this as a default, or a sole encryption method, but as an additional layer for those who really need the security.
Agreed that they might want to import a file of true randomness, rather than use pseudorandomness from some noise from hardware they have on their device. But either, as an additional layer of encryption, would be an improvement, because the attacker has to break the public-key encryption before they can start hoping that the pseudorandomness isn’t very random.
Key reuse would indeed be a problem if pads could be copied to multiple devices. It would make sense to prevent such copying.
Are smartphones equipped to read the screen display for ChipTAN or do you need special hardware?
I assume that you could similarly transmit more information than a single QR code by generating a series of QR codes which could then be recorded by video instead of camera, although I don’t know if there are any existing libraries to decode this.
In any case, apart from the possibility of one-time pads, a higher
capacity data channel such as the suggested screen display for ChipTAN would allow Delta Chat to overcome the obstacle to including the encryption key in the QR code and allow new contacts to send encrypted messages immediately (although this wouldn’t be possible for invite links).
photoTAN is definitely not readable by normal camera apps. ChipTAN needs a card reader.
The apps can implement a scanner for those custom codes, but the convenience of using the camera app and third party scanners would be lost.