Archive

Author Archive

Stream cipher weaknesses

From: http://en.citizendium.org/wiki/Stream_cipher
Reusing pseudorandom material

There is one essential usage restriction: never encrypt two different messages with the same pseudorandom data, or even the same truly random data.

Using P for plaintext, C for ciphertext, R for (pseudo)random, and for XOR this makes the encryptions:

C1 = (P1)XOR(R)
C2 = (P2)XOR(R)
The enemy can intercept both ciphertexts, so he does:

X = (C1)XOR(C2) = (P1)XOR(R)XOR(P2)XOR(R)
and the Rs cancel out!

This is extremely good for the attacker who now has:

X = (P1)XOR(P2)
This is very weak indeed. Because the Rs cancel out, the attacker gets the same result no matter what R is used, so the encryption no longer has any real effect and the quality of the random numbers becomes irrelevant.

From that point on, the attacker need not worry about the encryption, only about properties of the plaintexts. If he knows or can guess part of either plaintext, he can immediately infer the corresponding part of the other. A zero byte in X means the corresponding bytes in P1 and P2 are equal. Other simple relations exist and can readily be exploited. He can also play a sort of ping-pong; make some inferences or guesses about one text, see what that tells him about the other, make some inferences there, see what that tells him about the first text, and so on.

Given moderately strong knowledge of plaintext properties — for example, that it is English or Russian text — P1P2 can be broken using techniques such as frequency counting that have been well-known for centuries and can be done with pencil and paper; you don’t even need a computer. See History of cryptography for details. Even with weaker knowledge of the input format, it is still easily breakable.

Of course in a real application, such as the NSA and British attack on Soviet one-time pads called VENONA, the attack may be far more difficult. Suppose you have a substantial archive of intercepted messages and you know or suspect that the enemy sometimes reuses the random material, There is still a huge amount of work to do to discover what was reused where.

On the other hand, the attack might be easy. In some versions of Word and Excel, Microsoft mis-used RC4 [6]; when multiple versions of an encrypted file were saved, the same pseudorandom stream was used each time. In this case the attacker has more to go on since he knows the texts are multiple versions of the same document. Also, there may be more than two versions.

Microsoft also mis-used RC4 in their first version of PPTP, the point-to-point tunneling protocol used to implement VPNs [7]. They used the same key for encryption in both directions on a connection; the attacker can just XOR the two message streams together. This was fixed in their next version of the protocol.

There is a rather nice graphical illustration of this attack at Cryptosmith.

Rewrite attacks

Stream ciphers (including one-time pads) are inherently vulnerable to a rewrite attack. If an attacker knows some plaintext and has intercepted the matching ciphertext, then he can discover that portion of the pseudorandom data. This does not matter if the attacker is just a passive eavesdropper. It gives him no plaintext he didn’t already know and we don’t care that he learns some pseudorandom data. We will never re-use that data, for reasons given in the previous section. For a one-time pad, having a portion of the truly random key tells him absolutely nothing about the rest of the key. For a stream cipher, having some of pseudorandom generator’s output does not allow an attack if the generator is well designed.

However, an active attacker who knows the plaintext can recover the pseudorandom data, then use it to encode whatever he chooses. If he can get his version delivered instead of yours, this is a disaster. If you send “attack target 372 at dawn”, the delivered message can be anything the same length; perhaps the enemy would prefer “withdraw East immediately”. An active attacker with only a reasonable guess at the plaintext can try the same attack. If the guess is correct, this works and the attacker’s bogus message is delivered. If the guess is wrong, a garbled message is delivered.

The attack fails if an effective cryptographic authentication mechanism is used at either packet or message level. That mechanism detects the bogus message and either discards it or warns the user. Note, however, that while authenticating the players at channel setup time is a required step to prevent man-in-the-middle attacks, it does not prevent this attack. To stop rewrite attacks, you need authentication later on, at packet or message level.

Even ignoring whatever authentication is used, this attack is generally not practical against high-speed systems with a good synchronisation mechanism, such as military systems or network encryption boxes. Performing the attack in real time — fast enough to get a bogus message delivered without losing synchronisation — would be very difficult. Systems such as TLS that use a stream cipher for a slower and less synchronised connection are more vulnerable; they definitely need authentication. Systems such as Microsoft Word encryption which apply stream ciphers to static data are even more vulnerable.

Advertisements

WEP Protocol architecture

Copied from: http://www.ouah.org/wirelessvuln.htm

802.11 defines an optional WEP mechanism to provide confidentiality and integrity of traffic in the WLAN. WEP is used at the two lowest layers of the Open Systems Interconnect (OSI) reference model, data link and physical layers; thereby, it does not offer end-to-end security. WEP depends on a secret key shared between the communicating parties (mobile station and AP) to protect the payload of a transmitted frame in each direction. Moreover, the RC4 PRNG algorithm used by WEP includes an integrity check vector (ICV) to check the integrity of each packet. This process is summarized below.

First, WEP computes the ICV by performing a 32-bit cyclical redundancy check (CRC-32) of the frame and appends the vector to the original frame, resulting in the plaintext. Then, the message plus ICV is encrypted via the RC4 PRNG algorithm using a long sequence key stream – a long sequence of pseudorandom bits. This key stream is a function of the 40-bit secret key (which is shared between all authorized stations in the WLAN) and a 24-bit initialization vector (IV). Consequently, an exclusive-or (XOR) operation is made between the plaintext and the key stream to produce the ciphertext. Finally, it is the ciphertext that is sent over the radio link. Theoretically, the ciphertext provides data integrity because of the ICV and confidentiality due to encryption.

The receiver, inasmuch as RC4 PRNG algorithm is symmetric, performs the same procedure described above, but in reverse, to retrieve the original message frame. Specifically, the ciphertext is decrypted using a duplicated key stream to recover the plaintext. The recipient then validates the checksum on this plaintext by computing the ICV and comparing it to the last 32 bits of the plaintext, thus ensuring that only frames with a valid checksum will be accepted by the receiver.

WEP can be implemented with the classic 40-bit key and 24-bit IV or a vendor-dependent (hence proprietary) extended version that affords a larger key. The shorter key length can be relatively easy to compromise via brute-force attack, even with modest computing resources; however, a larger key such as the 128-bit keys would be render brute-force attacks impossible, even for sophisticated computing systems. Nevertheless, alternative attacks are possible that do not require a brute-force strategy, thereby diminishing the strength of key length.

Categories: Uncategorized Tags: , , ,

Rootkit in Network Card firmware

Wow…  this is just amazing how you can compromise and entire network, just by messing around with the firmware of one network card.

See the link:

http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf

Which Programming Language?

May 15, 2010 1 comment

Copied from a number of different blogs … so i have no idea where they found it … but anyhow it’s funny/interesting/quite true …

In response to the question “Which programming language should I learn first?” – one user responds:

Depends.

To program in an expressive and powerful language: Python
To get a website up quickly: PHP
To mingle with programmers who call themselves “rockstars”: Ruby.
To really learn to program: C.
To achieve enlightenment: Scheme.
To feel depressed: SQL
To drop a chromosome: Microsoft Visual Basic
To get a guaranteed, mediocre, but well paying job writing financial applications in a cubicle under fluorescent lights: Java.
To do the same thing with certifications and letters after your name: C#
To achieve a magical sense of childlike wonder that you have a hard time differentiating from megalomania: Objective C

Categories: Uncategorized Tags: , , , ,

The Top 2 Rules of Security

Rule #2 : “Moving targets are harder to hit.

If it’s in motion, getting it dead on is difficult.

Rule #1 : “Camouflage is the best defence.

If it can’t see you, it can’t hit you.

~Stewart Kowalski

Categories: Uncategorized

Confidentiality without Integrity & Vice versa [re-phrased]

October 18, 2009 1 comment

Can a system provide Confidentiality without needing to provide integrity as a precursor?
Can a system provide Integrity, without having to deal with confidentiality first?

I came across this interesting piece by Nicholas Allen. I hadn’t though it was possible because i couldn’t come up with a clear example. However, he seems to somehow bring the idea home,thus i have copied this from his blog (http://blogs.msdn.com/drnick) verbatim and added a little “meat” to it to make it slightly more clear:

Confidentiality. Confidentiality means that the contents of the message are kept secret from unintended listeners. An unintended listener is typically going to be someone that is trying to eavesdrop on your messages, although it’s possible for the unintended listener to come from logging or other normal network monitoring. Confidentiality protects you from spying.

Integrity. Message integrity means that you have confidence that the message you received is the same as the one that the sender sent.

It’s possible to have confidentiality without integrity. Someone can hand you an encrypted message, and you can start changing bits in the message without knowing what those bits mean. Thus, the message could still remain confidential [as it is encrypted], but it has lost it’s integrity as the message has been tampered with.

Similarly, it’s possible to have integrity without confidentiality. You can transmit a message whose contents are in cleartext, but provide a tamper-resistant envelope for the message. Thus, the confidentiality of the message is non-existent [it is cleartext], but it cannot be tampered with [or traces of tampering shall be evident].

Practically speaking, i would say the 2 above scenarios are possible, but in the first case [Confidentiality, without integrity], the system is probably not meeting it’s requirements.

If you have further examples, ideas or comments, feel free to add them here.

Categories: Uncategorized

Confidentiality without Integrity & Vice versa

October 18, 2009 Leave a comment

I came across this interesting piece by Nicholas Allen. I hadn’t though it was possible because i couldn’t come up with an example…but he seems to put it quite simply, thus i have copied this from his blog (http://blogs.msdn.com/drnick) verbatim:

“I’ve gotten several questions about how transport security works. I’m putting together a list of transport security topics to talk about over the next few months to cover this topic. Before getting to that list though, I thought I’d talk a little bit about what transport security does.

Transport security protects the transfer of a message. Security is provided on a point-to-point basis. The lifetime of the security session ends when the message arrives at an endpoint. If a message goes through multiple hops to reach its destination, the message needs to be resecured for each hop. This is different than message security, which can be used to provide end-to-end security regardless of the number of hops you’re going through. No matter what method you use though, security is providing any of the following three things.

Confidentiality. Confidentiality means that the contents of the message are kept secret from unintended listeners. An unintended listener is typically going to be someone that is trying to eavesdrop on your messages, although it’s possible for the unintended listener to come from logging or other normal network monitoring. Confidentiality protects you from spying.

Integrity. Message integrity means that you have confidence that the message you received is the same as the one that the sender sent. It’s possible to have confidentiality without integrity. Someone can hand you an encrypted message, and you can start changing bits in the message without knowing what those bits mean. Similarly, it’s possible to have integrity without confidentiality. You can transmit a message whose contents are clear, but provide a tamper-resistant envelope for the message. Any attempt to change the message will result in evidence of tampering.

Authentication. Authentication means that you have confidence that you know the identity of the other party in the communication. Confidentiality and integrity are not very useful unless the message is authentic. You can have a message that was kept secret and was not tampered with, but the author of the message is not who you thought it was. Authentication can be for the client, server, or mutually for both parties of the conversation.

Here’s the list of topics I’m thinking about so far:

  • Basics of Encryption and Hashing
  • Security Key Management
  • Basics of Security Certificates
  • How Stream Ciphers Work
  • How Block Ciphers Work
  • How RSA Works
  • How Diffie-Hellman Key Exchange Works

Categories: Uncategorized