[dm-crypt] two factor authentication with zuluCrypt
.. ink ..
mhogomchungu at gmail.com
Mon Oct 17 16:39:15 CEST 2011
> I do not think this increases security but Arno already mentioned this.
> You can check various wrappers (in Debian for example) and integrate
> support for smardcards etc.
> But I would better to see that GUI does not implement these things,
> this should be separate code.
> ok, will not then. It was just a though as i was looking at truecrypt to
see what features it has.
Why doesnt cryptsetup support two factor authentication?
> Btw there a lot of cleaning needed in your zulucrypt code.
> It is not easy to package it - and without users in distros this make no
> For example your hardcoded "build" script should be replaced by qmake
> (or whatever Qt world prefers today).
> If you look at the code, i am sure you have seen it looked "amateurish".
Thats because this is my first attempt at meaningful programming and there
is a lot to cover. I started with cryptsetup because i manage a bunch of
encrypted volumes in files and managing them through a cli interface was
annoying, i created a script to simply the task but it still involved
opening a terminal and typing commands and it got really boring really
That is why i started this project with two requirements, it has to work
without requiring root's password(suid program) and it must work with
encrypted files, of type "plain" because thats what we have mostly. It
already does what i want, i am working on it further to learn more and make
cryptsetup easier to use for others too.
packaging is something i was going to do next and i currently do not know
anything about them, the script was a quick hack to build the package and
install it while i concentrate on learning and doing other things. If
packaging can not work with it, then i will change it to use qmake for
> Another thing is loading of libcryptsetup through dlopen(). Not
> only this will not work on other architectures (think /lib64)
Can you clarify on this? it will not work because dlopen isnt present/works
differently in 64 bit or because the search path in my code does not include
> why you are doing this at all? There are versioned symbols,
> you should link the program directly to library...
> (Otherwise after upgrade in future this can do really bad things.)
because this is my first attempt at meaning programming and i am creating an
suid program without really comprehending a lot of what i am doing and suid
program in linux are practically considered a sin, was just trying to cover
my bases by being as specific as i can. I though going straight and manually
picking a library will be more secure. Will go back to linking directly.
Thanks for the input.
I could have statically link against the library but pclinuxos does not ship
with the static library, cryptsetup only build it on request at build time
and i though other distros also do not ship with the static library and this
could inconvenience users and thats why i went with the shared library.
> There is great potential in some GUI similar to Truecrypt one
> but your code is really not ready - don't you want better spent
> time with cleaning the code?
i try to clean it as much as i can. If there is anything more you can think
that needs cleaning, please tell and i will do it.
While we are talking about cleaning the code, from what i know so far,
"mount/umount" system calls do not add entries in "/etc/mtab" and tools like
kdiskfree do not show these opened volumes if they do not have entries in
mtab, manually editing the file corrupts it and that is why i use
"mount/umount" cli tools through popen because they do whatever they to do
add entries in mtab on mounting and unmounting volumes.
Can you think of a way i can do this completely within my program without
corrupting the file? manually editing mtab will cause mount/umount command
to hand and then they complain about unlocked /etc/mtab~ or something.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt