Prev: Call for participants
Next: My Cryptography that is Currently on the Table.
From: Wolfgang Ehrhardt on 5 Jul 2010 13:31
On Mon, 5 Jul 2010 12:18:20 +0000 (UTC), Kristian Gj�steen
<kristiag+news(a)math.ntnu.no> wrote:
>>If so, is there any way to do it using other/extra primitives?
>
>I can't think of any. It seems impossible.
>
>(Consider the following attack: the user has stored one data file
>generated with his passphrase. I substitute my data file generated with a
>random passphrase. How is the software to decide whether the user enters
>the correct passphrase and the file has been tampered with, or the file
>has not been tampered with and the user enters an incorrect passphrase?)

Do you have any concerns about the following construction?

(masterkey, pw_verifier) = PBKDF(passphrase, salt)

i.e. instead you deriving the key bits only derive say 64 bits more
and use them as a password verifier.

The password verification calculates (masterkey2, pw_verifier2) =
PBKDF(passphrase2, salt), and if pw_verifier != pw_verifier2, the
password is wrong (ignoring the 2^-64 chance of false negatives).

From: Kristian Gj�steen on 5 Jul 2010 14:15
Wolfgang Ehrhardt <WE(a)completely.invalid> wrote:
>On Mon, 5 Jul 2010 12:18:20 +0000 (UTC), Kristian Gj�steen
><kristiag+news(a)math.ntnu.no> wrote:
>>>If so, is there any way to do it using other/extra primitives?
>>
>>I can't think of any. It seems impossible.
>
>Do you have any concerns about the following construction?
>
>(masterkey, pw_verifier) = PBKDF(passphrase, salt)
>
>i.e. instead you deriving the key bits only derive say 64 bits more
>and use them as a password verifier.
>
>The password verification calculates (masterkey2, pw_verifier2) =
>PBKDF(passphrase2, salt), and if pw_verifier != pw_verifier2, the
>password is wrong (ignoring the 2^-64 chance of false negatives).

I haven't got a problem with it, but it doesn't solve the problem
as posed.

--
kg
From: TC on 6 Jul 2010 01:36
On Jul 6, 3:15 am, Kristian Gjøsteen <kristiag+n...(a)math.ntnu.no>
wrote:
> Wolfgang Ehrhardt <W...(a)completely.invalid> wrote:
> >On Mon, 5 Jul 2010 12:18:20 +0000 (UTC), Kristian Gjøsteen
> ><kristiag+n...(a)math.ntnu.no> wrote:
> >>>If so, is there any way to do it using other/extra primitives?
>
> >>I can't think of any.  It seems impossible.
>
> >Do you have any concerns about the following construction?
>
> >(masterkey, pw_verifier) = PBKDF(passphrase, salt)
>
> >i.e. instead you deriving the key bits only derive say 64 bits more
> >and use them as a password verifier.
>
> >The password verification calculates (masterkey2, pw_verifier2) =
> >PBKDF(passphrase2, salt), and if pw_verifier != pw_verifier2, the
> >password is wrong (ignoring the   2^-64 chance of false negatives).
>
> I haven't got a problem with it, but it doesn't solve the problem
> as posed.


Thanks for everyones' further replies. I need to read them all
carefully, which will take a couple of days. Then I will get back
again.

Cheers,
TC
From: TC on 9 Jul 2010 05:28
On Jul 6, 2:36 pm, TC <gg.20.keen4s...(a)spamgourmet.com> wrote:
> On Jul 6, 3:15 am, Kristian Gjøsteen <kristiag+n...(a)math.ntnu.no>
> wrote:
>
>
>
>
>
> > Wolfgang Ehrhardt <W...(a)completely.invalid> wrote:
> > >On Mon, 5 Jul 2010 12:18:20 +0000 (UTC), Kristian Gjøsteen
> > ><kristiag+n...(a)math.ntnu.no> wrote:
> > >>>If so, is there any way to do it using other/extra primitives?
>
> > >>I can't think of any.  It seems impossible.
>
> > >Do you have any concerns about the following construction?
>
> > >(masterkey, pw_verifier) = PBKDF(passphrase, salt)
>
> > >i.e. instead you deriving the key bits only derive say 64 bits more
> > >and use them as a password verifier.
>
> > >The password verification calculates (masterkey2, pw_verifier2) =
> > >PBKDF(passphrase2, salt), and if pw_verifier != pw_verifier2, the
> > >password is wrong (ignoring the   2^-64 chance of false negatives).
>
> > I haven't got a problem with it, but it doesn't solve the problem
> > as posed.
>
> Thanks for everyones' further replies. I need to read them all
> carefully, which will take a couple of days. Then I will get back
> again.
>
> Cheers,
> TC- Hide quoted text -
>
> - Show quoted text -

Hi folks

I'm really surprised to see that there is apparently no way to do what
I want. It seems like such a simple requirement from an end-user
viewpoint!

To restate the requirement: the user enters a passphrase. The
ciphertext does not decrypt to the original plaintext. I want to
unambigously detect whether that was because (1) the user entered the
wrong passphrase, or (2) the ciphertext has been altered (for any
reason - including by a malicious attacker).

Francois Grieu says: "There is no meaningful way to distinguish "wrong
password" from "malicious alteration" without a public key scheme."

I'm no expert, but on reflection, it seems to me that the problem is
this.

There's /no shared secret/ in this system. The only secret is the
passphrase. But if someone enters the passphrase wrongly, then, they
no longer share a secret with the person who encrypted the data. And
"no shared secret" means, "no way to distinguish 'wrong passphrase'
from 'malicious alteration'" - right?

If the users /did/ have a shared secret, /seperate to/ the password,
then I could achieve what I want - /without/ using a public key
scheme. So the problem is not the lack of a public key scheme - it's
the lack of a known shared secret - right?

TIA,
TC
From: Kristian Gj�steen on 9 Jul 2010 07:38
TC <gg.20.keen4some(a)spamgourmet.com> wrote:
>So the problem is not the lack of a public key scheme - it's
>the lack of a known shared secret - right?

Well, if you have a shared secret, what do you need the passphrase for?

--
kg
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Call for participants
Next: My Cryptography that is Currently on the Table.