Question

What specific concepts from the ones listed below do you find the most interesting and/or impactful to Cybersecurity? Explain the concept thoroughly, explain your position (e.g. why is it impactful to the field of Cybersecurity and/or so interesting to you) and provide several examples that support your argument.

Applications of Cryptography and PKI

Trust relationships

Password guessing / cracking

Public Key Infrastructure

Certificates

Key Management (creation, exchange/distribution)

Common Cryptographic Protocols

Types of Attacks (brute force, chosen plaintext, known plaintext, differential and linear cryptanalysis, etc.)

Implementation failures

Answer 1

PKI and Cryptographic Applications

Asymmetric Cryptography

Public and Private Keys

In Public key cryptosystems, every user maintains both a public key and a private key. As the names imply, public key cryptosystem users make their public keys freely available to anyone with whom they want to communicate. The mere possession of the public key by third parties does not introduce any weaknesses into the cryptosystem. The private key, on the other hand, is reserved for the sole use of the individual who owns the keys. It is never shared with any other cryptosystem user.

RSA

The RSA algorithm depends on the computational difficulty inherent in factoring large prime numbers. Each user of the cryptosystem generates a pair of public and private keys using the algorithm described in the following steps:

1. Choose two large prime numbers (approximately 200 digits each), labeled p and q.
2. Compute the product of those two numbers: n = p * q .
3. Select a number, e , that satisfies the following two requirements:
   1. e is less than n .
   2. e and ( n – 1)(q – 1) are relatively prime—that is, the two numbers have no common factors other than 1.
4. Find a number, d , such that ( ed – 1) mod (p – 1)(q – 1) = 0.
5. Distribute e and n as the public key to all cryptosystem users. Keep d secret as the private key.

El Gamal

ElGamal encryption system is an asymmetric key encryption algorithm for public-key cryptography which is based on the Diffie–Hellman key exchange. ElGamal encryption can be defined over any cyclic group G. Its security depends upon the difficulty of a certain problem in G related to computing discrete logarithms. El Gamal also has a major disadvantage—the algorithm doubles the length of any message it encrypts.

Elliptic Curve

Elliptic-curve cryptography (ECC) is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields.

Hash Functions

Hash functions have a very simple purpose—they take a potentially long message and generate a unique output value derived from the content of the message. This value is commonly referred to as the message digest. Message digests can be generated by the sender of a message and transmitted to the recipient along with the full message for two reasons :

• The recipient can use the same hash function to recompute the message digest from the full message. They can then compare the computed message digest to the transmitted one to ensure that the message sent by the originator is the same one received by the recipient.
• The message digest can be used to implement a digital signature algorithm.

According to RSA Security, there are five basic requirements for a cryptographic hash function :

• The input can be of any length.
• The output has a fixed length.
• The hash function is relatively easy to compute for any input.
• The hash function is one-way (meaning that it is extremely hard to determine the input when provided with the output).
• The hash function is collision free (meaning that it is extremely hard to find two messages that produce the same hash value).

SHA

The Secure Hash Algorithm (SHA) and its successors, SHA-1 and SHA-2, are government standard hash functions developed by NIST. SHA-1 algorithm processes a message in 512-bit blocks. Cryptanalytic attacks have demonstrated that there are weaknesses in the SHA-1 algorithm. This led to the creation of SHA-2, which has four variants :

• SHA-256 produces a 256-bit message digest using a 512-bit block size.
• SHA-224 uses a truncated version of the SHA-256 hash to produce a 224-bit message digest using a 512-bit block size.
• SHA-512 produces a 512-bit message digest using a 1,024-bit block size.
• SHA-384 uses a truncated version of the SHA-512 hash to produce a 384-bit digest using a 1,024-bit block size.

MD2

MD2 pads the message so that its length is a multiple of 16 bytes. It then computes a 16-byte checksum and appends it to the end of the message. A 128-bit message digest is then generated by using the entire original message along with the appended checksum.

MD4

MD4 pads a message to ensure that the message length is 64 bits smaller than a multiple of 512 bits. For example, a 16-bit message would be padded with 432 additional bits of data to make it 448 bits, which is 64 bits smaller than a 512-bit message. The MD4 algorithm then processes 512-bit blocks of the message in three rounds of computation. The final output is a 128-bit message digest.

MD5

MD5 processes 512-bit blocks of the message, but it uses four distinct rounds of computation to produce a digest of the same length as the MD2 and MD4 algorithms (128 bits). MD5 has the same padding requirements as MD4—the message length must be 64 bits less than a multiple of 512 bits.

Digital Signatures

Digital signature infrastructures have two distinct goals :

• Digitally signed messages assure the recipient that the message truly came from the claimed sender. They enforce non-repudiation (that is, they preclude the sender from later claiming that the message is a forgery).
• Digitally signed messages assure the recipient that the message was not altered while in transit between the sender and recipient. This protects against both malicious modification (a third party altering the meaning of the message) and unintentional modification (because of faults in the communications process, such as electrical interference).

HMAC

The Hashed Message Authentication Code (HMAC) algorithm implements a partial digital signature - it guarantees the integrity of a message during transmission, but it does not provide for nonrepudiation. HMAC can be combined with any standard message digest generation algorithm by using a shared secret key, and therefore, does not provide any non-repudiation functionality.

Digital Signature Standard

NIST specifies the digital signature algorithms acceptable for federal government use in Federal Information Processing Standard (FIPS) 186-4, also known as the Digital Signature Standard (DSS). This document specifies that all federally approved digital signature algorithms must use the SHA-2 hashing functions. DSS also specifies the encryption algorithms that can be used to support a digital signature infrastructure. There are three currently approved standard encryption algorithms :

• The Digital Signature Algorithm (DSA) as specified in FIPS 186-4
• The Rivest, Shamir, Adleman (RSA) algorithm as specified in ANSI X9.31
• The Elliptic Curve DSA (ECDSA) as specified in ANSI X9.62

Public Key Infrastructure

The major strength of public key encryption is its ability to facilitate communication between parties previously unknown to each other. This is made possible by the public key infrastructure (PKI) hierarchy of trust relationships.

Certificates

Digital certificates provide communicating parties with the assurance that the people they are communicating with truly are who they claim to be. They contain specific identifying information, and their construction is governed by an international standard - X.509.

Certificate Authorities

Certificate authorities (CAs) are neutral organizations that offer notarization services for digital certificates. Registration authorities (RAs) assist CAs with the burden of verifying users’ identities prior to issuing digital certificates.

Certificate Generation and Destruction

Enrollment : When one wants to obtain a digital certificate, they must first prove their identity to the CA in some manner; this process is called enrollment . The CA next creates an X.509 digital certificate containing identifying information and a copy of the public key. The CA then digitally signs the certificate using the CA’s private key and provides a copy of the signed digital certificate. Verification : A digital certificate is verified by checking the CA's digital signature using CA's public key. Next, check and ensure that the certificate was not published on a certificate revocation list (CRL). Revocation : A CA revoke a certificate for one of the following reasons :

• The certificate was compromised (for example, the certificate owner accidentally gave away the private key).
• The certificate was erroneously issued (for example, the CA mistakenly issued a certificate without proper verification).
• The details of the certificate changed (for example, the subject’s name changed).
• The security association changed (for example, the subject is no longer employed by the organization sponsoring the certificate).

There are two techniques to verify the authenticity of certifi cates and identify revoked certificates :

• Certificate Revocation Lists (CRL) are maintained by the various certificate authorities and contain the serial numbers of certificates that have been issued by a CA and have been revoked along with the date and time the revocation went into effect.
• Online Certificate Status Protocol (OCSP) This protocol eliminates the latency inherent in the use of certificate revocation lists by providing a means for real-time certificate verification. When a client receives a certificate, it sends an OCSP request to the CA’s OCSP server. The server then responds with a status of valid, invalid, or unknown.

Asymmetric Key Management

A few things to consider while working with PKI :

• Choose an encryption system with an algorithm in the public domain that has been thoroughly vetted by industry experts.
• Use a key length that balances security requirements with performance considerations.
• Do not, under any circumstances, allow anyone else to gain access to one's private key.
• Retire keys when they’ve served a useful life.
• Create a private key backup or use a key escrow service.

Applied Cryptography

Portable Devices

Examples of Disk Encryption Softwares/Packages: BitLocker, Encrypting File System (EFS), FileVault encryption, and TrueCrypt. The major differentiators between these tools are how they protect keys stored in memory, whether they provide full disk or volume-only encryption, and whether they integrate with hardware-based Trusted Platform Modules (TPMs) to provide added security.

Email

Pretty Good Privacy (PGP) : It combines the CA hierarchy with the “web of trust” concept—that is, you must become trusted by one or more PGP users to begin using the system. Available in two versions. The commercial version uses RSA for key exchange, IDEA for encryption/decryption, and MD5 for message digest production. The freeware version (based on the extremely similar OpenPGP standard) uses Diffie-Hellman key exchange, the Carlisle Adams/Stafford Tavares (CAST) 128-bit encryption/decryption algorithm, and the SHA-1 hashing function. Secure Multipurpose Internet Mail Extensions (S/MIME) : It uses the RSA encryption algorithm and relies on the use of X.509 certificates for exchanging cryptographic keys.

Web Applications

SSL - Developed by Netscape to provide client/server encryption for web traffic. Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) uses port 443 to negotiate encrypted communications sessions between web servers and browser clients. The following steps are involved :

1. When a user accesses a website, the browser retrieves the web server’s certificate and extracts the server’s public key from it.
2. The browser then creates a random symmetric key, uses the server’s public key to encrypt it, and then sends the encrypted symmetric key to the server.
3. The server then decrypts the symmetric key using its own private key, and the two systems exchange all future messages using the symmetric encryption key.

Based on SSL technology, Transport Layer Security (TLS) incorporated many security enhancements and was eventually adopted as a replacement for SSL in most applications.

Steganography and Watermarking

Steganography is the art of using cryptographic techniques to embed secret messages within another message. Adding digital watermarks to documents to protect intellectual property is accomplished by means of steganography.

Digital Rights Management

Digital rights management (DRM) software uses encryption to enforce copyright restrictions on digital media. Two of the major technologies used to protect mass-distributed media are as follows

• Content Scrambling System (CSS) : Enforces playback and region restrictions on DVDs.
• Advanced Access Content System (AACS) Protects the content stored on Blu-Ray and HD DVD media.

Networking

Circuit Encryption

Link Encryption : Protects entire communications circuits by creating a secure tunnel between two points using either a hardware solution or a software solution that encrypts all traffic entering one end of the tunnel and decrypts all traffic entering the other end of the tunnel. End-to-End Encryption : Protects communications between two parties (for example, a client and a server) and is performed independently of link encryption. Internet Protocol Security (IPsec) : IPsec is a standard architecture set forth by the Internet Engineering Task Force (IETF) for setting up a secure channel to exchange information between two entities. It is commonly paired with the Layer 2 Tunneling Protocol (L2TP) as L2TP/IPsec. It relies on security associations, and there are two main components :

• The Authentication Header (AH) provides assurances of message integrity and nonrepudiation. AH also provides authentication and access control and prevents replay attacks.
• The Encapsulating Security Payload (ESP) provides confidentiality and integrity of packet contents. It provides encryption and limited authentication and prevents replay attacks.

IPsec provides for two discrete modes of operation. When it is used in transport mode, only the packet payload is encrypted. This mode is designed for peer-to-peer communication. When it’s used in tunnel mode , the entire packet, including the header, is encrypted. This mode is designed for gateway-to-gateway communication. At runtime, you set up an IPsec session by creating a security association (SA). The SA represents the communication session and records any configuration and status information about the connection. The SA represents a simplex connection. If you want a two-way channel, you need two SAs, one for each direction. Also, if you want to support a bidirectional channel using both AH and ESP, you will need to set up four SAs. Internet Security Association and Key Management Protocol (ISAKMP) : Provides background security support services for IPsec by negotiating, establishing, modifying, and deleting security associations. There are four basic requirements for ISAKMP :

• Authenticate communicating peers
• Create and manage security associations
• Provide key generation mechanisms
• Protect against threats (for example, replay and denial-of-service attacks)

Wireless Networking

Wired Equivalent Privacy (WEP) : Provides 64- and 128-bit encryption options to protect communications within the wireless LAN. WiFi Protected Access (WPA) : Improves on WEP encryption by implementing the Temporal Key Integrity Protocol (TKIP), eliminating the cryptographic weaknesses that undermined WEP.

--------------------------------------------------------------------------------------------------------------------------------------------------

Trust Relationship – nature and level of trust that exists between a set people, processes, systems and entities
Threat Model – a scenario or condition that presents a significant danger of impact, usually identified by conducting threat modeling exercises
(https://en.wikipedia.org/wiki/Threat_model)

In every enterprise network, no matter how large or small, organisations have third parties included in their trust model. Whether it’s the laptops, VPS provider, an outsourced HR SaaS application, or just a downloaded piece of software, every organisation has stacks and stacks of third-party components. Naturally, each of these components has its own unique trust relationship with the hosting organisation. Some vendors are implicitly trusted and deal with the most sensitive of business components, while others are kept at arm’s length and relegated to locked-down networks and other restrictive access. How we choose to interact with a third party—the access we give it, the faith we put in it—inevitably defines the nature of our trust relationship with that vendor or technology.

The specifics of a trust relationship ultimately dictate the threat model for the implementation as well as the larger enterprise. Security controls are often selected and designed to address a specific threat model.

However, using a poorly defined trust relationship as the basis of a threat model, or misunderstanding the threat model can result in significant difficulties, such as:

• Misallocated budgets
• Ineffective security controls
• Unexpected vulnerabilities / exposures
• False senses of security

We’re going to take a look at what happens when we deploy some common enterprise security software without understanding or defining both our trust relationships and threat models; we can actually not make a substantial improvement on our security posture. We’ll use the following three technologies as examples, but we aren’t picking on them, this could apply to any technology:

• Secret Vaults
• Advanced HIPS
• Security Tools

Secret Vaults

There is currently a push among application development teams to move secrets from source code or configuration files to a secrets-as-a-service model, where secrets are issued on request to micro-services or users given a specific security context or met condition. This approach is most commonly achieved by using a software secret store such as HashiCorp Vault.

Sounds great—we implement this and presto! We now have a secure environment without hard-coded secrets and better application performance! However, we didn't remove the secrets, we moved the secrets. So, now we need to consider the following:

• How is the technology or data accessed?
• Who accesses the technology or data?
• How is the technology or data protected while in use?
• How is the technology or data protected at rest?
• How is the technology or data managed?
• Where is the technology or data within the environment?
• Do any of the above invalidate internal or external policies (i.e. compliance)?

As we start answering these questions we can to build an actual picture of our trust relationships as they relate between users, admins, sensitive assets, third parties and secrets themselves.

Each question can be answered a variety of ways, and each solution bring with it a set of considerations and additional questions. The process of exploring these questions and answers is integral to a well-defined trust relationship and threat model. Let’s take a look at the first question: If the data is accessed by the micro-services by using a certificate, then how is the certificate protected? Once the secrets are retrieved what state are they in (i.e. encrypted or unencrypted)? Each answer will dictate the design considerations and controls necessary to secure the solution.

The end state is that in most common configurations the solution is not more secure, it just changes the threat model. If this vault is not protected by well-defined network access controls and does not have strictly enforced management policy, you have only shifted your threat model to compromise of a privileged user instead of compromise of source. Depending on the directory implementation that is backing your identity provider, it could be easier to achieve access as a privileged user, rather than access to source code. Regardless, it would provide access to all secrets in one place, rather than in separate components of code.

So, the threat model we are addressing here boils down to protecting against post-compromise access of sensitive data, which is the same issue as if the credentials were in source. However, we have narrowed the scope of attacker to “those administrative privileges.”

Advanced HIPS

In the past, "Enterprise AV" was king. (Well, not really, but it was all we had.)

Then new solutions emerged like Bit9, Cylance, CarbonBlack and many others. Security practitioners starting looking for new, more efficient approaches to stopping threats. They looked at learning based network inspection, math-based threat detection on end points, optimised log/activity data aggregation paired with Big-Data advanced search, and correlation features. All with the intent of stopping attackers, malware, and policy violating users. What becomes apparent is that because each solution works very differently with unique market differentiators, we yet again have to ask, “What threat model are we addressing with each solution?” When we do this, we need to go back to those questions above to really explore how we should implement and how effective the solution will be.

When asking our threat model evaluation questions like we did for secret vaults, we need to make sure we are looking at it in the context of HIPS. In the case of HIPS, each one of these questions leads to a question about the individual solutions’ capabilities. If when we ask the question, “Who is accessing the system?” and our answer is “Administrators,” a solution like Cylance or Bit9 loses a lot of effectiveness. This is because these solutions are easy to bypass as a super user and are primarily effective at stopping privilege escalation. This is another reason it is important to understand both the system being protected and the types of attacks we need to defend against.

The first take away for HIPS, in relation to trust relationships and threat models, is that you get far more mileage when they are used to address specific threat models by closing gaps left by other security technologies. When you apply principles of least privilege and use the HIPS specifically to mitigate a concerning threat model like "malicious user, with low privileges," you are able to better realise return on investment for that technology.

The second take away here is that user land based HIPS is not an effective mitigation against administrative level attackers. Controls that are independent of the realm of administration are far better suited to address these kinds of threats. An example of this is when security controls that run between the guest and host in a virtualised environment remove the super user’s ability to bypass them.

These two points can be tied to trust relationships as well. Looking at the long list of AV/HIPS providers that have had security vulnerabilities published, it begs the questions of how closely are we considering our investments in HIPS and how much trust are we actually investing in them?

Security Tools

Security tools have become ingrained into our day-to-day security operations. For a long time, tools were cropping up and being consumed so quickly and readily that it was not at all uncommon for organisations to have two or three security tools doing the same thing across multiple teams. The efficiency gains of a good security tool and the sheer number of potential options ensures that no matter where you go in security there will be a tool closely tied to your day-to-day function.

Security tools come in a variety of forms including, but not limited to:

• Compliance management tools
• Inventory solutions
• Security scanners
• DLP solutions
• Exploitation tools used by internal security teams

Security tools are perhaps the best object lesson for understanding the implications of third-party software use of trust relationships, because these tools are commonly:

• Deployed by a highly-privileged admin
• Configured by an admin or the intended operator
• Operated by an organisation user who has admin rights to the application
• Configured with credentials in order to achieve a highly-privileged action with a limited scope

This is most common with security scanners. Often a security scanner is set up on a system where an auditor, lower level admin, or other person is given access to the application UI as a global/top-level admin, but not given access to the underlying operating system. At some point if credentialed checks are used (they are required in many compliance standards), credentials will be entered into the UI. At this point the user’s working perception is that a set of privileged credentials can be entered into the security scanner, then that scanner can be used by an under privileged user and the credentials that were initially stored for authenticated scanning are not retrievable. When we look at the threat model, the actuality is that this may not be true. Depending on how the credentials are stored, if backups contain credentials then what kind of protections are actually securing the interface?

When we go beyond configuration, we start to see some other things emerge about security tools. They often don’t consider threat model or the tools’ actual common use in the design. Other times, the security tool is basically a black box, and once you dig in you start to see a litany of weird behaviors and unsafe configurations hard-coded into the operation of the software. What further compounds the issue, is that these tools are inherently trusted because of their function and service they’re providing.

Coming Full Circle

This brings us full circle to trust relationship. If a threat model or problem statement dictates how to effectively use security tools, then the threat model and attack surface of the actual tool, as well as the transparency of its design, is the dictator of defining the trust relationship constraints around that tool or solution.

In summary, understanding how something is or can be attacked, knowing what a specific solution does, and recognising the potential risk and operation of a solution in day-to-day operations can enhance efficiency in operations, security, and budget.

----------------------------------------------------------------------------------------------------------------------------------------------

What is Password Cracking?

Password cracking is the process of attempting to gain Unauthorized access to restricted systems using common passwords or algorithms that guess passwords. In other words, it’s an art of obtaining the correct password that gives access to a system protected by an authentication method.

Password cracking employs a number of techniques to achieve its goals. The cracking process can involve either comparing stored passwords against word list or use algorithms to generate passwords that match

What is password strength?

Password strength is the measure of a password’s efficiency to resist password cracking attacks. The strength of a password is determined by;

• Length: the number of characters the password contains.
• Complexity: does it use a combination of letters, numbers, and symbol
• Unpredictability: is it something that can be guessed easily by an attacker

Password cracking techniques

There are a number of techniques that can be used to crack passwords. We will describe the most commonly used ones below;

• Dictionary attack– This method involves the use of a wordlist to compare against user passwords.
• Brute force attack– This method is similar to the dictionary attack. Brute force attacks use algorithms that combine alpha-numeric characters and symbols to come up with passwords for the attack. For example, a password of the value “password” can also be tried as p@$$word using the brute force attack.
• Rainbow table attack– This method uses pre-computed hashes. Let’s assume that we have a database which stores passwords as md5 hashes. We can create another database that has md5 hashes of commonly used passwords. We can then compare the password hash we have against the stored hashes in the database. If a match is found, then we have the password.
• Guess– As the name suggests, this method involves guessing. Passwords such as qwerty, password, admin, etc. are commonly used or set as default passwords. If they have not been changed or if the user is careless when selecting passwords, then they can be easily compromised.
• Spidering– Most organizations use passwords that contain company information. This information can be found on company websites, social media such as facebook, twitter, etc. Spidering gathers information from these sources to come up with word lists. The word list is then used to perform dictionary and brute force attacks.

-------------------------------------------------------------------------------------------------------------------------------------------------

Cryptographic protocol

A security protocol (cryptographic protocol or encryption protocol) is an abstract or concrete protocol that performs a security-related function and applies cryptographic methods, often as sequences of cryptographic primitives. A protocol describes how the algorithms should be used. A sufficiently detailed protocol includes details about data structures and representations, at which point it can be used to implement multiple, interoperable versions of a program.

Cryptographic protocols are widely used for secure application-level data transport. A cryptographic protocol usually incorporates at least some of these aspects:

• Key agreement or establishment
• Entity authentication
• Symmetric encryption and message authentication material construction
• Secured application-level data transport
• Non-repudiation methods
• Secret sharing methods
• Secure multi-party computation

For example, Transport Layer Security (TLS) is a cryptographic protocol that is used to secure web (HTTPS) connections. It has an entity authentication mechanism, based on the X.509 system; a key setup phase, where a symmetric encryption key is formed by employing public-key cryptography; and an application-level data transport function. These three aspects have important interconnections. Standard TLS does not have non-repudiation support.

There are other types of cryptographic protocols as well, and even the term itself has various readings; Cryptographic application protocols often use one or more underlying key agreement methods, which are also sometimes themselves referred to as "cryptographic protocols". For instance, TLS employs what is known as the Diffie–Hellman key exchange, which although it is only a part of TLS per se, Diffie–Hellman may be seen as a complete cryptographic protocol in itself for other applications.

Advanced cryptographic protocols

A wide variety of cryptographic protocols go beyond the traditional goals of data confidentiality, integrity, and authentication to also secure a variety of other desired characteristics of computer-mediated collaboration.^[2] Blind signatures can be used for digital cash and digital credentials to prove that a person holds an attribute or right without revealing that person's identity or the identities of parties that person transacted with. Secure digital timestamping can be used to prove that data (even if confidential) existed at a certain time. Secure multiparty computation can be used to compute answers (such as determining the highest bid in an auction) based on confidential data (such as private bids), so that when the protocol is complete the participants know only their own input and the answer. End-to-end auditable voting systems provide sets of desirable privacy and auditability properties for conducting e-voting. Undeniable signatures include interactive protocols that allow the signer to prove a forgery and limit who can verify the signature. Deniable encryption augments standard encryption by making it impossible for an attacker to mathematically prove the existence of a plain text message. Digital mixes create hard-to-trace communications.

--------------------------------------------------------------------------------------------------------------------------------------------

Different Types Of Cryptographic Attacks

Brute Force Attack

Brute-force attacks are quite straightforward. Such an attack attempts every possible valid combination for a key or password. They involve using massive amounts of processing power to methodically guess the key used to secure cryptographic communications.

The average amount of time required to discover the key through a brute-force attack is directly proportional to the length of the key.

A brute-force attack will always be successful if given enough time. Every additional bit of key length doubles the time to perform a brute-force attack because the number of potential keys
doubles.

Replay Attack

The replay attack is used against cryptographic algorithms that do not incorporate temporal protections. In this attack, the malicious individual intercepts an encrypted message between two parties (often a request for authentication) and then later “replays” the captured message to open a new session. This attack can be defeated by incorporating a time stamp and expiration period into each message.

Man in the Middle Attack

In the man-in-the-middle attack, a malicious individual sits between two communicating parties and intercepts all communications (including the setup of the cryptographic session). The attacker responds to the originator’s initialization requests and sets up a secure session with the originator. The attacker then establishes a second secure session with the intended recipient using a different key and posing as the originator. The attacker can then “sit in the middle” of the communication and read all traffic as it passes between the two parties.

Implementation Attack

This is a type of attack that exploits weaknesses in the implementation of a cryptography system. It focuses on exploiting the software code, not just errors and flaws but the logic implementation to work the encryption system.

Statistical Attack

A statistical attack exploits statistical weaknesses in a cryptosystem, such as floating-point errors and inability to produce truly random numbers.

Statistical attacks attempt to find a vulnerability in the hardware or operating system hosting the cryptography application.

Frequency Analysis and the Ciphertext Only Attack

In many cases, the only information you have at your disposal is the encrypted ciphertext message, a scenario known as the ciphertext only attack. In this case, one technique that proves helpful against simple ciphers is frequency analysis—counting the number of times each letter appears in the ciphertext.

Using your knowledge that the letters E, T, O, A, I, and N are the most common in the English language, you can then test several hypotheses:

-If these letters are also the most common in the ciphertext, the cipher was likely a transposition cipher, which rearranged the characters of the plain text without altering them.

-If other letters are the most common in the ciphertext, the cipher is probably some form of substitution cipher that replaced the plaintext characters.

This is a simple overview of frequency analysis, and many sophisticated variations on this technique can be used against polyalphabetic ciphers and other sophisticated cryptosystems.

Known Plaintext

In the known plaintext attack, the attacker has a copy of the encrypted message along with the plaintext message used to generate the ciphertext . This knowledge greatly assists the attacker in breaking weaker codes.

For example, imagine the ease with which you could break the Caesar cipher if you had both a plaintext copy and a ciphertext copy of the same message.