crypto.txt

*Cryptography*

Concepts
    **Cleartext** or **plaintext**: Text to be encrypted.
    **Ciphertext**: Encrypted text.
    **Passphrase**: password or key.
    **Encoding** involves replacing every ASCII character with an equivalent encoded set of characters.
    **Escaping** is trying to prevent a string from breaking out of a single or double quoted context by adding backslash character sequences. Encoding is way better solution in general.
    **Confusion** is a property that refers to methods used to hide relationships between the plaintext, the ciphertext, and the key.
    **Forward Secrecy** involves generating a secret without mentioning it. Therefore, compromising the private key in the future does not allow to decrypt the messages. Ciphers like Diffie-Hellman key exchange-based (DHE-RSA, DHE-DSA) and elliptic curve Diffie-Hellman-based (ECDHE-RSA, ECDHE-ECDSA).
    **Cryptographic signing**: Cleartext is hashed and the hashed signed with the private key.
    **Hashing**: one way irreversible function of fix size, any small variation in the input causes a very large variation of the output, with the output you can not generate the input, useful to verify passwords without actually storing the password. The output is of a fixed length that is usually much smaller than the input
    **Encoding** is designed to protect the integrity of data as it crosses networks and systems, i.e. to keep its original message upon arriving, and it isn’t primarily a security function. It is easily reversible because the system for encoding is almost necessarily and by definition in wide use.
    **Encryption** is designed purely for confidentiality and is reversible only if you have the appropriate key/keys.
    **Digital signature** allows to verify the authenticity of a message used in asymmetric encryption. It is usually a hash encrypted with the private key and  the algorithm used.
    **MACs** allow to verify authenticity of a message used in symmetric encryption.
    **Steganography** This is the art of hiding messages to conceal the existence of the communication.
    **Mixes and mix networks** are used to unlink the message form the sender (like btc mixers or TOR).
    **Blinding** allows a system to sign a message without seeing it.
    A **rainbow table** is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering a plaintext password (or credit card numbers, etc) up to a certain length consisting of a limited set of characters. It is a practical example of a space–time tradeoff, using less computer processing time and more storage than a brute-force attack .
    **Certificate transparency** is a proposal to improve PKI by keeping a record of all certificates. The CAs must send them to a public log server and they will receive a signed certificate timestamp to relay to the end users. The log can be monitored and fraudulent ceritificates identified quickly.
    Certificates contain the public key, subject or distinguished name (DN). The CN is part of it, and it contains the hostname to validate.
    **Public key pinning** addresses the biggest weakness of the current PKI ecosystem, which is the fact that any CA can issue a certificate for any domain name without the owner’s permission
    **DNSSEC** protocol to extend DNS with integrity checking. Each nameserver has associated keys for that zone. DANE is a bridge between DNSSEC and TLS authentication.
    **Online Certificate Status Protocol (OCSP)** is an Internet protocol used for obtaining the revocation status of an X.509 digital certificates.
    **Sidejacking** is a special case of web application session hijacking in which session tokens are retrieved from an unencrypted traffic stream.
    **Key stretching** involves making a weak key stronger against bruteforce attacks by increasing the time it takes to test every key. Usually it is stretched by appling salts and macing the hash. algorithms are PBKDF2, bcrypt, and scrypt

Numbers generation
    True Pseudo Random Number Generator (TPRNG): Uses entropy from multiple sources such as keyboard strikes to get a good seed.
    Pseudo Random Number Generator (PRNG): Given a seed, you get random numbers. There are hardware devices within the CPU to do so.
    Cryptographic Pseudo Random Number Generator (CPRNG): are PDNGs that are unpredictable


Symmetric encryption algorithms (128/256 bits is considered safe)
    Provides confidentiality (in: plaintext, out: ciphertext)
    Safest is AES in CBC or CTR mode.
    Block ciphers: Operates on blocks of fixed sized (64 or 128)
        **DES**: key size 56 bits, can be bruteforced, no other weakness
        **Triple-DES**: concatenates two DES keys (still weak)
        **Blowfish** (weak).
        **AES**: Iterative block cipher, very secure. Needs the correct  block cipher mode to be safe.
    Stream ciphers: useful for encrypting streams of data
        **RC2**: insecure
        **RC4**: might be secure depending on usage

    Block ciphers
    Produce an output of the same size as the input.
    Require an **initialization vector (IV)**, which is a random number that guarantees that same key and plaintext don't produce the same output
    They need a mode of operation, which can be:
    **Electronic Code book ECB**: each block is encrypted separately (less entropy). You should only use it if you have a single block: It produces the same result for the same input so: 1) Patterns in ciphertext will match patterns in plaintext. 2) Attacker can detect repeated messages. 3) An attacker that can submit arbitrary plaintext for encryption and observe the ciphertext will be able to guess the plaintext (BREAST).
    **Cipher Block Chaining CBC**: Each block is XORed with the previous ciphertext block before being encrypted, more entropy
    They need an initialization vector that has to be unpredictable.
    CTR
    GCM

    Stream ciphers
    Take a key and produce a key stream which can be XORed with a plaintext bit stream to produce ciphertext. The same key stream is used on the other side to XOR and decrypt.

Asymmetric encryption algorithms
    3245 bits is considered safe
    Provides authentication (in: plaintext, out: signature) and key agreement.
    Public key encryption provides a protocol for encrypting (confidentiality to a message for the key owner) and signing messages (non-repudiation for parties how have public key).
    **RSA**: difficulty of factoring large numbers. can be used for encryption and signing
    **DSA**: fast at signature creation but slower at validation. Can only be used for signing?


    **Diffie-Hellman** is a key-exchange protocol (not an encryption algorithm) used to build a shared secret over a public medium. It allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher. Works by each party choosing a prime number, sending another number and computing the modulus. It is vulnerable to man in the middle, since neither of the parties are authenticated.

Hashing
    **MD4/MD5/SHA1**: broken
    **SHA-256/SHA-512**: secure
    MD5 is 32 characters long, hex character space.
    In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" data, a password or passphrase. Salts are closely related to the concept of nonce. The primary function of salts is to defend against dictionary attacks or against its hashed equivalent, a pre-computed rainbow table attack.


Prevent MITM:
    SSH uses hosts fingerprint to detect mitm
    SSL uses certificates to validate identity

TLS handshake.
    The TLS Handshake Protocol involves the following steps:
    **ClientHello**: The client sends the supported protocols, ciphers , random str (to prevent reply attacks), empty session ID, compression and extensions.
    **ServerHello**: the server responds with the choosen protocol, server time, random bytes, the session ID, extensions.
    **Certificate**: The server sends the X509. certificate's chain. Main certificate, and the intermediate ones in the right order. The root can be ommited.
    **ServerHelloDone**: the server sends it to indicate that he has sent all the handshake data.
    **ClientKeyExchange** is sent by the client and carries information for the key exchange
    **ChangeCipherSpec** is sent by both server and client to indicate there is enough info to generate the encryption keys.
    **Finished** is a message that signals that the handshake finished, it is also sent by both, it is encrypted  and contains a MAC of all the messages sent in the handshake.


Key Exchange
    **RSA** it is the most widely used **key transport algorithm**, the client generates the premaster secret and encrypts it the server's public key. If the private key is compromised, the attacker eversdroping the network will be able to decrypt all communications. Authentication is implicit, otherwise the server can not decrypt the premaster key.
    **DHA_RSA** is a **key agreement algorithm** and provides forward secrecy, it is used with RSA for authentication. It allows two parties to establish a shared secre over an insecure channel. The maths is that it is easy to do a power of a primer number but difficult to obtain the original number with the power. The parameters sent by the server are signed with the private key to provide authentication.
    **ECDHE_RSA**  Ephemeral elliptic cuve Diffie-Hellman is a **key exchange algorithm** that provides forward secrecy and it is faster than DHA. It is simmilar to DH but uses elliptic curves to find big prime numbers. Authentiation is the same as DHA.



MAC
    **Message authentication code (MAC)**  provides authentication and integrity (if used correctly) to the message. The plaintext is hashed with a secret symmetric key, generating a signature, which is sent with the message. MACs do not encrypt the message. Instead, the message (encrypted or not) must be sent alongside the hash. Without a MAC an attacker could modify a message encrypted with AES and the recipient could not tell. An MAC by itself does not provide message integrity. You need to hardcode the hash somewhere else or have a sequence number or hash the version of the binary. MACs usually contain the sequence number or dates to prevent reply attacks. Usually the key and plaintext is concatenated and then hashed. This prevents an attacker who finds a collision from recovering the key. MACs differ from digital signatures as MAC values are both generated and verified using the same secret key.
    **Hash message authentication code(HMAC)** is a type of MAC. Uses md5, sha1,256... The name is **HMAC_** and the hashing algorithm.

    It is better than MAC because it is robust against **length extension attacks** as the message is hashed twice. First, the secret key derives two keys inner and outer
        1) hash(innerkey and message)
        2) hash(result and outer key)
    HMAC hashes twice the message.
    HMAC generation uses two passes of hash computation. The secret key is first used to derive two keys; inner and outer. The first pass of the algorithm produces an internal hash derived from the message and the inner key. The second pass produces the final HMAC code derived from the inner hash result and the outer key **H(key || H(key || message))** How the keys are derivated is not too much relevant as long as you have a different digit.

    The most common attack against HMACs is brute force to uncover the secret key. HMACs are substantially less affected by collisions than their underlying hashing algorithms alone
    **Length extension attacks**: MACs require the text to be padded, if the message length is known, and the final hash in known, an attacker can add additional text to the message making the hash still valid. You can set the state of the hashing algorithm to the same as it was when it finished generating the server's signature, then you can append anything to the message and the hash will match. If you do **H(M||K)** the attack is mitigated.

    As we can see, the padding is not maced, so length extension attacks where possible in TLS 1.1.
    **IV + AES(MAC(Sequence number + header + plaintext) + padding)**

Cryptographic Weaknesses
    Pseudorandom number generators (PRNGs)
    Protocols providing transport layer security (such as TLS and IPsec)
    Encryption of data at-rest
    Signing of data to provide integrity checking (e.g., HMAC calculation)


Certificate lifecycle
    a Certificate signing request is submitted to a CA. The ca validates the domain, organization and then issues the certificate and all the intermediary certificates.

Revocation of certificates
    It happens through **online certificate status protocol (OCSP)**, which allows real time lookups of certificates. The TLS handshake provides real time OCSP verification called **OCSP stapling**.
Attacks against cryptosystems:

    Cryptography is not usually broken but bypassed (bruteforce, implementation bug, timing attacks)

    **Collisions** Message digests used for integrity checking can be circumvented if a collision is found, where two different messages generate the same digest (signature). MD5 collisions can be easily generated. A collision can be used to generate malicious material (e.g., a certificate or ticket) which is in turn trusted.

    **Modification of ciphertext** If ciphertext generated by a stream cipher (e.g., RC4) or certain block ciphers (ECB, CBC, and CTR) lacks integrity checking, an adversary can modify it to generate useful plaintext upon processing by a recipient. Bit flipping and block rearranging can produce predictable changes to plaintext upon decryption.

    **Replay of ciphertext** Many protocols (including older 802.11 WiFi standards) do not track state. Encrypted 802.11 network frames can be replayed to an access point or client with unintended results, for example. In an authentication context, implementations lacking state tracking or use of a cryptographic nonce are also susceptible to replay attack—by which an attacker captures a token and later presents it to authenticate.
    **Side channel attacks** Sensitive material is sometimes leaked through oracles. In most cases, a side channel attack involves interacting with either timing or error oracles. A timing oracle leaks information based on the timing[…]

    **Known weak algorithms**: **RC4** is only insecure if a long term key is used, and other unrealistic conditions, it is better to use CBC though.

    **Birthday attack** If there are 23 people in a room, there is a 50% change or two having the same birthday. An attacker can find two documents with the same hash and substitute them.
    **Downgrade attacks**: MITM against the protocol to an insecure version.
    **Traffic analysis** looking for patterns.
    **Timing attacks** some operations take longer.
    **MITM** can do replay or just relay or tampering.

TLS
    Cipher suites are defined as:
        Key exchange and authentication method
        Bulk symmetric encryption algorithm, key length, and mode
        Message authentication code (MAC) algorithm and PRF
    For example:
    **TLS_RSA_WITH_RC4_128_MD5** means RSA, 128 bit RC4 and 128 HMAC-MD5.
    Padding oracle attacks are a weakness in som cipher block chain algorithms where some blocks need to be padded with extra bytes, those bytes are deterministic depending on the plain text, so if you can do a MITM to an SSL session that uses a block cipher of type CBC, you can change those pads, send it to the server to guess the plaintext
    The cert contains:
        **Subject** Contains the domain name
        **Authority Key Identifier** key identifier of the Issuing CA certificate
        **Subject Key Identifier**  This is a hash value of the SSL certificate
        **Validity**

Brute force
    If the character set is 35 characters and password length 5 characters, there are **35^5~=52M** possible combinations

TLS vulnerabilities
    **Heartbleed** exploits a bug in the heartbeat functionality of OpenSsl, which is used to know if the other party is still alive in the connection. The attacker controls the string that the other party has to reply with and the length, but you can specify a longer buffer than payload in the memcpy, leaking memory of the server process including passwords private keys, user data etc
    **DROWN (CVE-2016-0800)** An SSL 2.0 padding oracle attack resulting in RSA private key exposure.
    **Logjam (CVE-2015-4000)** Systems supporting DHE and group sizes less than 1,024 bits are vulnerable to MITM, by which a weak group is forced, and encryption attacked to reveal plaintext content.
    **POODLE (CVE-2014-3566)** SSL 3.0 using CBC mode ciphers is vulnerable to a padding oracle attack. Exploitation requires network access, along with JavaScript run by the victim browser to generate traffic (performing a chosen-plaintext and chosen-boundary attack). A padding oracle within the CBC decryption mechanism is used to reveal a secret (e.g., session token) byte-by-byte upon modifying plaintext via the JavaScript agent.
    **BEAST (CVE-2011-3389)** TLS 1.0 generates predictable IV values when using CBC mode ciphers. It is possible to deduce secrets through undertaking a blockwise chosen-boundary attack upon injecting an agent (e.g., Java applet) into a victim’s browser and monitoring the ciphertext.
    **CRIME (CVE-2012-4929)** Servers running TLS 1.2 and prior that support compression are vulnerable to attack via CRIME. Practical exploitation requires network access, along with JavaScript run by the victim browser to generate ciphertext (performing a chosen-plaintext and chosen-location attack). A side channel introduced by the server compression mechanism is monitored, revealing a secret (e.g., session token) byte-by-byte upon modifying the plaintext.
    **BREACH (CVE-2013-3587)** Web applications that use HTTP compression and reflect static secrets (e.g., session tokens) to clients via HTML can be targeted through BREACH. As with CRIME, the attack relies upon a JavaScript agent to generate traffic and undertake a chosen-plaintext attack through monitoring response lengths to infer each byte of a secret.
    **TIME** It targets HTTP compression but does not require network access to exploit. After malicious JavaScript is injected into a browser, an adversary can deduce secrets (e.g., session token values) byte-by-byte through monitoring responses to chosen-plaintext values used in particular locations. A timing side channel is used upon aligning HTTP responses to an MTU boundary.
    **RC4 byte biases (CVE-2013-2566)** The RC4 algorithm has many byte biases, which an adversary can use to recover plaintext bytes at known locations (such as a session token within a cookie) upon encrypting the same plaintext many times and monitoring the ciphertext. The attack requires generation of extremely large data volumes. Thus it is somewhat impractical but highlights a significant flaw within RC4.
    **Insecure renegotiation (CVE-2009-3555)** TLS endpoints might support insecure renegotiation, making it possible for an attacker with network access to prefix legitimate session traffic from a client to server with his own (e.g., a malicious HTTP request). Depending on the configuration of the application, this can result in HTTPS to HTTP downgrade or malicious commands being processed.
    **Insecure fallback** Outdated clients support insecure fallback, which an attacker with network access can exploit to downgrade a session to TLS 1.0 or SSL 3.0. The IETF resolved the issue by introducing a new cipher suite (TLS_FALLBACK_SCSV),36 which prevents downgrade of TLS implementations that support the cipher.