0
$\begingroup$

There are many limits on key size. As far as I know 56 bit in USA and 40 bits in India without license. On the other hand much higher 128 bit or 1024 or 4096 bit for banking and other purposes. So what will one do (I am not starting any banking business or something, just asking in case a man wants to make a secure app must he take license?) Without license one cannot comply with both.

Secondly I am new to TLS and cryptography in general. In case of https connection who decides the encryption strength the server or client. How can I force a less than 32-bit encryption on server and clientside. If the data is read then it's not a problem but want to prevent man in the middle attacks.

$\endgroup$
4
  • 6
    $\begingroup$ There haven't been legal limits for a long time. $\endgroup$
    – forest
    Oct 13 '20 at 4:57
  • 1
    $\begingroup$ Some references: What is Export/Import Control on Encryption? and Wikipedia on Restrictions on the import of cryptography. What about these? $\endgroup$ Oct 13 '20 at 5:30
  • $\begingroup$ No SSL/TLS (and HTTPS) implementation you can find today will support symmetric ciphers with strength less than 112 bits (tripleDES aka 3DES[-EDE]), and often not less than 128 (AES, Camellia, SEED, ARIA, GOST). However, if you want only authentication/integrity but not confidentiality, and limit yourself to TLS 1.2 or lower, there are 'eNULL' suites that do no encryption. Some implementations still support these, though rarely by default, since they are not considered broken -- they don't 'promise' confidentiality and fail to deliver it. See the RFCs. $\endgroup$ Oct 14 '20 at 0:17
  • $\begingroup$ Thanks for the reply! $\endgroup$ Oct 14 '20 at 3:36
2
$\begingroup$

There are many limits on key size. As far as I know 56 bit in USA and 40 bits in India without license.

In general, this is incorrect, at least for the US. However, when exporting cryptography you should be aware of export regulations for countries. It does generally matter how the cryptography is made available and to who. This site however doesn't give any legal advice.

In case of https connection who decides the encryption strength the server or client.

The client sends out the cipher suites, but the server gets to choose. Generally the server will support a small subset of ciphers for TLS 1.2. For TLS 1.3 the set of cipher suites was deliberately made smaller in the protocol specification.

How can I force a less than 32-bit encryption on server and clientside.

Generally you cannot get any cipher suite with so little security. Basically it would equate to no security at all, so you'd just be fooling yourself.

If the data is read then it's not a problem but want to prevent man in the middle attacks.

This means you need to authenticate the handshake and provide message integrity. "Unfortunately" if the key agreement and authentication is strong, then the encryption will be strong as well.

The only way to have weak encryption and strong authentication is therefore to deliberately weaken the encryption component.

$\endgroup$
1
0
$\begingroup$

See https://www.keylength.com/ for a comprehensive explanation and various key sizes to use

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.