Thanks for that! You always have helpful info to share :)
On Sun, Jan 25, 2015 at 7:14 AM, Eric Auer <[email protected]> wrote:
>
> 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
>
------------------------------------------------------------------------------
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
