echo -n test | ecryptfs-add-passphrase always creates sig [d395309aaad4de06]

[Hans]

I am worried about the behaviour of ecryptfs-add-passphrase which always creates the same password signatures. There are lots of documents that point out that you should add the key signature into a file on the disk. If I run that command on two systems it produces the same signature.

However unless I have a better explanation, this looks like a checksum over the passphrase to me, and If I would have access to such a system I would check if i could run all that through some sort of rainbow table.

So please forgive me that I am a bit worried right now. Instead of exposing a checksum of your password to parts of the system without any salt in it, I would have expected to see a description string there which could be generated by use of the name of the mountpoint or set by the user.

[Dustin Kirkland  (kirkland)]

Hmm, that's not the behavior I'm seeing here:

kirkland@x250:~⟫ echo abc123 | ecryptfs-add-passphrase -
Inserted auth tok with sig [dba5ed7952a1184d] into the user session keyring
kirkland@x250:~⟫ echo foobar | ecryptfs-add-passphrase -
Inserted auth tok with sig [c7fed37c0a341e19] into the user session keyring
kirkland@x250:~⟫ echo and_again | ecryptfs-add-passphrase -
Inserted auth tok with sig [6a81a6555ffd4978] into the user session keyring

That's with:

ii ecryptfs-utils 108-0ubuntu1 amd64 ecryptfs cryptographic filesystem (utilities)

[Hans (zem-g)]

Hi Dustin,

My problem is more that the same password leads to the same signature.

Look we do now know the following points:

dba5ed7952a1184d --> abc123
d395309aaad4de06 --> test
c7fed37c0a341e19 --> foobar
6a81a6555ffd4978 --> and_again

you just need to put that info along with all the other passwords in a
nice 'little' 10-50TB numerical ordered table and as soon as you have access
to a signature string you just look your password up.

The e4crypt implementation uses at least a salt here, but I think
setting that ID (which is documented as a free text string to identify a key
in the keyring within the kernel doku) from a different source would be best.

testpass1 --> abc123
anothertest2 --> test
rfcsomething --> foobar
passforzemshome --> and_again

You could also use the mountpoint, or a checksum of the mountpoint, for
this token. From my standpoint is absolutely unclear to me why this
password hash is needed at all. An ID is needed, but not as hash
over the password.

regards

    Hans

On Fri, Dec 11, 2015 at 04:22:30PM -0000, Dustin Kirkland  wrote:
> Hmm, that's not the behavior I'm seeing here:
>
> kirkland@x250:~⟫ echo abc123 | ecryptfs-add-passphrase -
> Inserted auth tok with sig [dba5ed7952a1184d] into the user session keyring
> kirkland@x250:~⟫ echo foobar | ecryptfs-add-passphrase -
> Inserted auth tok with sig [c7fed37c0a341e19] into the user session keyring
> kirkland@x250:~⟫ echo and_again | ecryptfs-add-passphrase -
> Inserted auth tok with sig [6a81a6555ffd4978] into the user session keyring
>
> That's with:
>
> ii ecryptfs-utils
> 108-0ubuntu1 amd64
> ecryptfs cryptographic filesystem (utilities)
>
>
> ** Changed in: ecryptfs
> Importance: Undecided => High
>
> ** Changed in: ecryptfs
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1525025
>
> Title:
> echo -n test | ecryptfs-add-passphrase always creates sig
> [d395309aaad4de06]
>
> Status in eCryptfs:
> Incomplete
>
> Bug description:
> I am worried about the behaviour of ecryptfs-add-passphrase which
> always creates the same password signatures. There are lots of
> documents that point out that you should add the key signature into a
> file on the disk. If I run that command on two systems it produces the
> same signature.
>
> However unless I have a better explanation, this looks like a checksum
> over the passphrase to me, and If I would have access to such a system
> I would check if i could run all that through some sort of rainbow
> table.
>
> So please forgive me that I am a bit worried right now. Instead of
> exposing a checksum of your password to parts of the system without
> any salt in it, I would have expected to see a description string
> there which could be generated by use of the name of the mountpoint
> or set by the user.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ecryptfs/+bug/1525025/+subscriptions
>

--
This final error message indicates a successful installation of a
U...