I used a delphi example as a basis.
the java implementations seems different.
I changed it and used the C code as a basis : https://github.com/polarssl/polarssl/blob/master/library/xtea.c
And this gives the same result :
http://www.movable-type.co.uk/scripts/tea.html
But when i read your earlier comment, it is not the same as b4d.
So with my modified xtea lib I get :
Encrypted: 73ECBFEC3EA85E4E73ECBFEC3EA85E4E
sì¿ì>¨^Nsì¿ì>¨^N
which is the same as the javascript when key is UUUUUUUUUUUUUUUU and text is 5555555555555555
... after some sleep : i checked the various implementations and it appears they use different endians. After i reversed the memory order i get the same output as b4d. I did not check the others.
The delphi sample i found in the wiki was simply wrong. I tested bascom xtea with this and that worked. Never tested it with other implementations.This means that the current implementation in bascom is wrong too.
The impact is not high when you use it with the bascom. But when you go cross platform you can get a problem.
Then there are various java/c implementations and some are wrong too because of the different storage in memory.
But i added a variant which should be according to the standard. It will be available in the next update.
↧