Hi security fans, here are some results from wikipedia-ing around a bit:
As follow-up to my previous mail, now about the topic of a tool to help several users to share one DOS PC by preventing them from accessing each others files (but not preventing them from deleting their disks). Password obfuscation is not what lock/screensaver tools should rely on either. Use a proven hashing. A tool to mount secure drive images, even if it is written in a less popular language, would clearly qualify for inclusion or at least mirroring :-) You could do something like: Key = [secure random value]. Hash = [secure hash of password]. Store (hash xor key) along with drive image. To unlock, compute key = stored value xor hash of what the user claims to be the password. Use for example XTEA to crypt all I/O for that disk image, AFTER adding the sector number to the key. As XTEA is using 64 bit blocks and 128 bit keys, you could either add the offset within the sector to the key or use a streaming scheme where you use the output of the previous 64 byte block within the sector for example xor to the next input first. Without making keys depend on the sector number, people could just use known content and crypted content of one sector to decrypt another sector with the same transformation. For example boot sector contents or contents of FAT sectors can be easily guessed. For not yet used sectors, do NOT use the encrypted version of a block of 00 bytes in the initial empty disk image. Use some random content. If you are lazy, use 00s, which will decrypt into pseudo random content, but it will be possible for others to see which sector has not yet been used then (it is unlikely that any sector filled with real data crypts into a block of 00 bytes, you get my point). https://en.wikipedia.org/wiki/XTEA Because patents have expired, you can also use IDEA: https://en.wikipedia.org/wiki/International_Data_Encryption_Algorithm For the hashing, you could use something with a small code size and memory overhead such as: https://en.wikipedia.org/wiki/RIPEMD http://homes.esat.kuleuven.be/~bosselae/ripemd160.html If the user enters the wrong password, the hash will be different from the hash of the correct password, so xoring the stored value with that wrong hash will not recover the original key and the disk image I/O will produce gibberish. For the random numbers, you could use something as the Fortuna PRNG, for the moment assuming that XTEA would be sufficiently strong for our purposes... https://en.wikipedia.org/wiki/Fortuna_%28PRNG%29 This boils down to filling your empty sectors with arrays of 64 bit integers starting with a random value and then counting up, then XTEA crypting the result and call it the "random plaintext". The I/O encryption step of your driver will XTEA it again, but now using the (random user key + sector number) as explained above. In other words, only people who know your random start value (which nobody should know) will have a chance to distinguish the encrypted sector from truly random data, and only if they know the user key. This means people will not be able to tell if a sector in the secure disk image is used or not. For the random start value, try to gather as much real random from the system state as you can and then hash it. In other words, do not simply use a hash of the time of day, that is easy to guess :-p Whew. So many algorithms. I hope this helps anybody when picking existing code modules as the ones in the list above when they make a secure drive mount! Regards, Eric ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
