Way to remove rc4 from Linux Cipher Suites

running this command resulted with the list of ciphers which supports rc4: /usr/bin/openssl ciphers -v | grep -i "rc4"

what’s the easiest way and how to remove specifically ciphers that supports rc4 that I need to execute or where is the configuration file in need to edit on Linux machines.

what’s the way to reverse the impact of this command? in case one of the server applications will stop working we will need to revert back to the previous Cipher Suites configuration.

Thanks!

Do Cipher Suites matter under attack using sslsqueeze tool?

I find that sslsqueeze tool can carry attack on SSL/TLS server and does not need to perform any cryptographic operations. I think that no matter which cipher suite used in handshakes, the tool consumes the same CPU power.

Then do cipher suites used in handshakes a factor to make the server more susceptible to the attack using sslsqueeze tool?

If cipher suites really matter, does it mean that attacker can specify certain cipher suite for handshake to make the attack more likely to succeed?

Why does TLS1.3 use same cipher suite for RSA and ECC key pairs?

As per this answer RSA and ECC certificates should use different cipher suites. I tried to test it. It holds true for TLSv1.2. But for TLSv1.3 I see same cipher suite being used for both types of certificates(Tested via Google Chrome=>Dev Tools=>Security). Why is that?

Here is how I generated an ECC cert:

openssl ecparam -out nginx.key -name prime256v1 -genkey openssl req -new -key nginx.key -out csr.pem openssl req -x509 -nodes -days 365 -key nginx.key -in csr.pem -out nginx.pem 

Generating RSA cert:

 openssl genrsa -out rsa.key 2048  openssl req -x509 -new -nodes -key rsa.key -days 7300 -out rsa.pem 

With TLS1.3 both the certs result in usage of same cipher suite:

The connection to this site is encrypted and authenticated using TLS 1.3,  X25519, and AES_256_GCM. 

With TLS1.2, RSA cert:

    The connection to this site is encrypted and authenticated using TLS 1.2,  ECDHE_RSA with X25519, and AES_256_GCM. 

With TLS1.2, ECC cert:

The connection to this site is encrypted and authenticated using TLS 1.2,  ECDHE_ECDSA with X25519, and AES_256_GCM. 

Cipher suite is different in “client hello” for the same code running on different platforms

I’m facing a “Alert: handshake failure (40)” error when trying to establish a TLS connection. The error only happens when I run the same application on cloud, it works when I run the application on HPG8 server. OS is the same Redhat 7. By checking into the traces, I found that the cipher suite in “client hello” is much less in the error case than the worked case, and the cipher suite that TLS server supported is just missed in the “client hello” of the error case. I want to know what will impact the cipher suite that contains in the “client hello”?

The openssl version is the same (1.1.1d) for both cases, Redhat version has small difference. TLS1.2 is used. The key file and cert file are also the same.

In the code, I’m using SSL_set_cipher_list to set the cipher string as “ALL:!DH:!EXP:!RC4:@STRENGTH”.

SSL_set_cipher_list(ssl, "ALL:!DH:!EXP:!RC4:@STRENGTH"); 

I also checked the source code of openssl, but didn’t find much clue.

Cipher suite in the failure case:

Cipher Suites (25 suites)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)     Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xc0af)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 (0xc05d)     Cipher Suite: TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (0xc061)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)     Cipher Suite: TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1)     Cipher Suite: TLS_RSA_WITH_AES_256_CCM (0xc09d)     Cipher Suite: TLS_RSA_WITH_ARIA_256_GCM_SHA384 (0xc051)     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)     Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 (0xc05c)     Cipher Suite: TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (0xc060)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)     Cipher Suite: TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0)     Cipher Suite: TLS_RSA_WITH_AES_128_CCM (0xc09c)     Cipher Suite: TLS_RSA_WITH_ARIA_128_GCM_SHA256 (0xc050)     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)     Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)     Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) 

Cipher suite for successful case (0xc02f is the suite that server returned in “server hello”):

Cipher Suites (45 suites)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)     Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xc0af)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 (0xc05d)     Cipher Suite: TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (0xc061)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc073)     Cipher Suite: TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)     Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)     Cipher Suite: TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1)     Cipher Suite: TLS_RSA_WITH_AES_256_CCM (0xc09d)     Cipher Suite: TLS_RSA_WITH_ARIA_256_GCM_SHA384 (0xc051)     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)     Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00c0)     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)     Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)     Cipher Suite: **TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256** (0xc02f)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 (0xc05c)     Cipher Suite: TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (0xc060)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc072)     Cipher Suite: TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076)     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)     Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)     Cipher Suite: TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0)     Cipher Suite: TLS_RSA_WITH_AES_128_CCM (0xc09c)     Cipher Suite: TLS_RSA_WITH_ARIA_128_GCM_SHA256 (0xc050)     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)     Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00ba)     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)     Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)     Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)     Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007)     Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) 

Is AES the recommended symmetric cipher for production level software?

I was considering developing an application level software for file encryption after stress testing many of my implementations of popular symmetric ciphers. I would love to support multiple algorithms like AES (GCM / CBC/ CTR) , XChaCha20-Poly1305 etc. But I’m on crossroads when choosing a very recommended symmetric cipher for my application, when it comes to performance as well as secure implementation. AES has been tried and tested for years and is still the most popular symmetric cipher in the world. It’s well documented and also standardized by various Governments (FIPS standard for example) , but very difficult to implement securely unless hardware acceleration is available. Pure software version of AES is slow and my application should be able to achieve the same performance on many devices. Also, AES GCM has a maximum size limit for messages ~ 64 GB, and I really wanted authentication with encryption!

  • Should I stick with AES and its various modes (ex. CTR HMAC SHA256) or is it time to adopt a new symmetric cipher like XChaCha20 or XSalsa20 with Poly1305, which is easy and secure to implement in software, but unfortunately not standardized yet ?

  • Also, why using a standardized cipher is recommended in production quality software?

Name of ‘smart brute force’ attack against sequential cipher lock [duplicate]

I remember learning about an attack against sequential cipher locks – ones that don’t have a ‘reset’ or ‘enter’, you just enter digits and as soon as the last n consecutive entries match, the lock opens. So, if the code is ‘1234’, the sequence ‘32431234’ will work just fine.

The attack depends on a specific sequence that appends such digits that the resulting ‘tail’ of the string is as new as possible.

Let’s take for example a 3-digit binary lock. The possible codes are 000, 001, 010, 011, 100, 101, 110, 111. To try all 8 codes in standard brute force attack, you’d enter 24 digits total.

But instead, entering sequence 0001110100, 10 digits total, you cover all combinations and unlock the lock – generating sequences: 000, 001, 011, 111, 110, 101, 010, 100, each new digit past first 2 generating a new code.

For the good of me, I can’t recall the name of the sequence used for this sort of attack.

Is there any existing obfuscation scheme that makes cipher text indistinguishable from plain text? [migrated]

Suppose a totalitarian government (in the name of anti-terrorism / protection of intellectual property):

  1. has outlawed encryption itself – encryption is only approved for cases where the state has reviewed the design and made sure it can decrypt/inspect the message, and made any unapproved encryption a criminal offense
  2. has total control over anything in and out of the network at ISP-level, as well as anything that passes through web services

How could two citizens Alice and Bob, using approved (and monitored) instant messaging service to set up a secure line of communication, conceal the fact that the communication is encrypted, i.e. to make it indistinguishable from unencrypted data, or at least, make it computationally- or financially-infeasible to distinguish it from plain text?

For example, no one would assume the following message to be encrypted:

  • Across the Great Wall, we can reach every corner in the world.

But it would be assumed that the following is:

  • WZ2A805Wq3rzpiuzE+ZCulgDrn76pVRW5PVUJ4DDadFQD4P9PsTeegbo5CAkqI4yZrO//p
    sYT+ZQkqZ6IrSGng==

  • 599D80F34E56AB7AF3A62BB313E642BA
    5803AE7EFAA55456E4F5542780C369D1
    500F83FD3EC4DE7A06E8E42024A88E32
    66B3BFFE9B184FE65092A67A22B4869E

For the purpose of this question, we assume the following technical details:

  1. the IM service is text-only, binary data is not allowed (in an IM setting, sending primarily small binary fragments back and forth would probably raise suspicion anyway)
  2. communication between Alice and the IM service, Bob and the IM service, are both end-to-end encrypted. A government agent Eve has a copy of the decryption key the IM service used
  3. proof that the message is encrypted is not required. I.e. Eve does not need to know the plain text or the algorithm used to produce the cipher text. She only needs to tell, with a reasonably-low false-positive rate, if a message is the result of an encryption
  4. the endpoint is secure, no backdoor or malware on the computer/router, etc.

I’d like to know if there are any reliable research on this, is it feasible or not, and if feasible, any existing protocol or algorithm developed for this?

Eve, in case you are watching, I’m asking this for academic purposes only. 😄