Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => Topic started by: willrandship on September 27, 2010, 11:34:17 am
-
The way I understand it.........
Nspire OS->Checksum file
Checksum->encryption
= Os x.x.tno
Tno->Calc
Calc Decrypts Checksum, makes checksum from OS bin.
If match, installs.
Is that about right?
Well, if so, what about this?
We write our own loader for our own OS/progs/whatever that matches the checksum of the boot2/OS bin, then that loads the rest of everything when run!
Thoughts/comments?
-
It depends. Cryptographic hashes were designed to prevent these so-called "collision attacks."
MD5, however, is compromised. It depends on what hashing method TI is using.
It'll be awesome if it turns out to be this easy ;D
-
I don't know how possible it is, but is this what you are saying?
Create our own loader in say 10kb. Then use like 50kb to try to fake the checksum? If that's possible, it would be really cool, maybe if we devoted a few computers to such a feat it would be possible.
-
MD5 is not completely down and out. Besides, I would presume that the nspire might use SHA-1. Just a theory considering the 1024 bit key.
And Because of the way hashes work, It would be easier to factor the RSA keys then trying to find a match.
-
Is there any way to know which method they used? It would really stink to develop a program to match the checksum of one type, only to have it be completely different from another, and be rejected.
-
any news about this?
-
MD5 is not completely down and out. Besides, I would presume that the nspire might use SHA-1. Just a theory considering the 1024 bit key.
And Because of the way hashes work, It would be easier to factor the RSA keys then trying to find a match.
MD5 is down and out, as of 2006 (http://www.cs.colorado.edu/~jrblack/papers/md5e-full.pdf). SHA-1 isn't quite down and out, but it's struggling.
Insert obligatory "Holy Necropost Fishman" here :D
-
That's one fishy necro! :O How did you happen to stumble onto this again anyways?
-
I was going over some security stuff and I remembered how computationally expensive it was to sign large quantities of data with public key algorithms. It got me thinking about how the Nspire would have to sign an entire OS if it didn't use hash of sorts and...
-
Very interesting :)
Got to research some more details.
-
That would be tricky overall, but it would be possible considering we've got ndless already manipulating the OS a bit. So effectively, we would be able to write a different OS (GUI) or shell?
-
You can do that now already.
But the thing here is to have an alternative OS working without Ndless, and installed the the flash.
This would give also much more power to the user.
-
Yeah I meant that, an OS independent of programs using the OS.
It would definitely give much more power to the user. But flexibility too.
-
jimbauwens pointed me to this topic.
Is there any way to know which method they (TI) used?
The method was publicly documented on Hackspire months before this thread was started ;)
Namely, TI uses SHA256, which is much stronger than SHA-0 or SHA-1, and of course even more stronger than MD5 (used in TI-Z80 and TI-68k series).
Finding a useful cryptographic hash collision would be like winning 10-15 times at the lottery, instead of 20-30 (or 40-60) with TF on the public RSA keys... that's immensely better, but still completely hopeless. Neither method is a usable way to achieve our basic user right, our freedom to tinker with the hardware we own.
-
I have to give TI props, they knew what they were doing this time with the Nspire. Although, being able to generate collisions would in fact give us a method to reinstall the OS because if the hash was sufficiently weak, it would give us the freedom to pick certain parts of the data and then select other sections of data to form a collision (basically a variation of the chosen-prefix attack).
Thanks for pointing out the information. I couldn't find the info on Hackspire :)