opie or s/key with gpg? (fwd)

[Atom 'Smasher']

it might not require that the secret pgp key be stored in the clear, with
access to it controlled by "something else"....

i'm not any good when it comes to C (yet!), so i'm not the one to write
any proof-of-concept code, but here's how it could work on any machine
that you'd trust "enough" to type your password into in the first place...

i wish i could do more oversimplifying here, but i'm sure that'll just
confuse things...

	== how it could work ==

based on the secret-keyring, an opie-secret-keyring is generated (when
setting an opie password). when a password is entered (into gpg), to
unlock the secret pgp key, it's first checked to see if it's the valid
reusable password, and if it isn't then it's checked if it's an opie
password.

the fun part is how to keep the opie-secret-keyring safe....

remember, this is an oversimplification, so don't flame me if something
isn't quite right....

let's say we have the count at 123, the password="p", the seed="s", so the
opie-secret-keyring is symmetrically encrypted, with a password based on
the final hash value of opie(p,s,124).

so, after a successful OTP is given to [an opie version of] gpg, let's
decrypt the secret key (from the opie-secret-keyring) so it's available to
gpg to do it's thing, and then re-encrypt the opie-secret-keyring, this
time with a password based on opie(p,s,123) (the current OTP). the next
valid OTP is #122.

in other words, the opie-secret-keyring is symmetrically encrypted, using
a password which is based on the final hash value of opie as it's
password. every time the opie-secret-keyring is accessed, the file is
decrypted (otherwise the key can't be accessed), then re-encrypted with
it's new password based on the final hash value of opie.

now the opie-secret-keyring is encrypted with a password based on
opie(p,s,123), and entering the right opie-password (based on a count of
122) will decrypt it, make the key available, and then re-encrypt it with
a password based on the final hash of opie(p,s,122). the opie counter is
now at 121.

** weakness below **

this should work. of course other concerns would be the security of the
computer, including any media that the file is stored on, or accessible
to, but that's a matter of implementation, not protocol... and since these
concerns already apply to the current implementations, i don't think
there's much of a drawback.

all in all, i would think that if this were reasonably implemented, it
would be at least as secure as a reusable password. maybe this would be
even better.... in a case were my keyring is generated and maintained on a
local machine (trusted to be secure), i could then copy an
opie-secret-keyring to a server that i use to read/send mail, and not have
to worry about my keystrokes being logged. (i know; if my keystrokes are
logged, then *they* know what i'm writing before it gets encrypted, but
they won't get my key - it makes a PART of the system more secure, it
doesn't make the whole system more secure.)

in some environments, this could eliminate what is currently the weakest
link in the practical use of pgp.

** weakness **

if an attacker gets a copy of the opie-secret-keyring, and sniffs any OTP
that's newer than the file, that sniffed OTP can be used to generate
previously used OTPs (which can unlock the file). this requires that the
opie secret password and string are the same, both the time that the file
is stolen, and the time that the password is sniffed. however, if an
attacker has access to both the opie-secret-keyring AND your password,
then you're hosed anyway. this method DOES NOT protect you in the event
that your opie-secret-keyring can be read by an attacker; it ONLY protects
your password from being replayed. of course, i'm not sure how useful the
password would ever be, without a copy of the encrypted secret keyring, so
maybe the whole thing makes no sense.... maybe all of this rambling is
pointless anyway?

it's 0035h here... i'll stop rambling, and start wasting some thought
cycles on how to use something like opie to keep files safe....



> > does anyone know if there's (yet) any way to use opie or s/key to unlock
> > one's secret gpg key? if done right, this could greatly reduce
> > (eliminate?) the possibility of having one's password sniffed, either on a
> > network or from the keyboard.....
>
> It is theoretically possible (I've thought about it for certain uses),
> but it does not do what one might think it does.  One-time passwords
> pretty much require that the item being protected be under the control
> of the machine that runs the OTP system.  The process that
> authenticates the OTP can then grant access to the protected item, in
> this case the secret key.  It comes down to the OTP process either
> needs access to the unprotected key or the passphrase.
>
> This isn't a fatal flaw (after all, the gpg agent holds the same
> information in memory), but it does change the circumstances where
> such a setup would be useful.  Since most people want such a thing for
> accessing their keys remotely, the requirement that their remote
> machine must remain completely secure usually makes them reconsider.

        ...atom

_______________________________________________
PGP key - http://smasher.suspicious.org/pgp.txt
3EBE 2810 30AE 601D 54B2 4A90 9C28 0BBF 3D7D 41E3
-------------------------------------------------

	"Violence is the first refuge of the incompetent."
		-- Issac Asimov