A83: Re: MD5

[Prev][Next][Index][Thread]

A83: Re: MD5


>but hey, whatever works. If it is
>true, then what do you plan to do with this knowledge?

The fact that TI uses MD5 really slims our chances of falsifying a base code
.hex file, one must do 2^128 calculs to do so. On the other hand MD5 is
often used with RSA for certificates, thus the next step is to isolate the
large number routines...

>Btw, where are you going to find a z80 implementation of MD5 to borrow?  If
>you know, please let me know :)

Well I borrowed TI's implementation, I'll spare the detailed information
that I found tracing through all the code, but the code below gives you a
tracing start point, just activate Trace log on page 1Fh with the TI
simulator debugger to get the entire code.


The following code is an implementation of MD5 in Z80 code that uses
romcalls to TI's functions, it will generate MD5 hashes without fault, the
actual sample text should generate the fingerprint
d174ab98d277d9f5a5611c2c9f419d9f
as specified in RFC1321.

Solignac Julien
x1cygnus@xcalc.org
http://xcalc.org

Piracy is a victimless crime, like punching someone in the dark


/-- Begin Code
#Include "x1Cygnus.Inc"

 IN A, (06h)
 PUSH AF

 Invoke(_HomeUp)

 LD HL, PlotScreen
 LD BC, 0Ch * 3Eh
 Invoke(_MemClear)

 LD HL, Sample
 LD DE, PlotScreen
 LD BC, Size
 LDIR

 LD A, 80h
 LD (DE), A

 LD HL, Size
 LD BC, 0000h

PadCalc:
 LD DE, 512 / 8
 Invoke(_CPHLDE)
 JR C, SkipRed

 SBC HL, DE
 JR PadCalc
SkipRed:
 LD DE, 448 / 8
 Invoke(_CPHLDE)
 JR Z, QuitPadCalc

 INC HL
 INC BC
 JR PadCalc

QuitPadCalc:
 PUSH BC

 LD HL, PlotScreen + Size
 ADD HL, BC

 LD DE, Size
 XOR A
 LD B, 03h

Mult8:
 OR A
 RL E
 RL D
 RLA
 DJNZ Mult8

 LD (HL), E
 INC HL
 LD (HL), D
 INC HL
 LD (HL), A

 POP HL
 LD DE, Size + 08h
 ADD HL, DE

 LD B, 06h
Divide64:
 OR A
 RR H
 RR L
 DJNZ Divide64

 LD A, 1Fh
 OUT (06h), A

 CALL 642Ah
; _Md5InitRegs

 PUSH HL
 POP BC

 LD HL, PlotScreen
Continue:
 PUSH BC

 LD DE, 83A5h
 LD BC, 0040h
 LDIR

 PUSH HL

 CALL 64D7h
; _Md5Process

 POP HL
 POP BC
 DEC BC
 LD A, B
 OR C
 JR NZ, Continue

 POP AF
 OUT (06h), A

 LD HL, 8292h
 LD B, 10h
DispMD5Str:
 LD A, (HL)
 AND 11110000b
 RRA
 RRA
 RRA
 RRA
 CALL DispHexChar
 LD A, (HL)
 AND 00001111b
 CALL DispHexChar
 INC HL
 DJNZ DispMD5Str

 RET

DispHexChar:
 CP 0Ah
 JR C, SkipExtraAdd
 ADD A, 'A' - '0' - 0Ah
SkipExtraAdd:
 ADD A, '0'
 JMP(_PutC)


Sample:
 .DB "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
 .DB "abcdefghijklmnopqrstuvwxyz"
 .DB "0123456789"
Size EQU $ - Sample

.END
END
End Code --/

-----Message d'origine-----
De : David Phillips <david@acz.org>
À : assembly-83@lists.ticalc.org <assembly-83@lists.ticalc.org>
Date : vendredi 1 septembre 2000 09:45
Objet : Re: A83: Ti uses MD5


>
>As he said in his original email, and as is explained in the RFC, those are
>not dynamic values.  They are what the registers are initialized to when
>calculating an MD5 hash.  They must be the same for all implementations
that
>wish to generate the same hash value for the same input data.  If the hash
>values are not consistent, then the algorithm is worthless.  There's no
real
>reason why not to comply with the RFC.  Doing so just makes everything
>easier.
>
>Btw, where are you going to find a z80 implemenation of MD5 to borrow?  If
>you know, please let me know :)
>
>> My problem with that is that generally you don't keep dynamic values in
>> rom just for sheer RFC compliance (which I find hard to believe). The
>> only way I would agree with that is if they got the routine from someone
>> else and just added it, or that those values have to be the initial
>> values for the md5-digest to work... but hey, whatever works. If it is
>> true, then what do you plan to do with this knowledge?
>
>
>
>
>