ValidaCFD

Pues lo veo y no lo creo.

Todo empezo con esta entrada en el blog de Ricky*.

En resumen comentaba sobre la validacion y las firmas que se generan. El menciona que si un documento es firmado con las librerias OpenSSL el sello NO ES IGUAL a que si se firma con Java......

Mmmmh, no puede ser, pensaba yo y me vino a la mente lo que habia leido sobre el MD5 (lo cual es un paso intermedio para generar el sello).

Resulta que es MUY POCO probable que dos cadenas originales produzcan el mismo MD5, eso es del orden de 1 en un billon. Es mas, grandes estudiosos de criptografia buscan precisamente eso, dos cadenas originales que produzcan el mismo MD5, una vez que lo encuentren el digestivo MD5 quedara obsoleto.

A eso le llaman "colision", dos cadenas que generan el mismo MD5.

Es por ello que yo creia que no era posible que una misma cadena generara dos sellos distintos, asi que me di a la tarea de investigar, y encontre que si es posible.

Anexo dos archivos EXACTAMENTE iguales excepto por el sello, uno esta firmado con JAVA y el otro con OpenSSL y lo mas increible es que los dos validan bien aun cuando el sello es distinto.

NOTA : Esta entrada es solo un "ejercicio tecnologico", para el dia con dia no es necesario saber si es JAVA, o si es OpenSSL, lo importante es que los validadores puedan reconocer los dos tipos de sellos.

......y por cierto, el ValidaCFD, si reconoce los dos..........

Gracias Ricky, siempre se aprende algo nuevo.

*actualizacion, el "blog de ricky" ya no es tal, ahora se convirtio en un sitio comercial que ofrece soluciones para factura electronica.

hola de nuevo, oye probe los dos xml con el validador del sat, y el que dice firmado por java me da un mensaje que dice que el sello no pudo ser validado. en cuanto al otro con openssl todo bien. Como es que creas el sello en java?

vivi escribió:hola de nuevo, oye probe los dos xml con el validador del sat, y el que dice firmado por java me da un mensaje que dice que el sello no pudo ser validado. en cuanto al otro con openssl todo bien. Como es que creas el sello en java?

Use el Micro-e del SAT para crear la factura inicial, despues tome esa factura y lo re-selle con mis rutinas de OpenSSL.

El Micro-e esta escrito 100% en Java, ahora no conozco Java pero una persona comento en otro mensaje que "revisando el codigo fuente del Micro-e encontre esto..." se referia a otro asunto pero lo que quiero entender es que se puede "husmear" en la instalacion del Micro-e y descubrir su codigo fuente no?

Dado, te agradeceria me pases la fuente donde dice que un mismo mensaje puede dar dos (o más) MD5 distintos.

Estuve leyendo la fuente "original" donde explica el algoritmo MD5 (http://www.ietf.org/rfc/rfc1321.txt) y nomás no veo cómo el mismo elemento pueda dar dos "digestivos" diferentes.

Incluso podria atreverme a decir que un algoritmo así sería muy poco confiable, totalmente inutil para "certificar".

Saludos

ironman escribió:Dado, te agradeceria me pases la fuente donde dice que un mismo mensaje puede dar dos (o más) MD5 distintos.

Estuve leyendo la fuente "original" donde explica el algoritmo MD5 (http://www.ietf.org/rfc/rfc1321.txt) y nomás no veo cómo el mismo elemento pueda dar dos "digestivos" diferentes.

Incluso podria atreverme a decir que un algoritmo así sería muy poco confiable, totalmente inutil para "certificar".

Saludos

Je je, no, es alrevez.

Encontraron dos mensajes distintos que producen el mismo MD5. Deja busco incluso un ejemplo de lo dicho, dos "textos" totalmente distintos que arrojan el mismo digest MD5....no prometo encontrarlo pronto....gracias a Dios tengo mucho trabajo (aunque creo que a Dios se le paso la mano un poquito.....je je je)

Fue esta singularidad casi imposible (dos textos, un solo MD5) que por eso pense que no podia existir dos sellos para una misma cadena, pero parece que si.

Si ya decía yo....lo que sucedió es que en tu post mencionas lo siguiente:

Es por ello que yo creia que no era posible que una misma cadena generara dos sellos distintos, asi que me di a la tarea de investigar, y encontre que si es posible

Repito: UNA misma cadena genera DOS sellos distintos

Una situación de estas sería caótica y completamente inutil para firmas digitales.

Lo que si encontraron fue que: DOS cadenas distintas generen UN solo sello.

Fue esta singularidad casi imposible (dos textos, un solo MD5) que por eso pense que no podia existir dos sellos para una misma cadena, pero parece que si

Aclarando, el MD5 es el SELLO. Entonces si lo entendiste bien, pero lo escribiste al revés... dos textos, un solo MD5.... dos cadenas, un solo sello.

En eso si estoy de acuerdo. Tambien es por eso que a partir del 1o de enero de 2011, El SAT cambia el algoritmo de MD5 a SHA-1, que es "más fuerte" en este sentido.

Una vez aclarado el punto, mi mente descansa tranquila...

DADO escribió:...Fue esta singularidad casi imposible (dos textos, un solo MD5) que por eso pense que no podia existir dos sellos para una misma cadena, pero parece que si.

Post antiguo, pero espero que mi anecdota les sirva de algo.

Mi proveedor/programador de CFD por medios propios elaboro un conector el cual esta en Java.
Cuando nos entrego dicho conector. Antes de aceptar "terminada" la entrega (faltan las adendas) valide el CFD/XML... y sopas! "sello invalido".
Total, para no hacerles cansada la anecdota el programador estaba haciendo esto:
1) Lee datos de ERP
2) crea cadena original
3) genera el sello con cadena original ( ej. sello(varcadena) ; )
4) guarda el XML en UTF-8
¿notan el problema? .... ¿no?
Esto es lo que yo le pedia a ese programador que hiciera pues nomas no veia el porque fallaba el sello:
1) Lee datos de ERP
2) crea cadena original
3) genera el sello con cadena original UTF-8 ( por ej. sello (varcadena.getbytes("UTF8")) ; )
4) guarda el XML en UTF-8

Resultado:
Validacion del SAT sin problemas sello vs md5 de cadena original correcto.
Esto quiere decir que la "misma" cadena original si puede generar diferentes sellos (hasta mas de dos sellos, si usan diferente encoding).

El problema fue que el programador estaba usando la cadena original pero sin convertir dicha cadena a UTF-8. Pase casi 2 semanas esperando que el programador aceptara mi sugerencia, cuando por fin la acepto, el resultado fue correcto... ahora mi duda ellos dicen que con otros clientes no tienen problemas... ¿sera? ¿acaso los pobres clientes tuvieron el cuidado de validar sus CFD que este proveedor les ha creado?... para nada! casi puedo apostar que varios clientes de este conector/proveedor van a recibir sus multitas el proximo año. Por mi parte lograron meterme un gol con el tamaño del campo fecha (max 19 caracteres) me estan grabando los milisengundos dando un total de 23 caracteres.

Saludos!

Hola, que raro que no se dieran cuenta al desarrollar la aplicacion que no validara correctamente, el problema descrito es basico ya que el anexo20 es muy claro en el estandar de fecha/hora y en la codificacion UTF8 (que en lo particular lo obtenemos al precisamente al convertir la cadena original a un arreglo de bytes), ahora, segun yo no debe de validar correcto el xml si el formato de hora no es el correcto, te recomendaria usar el ValidaCFD de Dado para que cheques realmente si estan bien armados tus xml o no, ya que el del SAT es un porqueria....

Saludos.

s3cr3to escribió:Esto quiere decir que la "misma" cadena original si puede generar diferentes sellos (hasta mas de dos sellos, si usan diferente encoding).

Una misma cadena original NO puede generar diferentes sellos. En tu caso, la cadena original aunque es la "misma", en realidad no es la misma. Una cadena con encoding UTF-8 y "la misma cadena" con cualquier otro encoding, son tecnicamente (hablando ya de bits y bytes) dos cadenas diferentes, y por tanto, generan dos sellos diferentes.