MD5 , SHA1 y demás tiliches... para contadores

La adopción de la factura electrónica en México trae aparejados términos que hasta algunos informáticos no entienden todavía.

En este blog pretendo explicar, sobre todo a contadores públicos, lo que significan estos términos para que no parezcan tan intimidantes.

Un Comprobante Fiscal Digital ( por sus siglas cfd ) es la famosa factura electrónica , aunque engloba otros comprobantes como nota de crédito.

Ahora bien por qué es electrónica ?

Dónde están los electrones de la factura ?

En ninguna parte. Solo es un nombre rimbombante para UNA FACTURA CUYO DESTINO PRINCIPAL ES UN ARCHIVO DE COMPUTADORA CON EXTENSION XML. Existe además del archivo xml una representación gráfica o para que un ser humano la pueda usar ( usualmente en pdf ). Allí a diferencia de la factura que hasta hoy se ha conocido existen elementos nuevos como la cadena original, el sello digital, número de aprobación y la fecha que ahora incluye la hora de la emisión de la factura.

Ok. Factura o CFD es primordialmente un archivo con extensión xml. ¿ qué más?

Un archivo xml contiene información estructurada que puede ser leida por programas de cómputo ( entre ellos los del SAT ). El famoso anexo 20 cuya última encarnación fue de septiembre del 2010 nos define las reglas de como debe formarse dicho archivo xml.

Los que nos dedicamos a la "programada" intentamos descifrar el acertijo que significa dicho anexo 20 que trae términos tipo guerra de las galaxias como :

MD5 , SHA1 , RSA, ENCODE base 64, Cadena Original.

Algunos informáticos conocen estas cosas que se relacionan con seguridad primordialmente y otros no tanto.

Si tuviera que explicar a un informático con cierto conocimiento en estos términos un cfd sería:

El "encode base64" del resultado de aplicar encriptación rsa mediante llave privada ( proveniente del archivo punto key del certificado de sello digital más la contraseña asociada, o bien de un archivo punto pem equivalente) a la cadena original previamente convertida a algo más breve mediante el algoritmo "hash" md5 ( y a partir del año entrante el algoritmo sha1 ).

Híjole parece simple por la cantidad de palabras y el acomodo mas no por lo que significa. ¿ Cierto?

Vayamos al origen del proceso o generación de un cfd.

1 - Cadena Original. El anexo 20 define reglas para presentar de cierta manera información forzosa y opcional con estructuración y que le llama "Cadena Original". Esa la van a ver mostrada en la representación gráfica ( impresa o visual ) de una factura.

2 - Todo el concepto de factura parte de la cadena original. Como la cadena incluye información que la hace "distinta a sus facturas hermanas" como folio y fecha/hora, en teoría DOS CADENAS NO DEBERIAN SER IGUALES.

3 - El MD5 -o a partir del año que entra- SHA1, son "algoritmos de digestión" ( nada que ver con dolores de estómago aunque por las premuras de la adopción del cfd antes del 2011 puede que si ). Son por asi decirlo fórmulas para producir un conjunto de caracteres de cierta longitud ( breve ) a partir de un contenido normalmente de mayor longitud como en este caso la cadena original. El uso de estos algoritmos de digestión es de usos múltiples en la industria informática. En nuestro caso es "reducir el contenido de la cadena original a una representación más corta".

4 - Por qué entonces SAT decidió que a partir del 2011 se empleará el algoritmo SHA1 en vez de MD5 ? Cómo ha sucedido en muchas cosas que nos sucede en México... por culpa de los chinos jeje. Y no es broma. Hace no mucho tiempo se convocó a un concurso para hacer que dos contenidos distintos produjeran el mismo contenido "reducido" o de digestión "a la MD5" y el concurso a las pocas semanas de ser lanzado lo ganaron un grupo de Chinos. Comencé con ello la caída de la reputación del MD5 en cuanto a la confiabilidad. Conste que hasta aquí no he hablado de seguridad. El MD5 o el SHA1 no confieren seguridad, simplemente producen un valor digestivo ("hash"). Ante la hazaña de los orientales y seguramente preocupados por eso la gente del SAT decidió brincar al siguiente "algoritmo" de digestión supuestamente no violado aún ( al menos en términos de dos fuentes produciendo el mismo valor de digestión ) y que se llama SHA1. Por algunas cosas que se han venido suscitando recientemente en el terreno de supercomputación al alcance de cualquiera via proveedores de nube, casi puedo preveer que para el 2012 habrán de forzarnos a cambiar del SHA1 a otro de mayor "fortaleza" por asi decirlo. Pero bueno el cambio que viene es de un algoritmo por otro. Lo demás queda intacto y que es lo demás ?

5 - Ok hasta aqui ya tenemos el valor reducido de la cadena original en forma "digestiva" ( hash ). Lo que sigue es firmar o cifrar o encriptar ( como decimos equivocadamente en México ) el digestivo con el algoritmo RSA, para lo cual sirve el famoso archivo .key que se genera en el trámite de certificado de sello digital. Algunos programas ( como el mío -lease comercial barato ) utilizan una forma convertida del archivo punto key en otro de tipo punto PEM para no estar preguntando por la contraseña asociada al punto key cada vez que se genera una factura.

6 - Bueno el caso es que habiendo "encriptado a la mexicana" o "cifrado a la española" el valor digestivo de la cadena original el resultado es una serie de garabatos que es inapropiada para ser incluida en el famoso archivo XML del que hablabamos en el principio. Por lo que el último paso es convertir estos garabatos en algo textual mediante la codificación ( asi se llama ) usando base 64. Como lo que esto produce es algo legible entonces es susceptible de ser incluido en el famoso XM y es lo que finlamente es el sello digital.



Ya sé que ha sido densa la explicación y con toda confianza hagan las preguntas que quieran por este medio o via twitter en #cfdmx que más de alguno podremos auxiliarlos. Mi twitter es @jdaguilera

Gracias por su tiempo.
Que en SHA1 se escribe...

'5c1102b6aa12cb16701f5a131ebdfdb71219a436'

Prueba

Esto es prueba en python

from couchdb.schema import Document, View, IntegerField, TextField
from couchdb import Database

map_fun = """
function(doc){
        emit(doc.name, doc.age);
}
"""
class Person(Document):
        name = TextField()
        age = IntegerField()
        by_name = View('people', map_fun)

db = Database("http://127.0.0.1:5984/borrame")

# to make a view permanent do this
from couchdb.design import ViewDefinition
ViewDefinition.sync_many(db, [Person.by_name])

Person(name = "batok", age = 48).store(db)
Person(name = "rgalvan", age = 47).store(db)
Person(name = "robert", age = 30).store(db)

for person in Person.by_name( db, limit = 3):
        print person.name, person.age

y esto es en ruby

require 'rubygems'
require 'ramaze'

# A very simple little application, you can simply run it and
# point your browser to http://localhost:7000
# you can change the port by setting
# Global.port = 80
# this most likely requires root-privileges though.

# This example shows following (requests to the mentioned base-url) :
# - simple text-output from the controller    [ / ]
# - showing you what your request looked like [ /simple ]
# - joining two strings                       [ /join/string1/string2 ]
# - join arbitary strings                     [ /join_all/string1/string2/string3 ... ]
# - sum two numbers                           [ /sum/1/3 ]
# - show if you made a POST or GET request    [ /post_or_get ]
# - How to map your controllers to urls       [ /other ]
# - Also try out the error-page, just pass something odd ;)

class SimpleController < Ramaze::Controller
  map '/'

  def index
    "simple"
  end

  def simple
    request.inspect
  end

  def join(first, second)
    [first, second].join
  end

  def join_all *strings
    strings.join
  end

  def sum first, second
    first.to_i + second.to_i
  end

  def post_or_get
    request.request_method
  end
end

class OtherController < Ramaze::Controller
  map '/other'

  def index
    "Hello, World from #{self.class.name}"
  end
end