hello,
would it be possible to add an option allowing the user to create 2048 and 4096 bit rsa keys? the story that the keys are too big is a false story with 5G. even the NSA no longer recommends ECC keys.
However, in August 2015, the NSA announced that it plans to replace Suite B with a new cipher suite due to concerns about quantum computing attacks on ECC.
Wikipedia reference you quoted does not say that RSA is more secure than ECC. It advises not to spend effort to transition from RSA to ECC to avoid a second transition from ECC to quantum resistant algorithms: āFor those partners and vendors that have not yet made the transition to Suite B elliptic curve algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition.ā This is from the page about Suite B which is outdated now: https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm
Commercial National Security Algorithm Suite - Wikipedia has some more references and says 3072-bit RSA is now supported (probably for legacy reasons) and does not introduce any quantum-resistant algorithms yet, probably because they are still experimental and not too well researched, while the risk of quantum computers becoming generally available soon was overestimated in 2015. 2048-bit RSA is considered insecure according to this new standard. Basically the advice boils down to āupgrade to ECC if you use less than 3072-bit RSA, keep using ECC if you have already transitioned to ECC and donāt bother transitioning to ECC from 3072-bit or 4096-bit RSA otherwise as you will probably need to transition to quantum-resistant algorithms again in the not so distant futureā.
RSA is not quantum resistant too, in fact Shorās algorithm is designed for integer factorization and directly applies to breaking RSA keys. In case quantum algorithms become practically available, both RSA and ECC will fail quickly. But I expect that practical quantum-resistant algorithms will become available in libraries like OpenSSL first, at which point we will switch to them. Wire did some research into quantum-resistant algorithms at some point and AFAIK did not adopt them in their messenger: Blog So I think a pragmatic solution is to keep using ed25519 and wait for standards for quantum-resistant algorithms approved by experts and merged into TLS, SSH and similar standard ciphersuites. If quantum computers become available before this point, we will have much bigger problems to solve than trying to keep our emails secure.
I have no idea how 5G is related, AFAIK wireless networks use symmetric encryption most of the time and it does not matter much which asymmetric encryption (RSA/ECC) is used during session establishment as it happens only when you connect to the network.
But on the application level, like in Delta Chat, RSA keys sent in each Autocrypt header indeed waste more traffic for the same level of security than ed25519 keys we use now. Ask Delta Chat users who donāt have unlmited traffic, for example @adbenitez 
If you really want to use RSA, I would recommend at least not to use less secure 2048-bit keys. You can generate 3072-bit key or 4096-bit key manually and import it into Delta Chat if you want, but be aware that it will result in significantly larger Autocrypt headers and no practical security benefit.
By the way, previously Delta Chat used RSA 2048 keys and there is still an option to do this. It is just not exposed in the UI and only used during the tests to test for compatibility with old RSA versions of Delta Chat. This was changed to Ed25519 during the effort to reduce traffic and there is a screenshot showing how much smaller Ed25519 keys are, RSA key did not even fit on the screen: Saving Network Traffic - Delta's Efforts to Reduce the Message Size - Delta Chat
loki5 Please mind your tone here, I kinda regret allowing your post that the system flagged now that I read it. I might hide or delete your post because of your tone, make a new post with neutral tone if you really want to discuss this.
just fork it and release you own version that has longer keys if you donāt trust us.
The decision was really made for data saving for users that donāt have infinite data.
If you want users to have confidence, you just need to provide an option to create keys
1-ECC (default, recommended)
2- RSA 2048
3-RSA 4096.
User is able to know if he has a large amount data on your phone plan or not.
Since you donāt do it, we can legitimately ask questionsā¦
The option actually exists in the core and allows switching between RSA 2048 (which was a previous default) and Ed25519 (which is the new default also documented in the Autocrypt documenation). It is only used in automated tests though and there are no plans to add such option to the UI.
We generally try not to add such low-level options to the UI unless necessary. If such option is to be added, it would go to āAdvanced optionsā of the login screen, which already has options for IMAP and SMTP hostname and port and TLS certificate checks.
These keys are also sent in Autocrypt and Autocrypt-Gossip headers, so what matters is not the sender data plan and storage, but receiver. Messages are more often downloaded than uploaded, e.g. if a user participates in a group with 10 members, the message will be uploaded only once and downloaded 9 times.
Not everyone speaks in groups, there are also individual discussions. At the end of the day, when you are asked for an option to have real security, you explain how we do without it. So we are right to stop using deltachat due to its lack of security.
just make a fork, If you are sceptical and donāt trust the devs then you should built it yourself anyway.
Even if you can not code, you would still be able to change the default for your build.
I think mistrust in ECC comes from Dual_EC_DRBG story and this comment. Switch from NIST-standardized curves to Curve25519 by OpenSSH, Tor, Wireguard, Signal, Olm (Matrix) etc. is actually a response to this, quite well documented on wikipedia with references: Curve25519 - Wikipedia
I opened a PR to add RSA-4096 generation support, but no promises about an option being added to UIs:
It is probably more interesting to test and fix key import so users can generate whatever key they want and import it into Delta Chat reliably:
This way we will not need to clutter the UI with options.
I opened a separate topic to discuss key import:
Key import is possible but it takes too long. The keys must be generated on a computer and then imported. It is not practical. You need an option directly in deltachat. You make a simple deltachat but for this import practice it is too complicated for people.
There is not only the DUAL_EC problem, many specialists think that the ECC keys are too short and that it is voluntary for the NSA to decrypt everything. Alternatively, you can add an option for 1024-bit ECC keys so that everyone is satisfied and we have no more suspicions to have. The stories of bandwidth used by RSA keys are nonsense. Then we will be told that in order to combat global warming, we must also reduce the size of the keys. Each user should choose the keys he wants.
You only need to do it once.
[Citation needed]
This does not make any sense to me. Can you give any example of a system using 1024-bit ECC keys? Key size for Curve25519 (used in Delta Chat) is 256 bits, key size for Curve448 (used in OTRv4) is 446 bits. I am sure actual specialists will not be satisfied if we just invent some curve with 1024-bit keys which is not a NIST curve and not one of Curve25519/Curve448. This would also break compatibility with other OpenPGP implementations, e.g. Thunderbird.
Also note that ECC curve with 256 bits is not directly comparable to RSA key with 256 bits.
Some estimates for ECC and RSA bruteforce complexity are:
1024-bit ECC key would roughly correspond to 80kb (10kB) RSA key.
You can open the MIME message and see for yourself how much space Autocrypt header with Curve25519 key takes compared to RSA-4096. Or compare the size of RSA and Ed25519 SSH keys in ~/.ssh/authorized_keys file. This matters for users who have ~1G of internet traffic per month or 100MB mailbox quota.
This is not possible when your correspondent does not know the computers. Itās too long to explain how to generate them and he doesnāt understand. You need a simple system included in deltachat.
This does not make any sense to me. Can you give any example of a system using 1024-bit ECC keys?
It was a way of talking to explain that you can generate ECC keys of any length.
NIST-approved curves allow the NSA to attack only these curves. Before each software generated its own random curve (as when generating a random RSA key). Now, with NIST, ECC attacks are made easier.
There are rumours that Daniel Bernstein works for the NSA in secret. I have no confidence in all its public key or private key algorithms. It would be the same as the Crypto AG operation but at the level of algorithms.
This information is given over private networks. I will not give links.
Ok then put an option for the RSA 4096.
This matters for users who have ~1G of internet traffic per month or 100MB mailbox quota.
It does not concern me. They will not activate the option and will not use their data or quota.
Could you give any example of such software?
This is not how ECC works I believe, all software I know generates points on curve and not curves themselves. Generating ECC curve is a research work and generating a random one will most likely give you an unsafe curve. For communication software it is even more difficult to imagine because implementations must be tested to handle edge cases exactly the same way by testing against carefully selected test vectors.
Generating ECC curve is a research work and generating a random one will most likely give you an unsafe curve
It seems you are right. I note that unsafe curves have been generated by crypto governement agencies or official bodies :
NIST P-224
NIST P-256
NIST P-384
ANSSI FRP256v1
All this only confirms what Iām saying: put an option to generate RSA 4096 keys because other curves that seem safe today may not be because they have not been detected as unsafe by the scientific community (especially Bernstein curves that I donāt trust).
We generally do not expose public key cryptography terminology or options to regular users but some limited support for key management is in advanced settings and you may import your own RSA4096 key there.
If you have scientific sources for vulnerabilities with the current default keys of Autocrypt 1.1 (Curve25519) then please let us know. Otherwise letās close the topic here. Thanks.
This is what I explained from the beginning: I no longer use Deltachat because you donāt allow users to generate their keys in the app. You know perfectly well that it is complicated to generate and import keys from outside. GnuPGP allows you to generate the keys in the application, you donāt need to do much manipulation. You spend a lot of time improving the app on the details, but you donāt want to do anything when it comes to security. Donāt want to add the option and allow the user to select the security level he wants? Fine, but donāt be surprised if we think deltachat is working hand in hand with the Bundesnachrichtendienst.
we do not use GnuPGP in delta-chat.
you can use what you want, you can also fork deltachat if you like it and this is the only thing that annoys you.
Funny conspiracy theory with no evidence. Just āI donāt like your decisionsā¦ you must be working with my enemies.ā
Suspicion sets in when justifications do not hold water: too much data consumption. But this does not hold water because the option would not be enabled by default and would be a choice of the user (as for example if he wants to recreate an RSA 4096 key every week). Deltachat is not centralized, so it is up to the user to choose the data they use on their phone plan.
Just for reference, here is an old thread with a request for ECC support: