I am planning to use AES CBC PKCS5PADDING with a passphrase to encrypt my REST API traffic to POST/GET over HTTPS from an Android application. the scope is to protect user data from MITM attacks and also if an attacker knows the clear text packets he could alter the API.

  1. Is there more secure method to do it?
  2. If an attacker knows the encrypted and decrypted text, is it possible for him to retrieve the passphrase ?

Example: The attacker may know that 0irIczt30hd1iDYH/xAjJQ== is 2 encrypted with AES CBC PKCS5PADDING

Can he retrieve the passphrase 2224567891234666 (even it seems to be simple to guess)?


  • 6
    Why do you need additional encryption to protect against MITM if you are already using HTTPS? – symcbean Jun 12 '18 at 12:08
  • Many end users don't mind if the traffic is intercepted, they accept everything even the connection isn't secure; also https isn't enough if you know how to use the tools of the trade – Abdelhafid Madoui Jun 12 '18 at 13:49
  • Certainly at least one of us doesn't know the tools the trade. stackoverflow.com/questions/9293019/… medium.com/@q2ad/… – symcbean Jun 12 '18 at 14:08
  • 2
    Please just use HTTP over TLS 1.2. Security and cryptography are hard problems, and attempting to wire up your own system from parts is only going to introduce vulnerabilities, not remove them. Yes, TLS 1.2 is enough even if you "know the tools of the trade" as many of us here do. – Stephen Touset Jun 13 '18 at 22:48
  • 4
    @AbdelhafidMadoui There are no "tricks of the trade" that work against proper TLS. Tools like moxie's sslstrip can only do so much. For properly-implemented TLS, there are no tools that can break it. – forest Jun 14 '18 at 10:39

It is unclear what you're trying to protect against, but in any case you're doing something wrong.

Are you trying to prevent an attacker from MitM intercepting legitimate users' traffic? Just use TLS (HTTPS). Seriously, it's the correct answer for this scenario. As long as you use modern ciphers and libraries (on both ends), you'll be secure against almost any conceivable (much less likely) attacker. If you want to be extra-careful, pin the certificate or public key info of your server (or your CA, at some level up the chain) so that even a compromised or malicious CA won't let somebody breach the communication channel.

Are you trying to use this as some sort of authentication mechanism? Using crypto to establish that both ends of the communication know a shared key, and therefore establishing the identity of the client, is a viable idea for a RESTful API (AWS, for example, does this with their SigV4 scheme). However, to do that, you need to use an authenticated form of crypto. Cipher Block Chaining (CBC) provides no authentication at all; an attacker who knows part of the plaintext for a message protected only by AES (or any other block cipher) in CBC mode can manipulate the ciphertext to produce a reliable change in the plaintext, and neither the victim nor the server will know. You may note that SigV4 doesn't actually do any encryption at all (only HMACs, a form of symmetric-key cryptographic signing); it isn't providing any confidentiality (HTTPS does that), only authenticity (ensuring that the message comes from the real source, and that it hasn't been tampered with in flight). You could fix this using an authenticated encryption mode of operation (like GCM), or by using asymmetric signatures (but then you may as well just use mutual TLS!), or by adopting a scheme like SigV4 (or just adopting it directly...), but your current scheme would not work.

Are you trying to prevent people from figuring out how to write third-party clients for your API? You can not prevent that. Don't bother trying. Whether by analyzing network traffic, reverse-engineering your binaries, or some other avenue, you can't prevent people from finding a key that you have to give your users. The best (in terms of technical knowledge and engineering resources applied) attempts at this are the commercial DRM systems that "protect" things like movies and commercial software, and those are still broken (sometimes with hilarious ease). It is fundamentally impossible to prevent them from being broken, in fact; the best you can hope for is to hide the key, and obscurity is not security.


Regarding the 2nd question: knowing a pair of plain text + cypher text the attacker can bruteforce the passphrase if it's simple to guess. Some level of protection against that can be given by use of password-based key derivation function (PBKDF2, Scrypt, etc.), that will allow you to use passphrase of any length and make the bruteforce much slower.

Regarding the 1st question: I'm not sure such encryption will make it much more secure then https-only. At least consider using some kind of MAC/authenticated encryption to protect against MITM, since CBC does not protect against message modification (it's easy for attacker to modify (xor) the first block of plain text without knowing the key, for example).

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.