Re: [9fans] Hmm, где secstore на KFS?

Re: [9fans] Hmm, где secstore на KFS?

[Eric Grosse]

Здесь!    sources /sys/src/cmd/auth/secstore/aescbc.c

Dan,

I recommend against a local encrypted file as a substitute
for secstore, because then the thief can perform an offline
dictionary attack.

But you're the second person today to ask for this, so I bow
to the desires of my users and offer a revised aescbc on
sources that prompts for a password.  It's only about a five
line change.  Add to your lib/profile
  auth/aescbc -d < factotum.aes | read -m > /mnt/factotum/ctl

Be sure to choose a password with plenty of entropy.  Since
distributed.net just cracked another 64-bit challenge, you
might take the advice of experts and use 90 bits, i.e. seven
diceware words.

In this version, getpasswd() is called directly.  The idea
in your post of using auth_getkey() is slick, but leaves the
password in factotum.  With proto=pass, any other process
could come along later and read the password.

If people are going to start using this for encrypting such
sensitive material, likely subject to attack, I would
welcome more eyes looking over aescbc.c for cryptographic
flaws.  As far as I know it is reasonably state of the art,
avoiding some mistakes of other encrypted file formats, but
crypto is subtle and anything new is justifiably suspect.

Eric

Re: [9fans] Hmm, где secstore на KFS?

[Dan Cross]

> I recommend against a local encrypted file as a substitute
> for secstore, because then the thief can perform an offline
> dictionary attack.

But what then is one to do when one doesn't have a secstore to store
things on?  In my case, that secstore *would* be a local file, even if
I ran secstored.  You're right about the risk of an offline dictionary
attack, but it's at least better than having everything in plaintext.

Btw, one thing that's always confused me about secstore; can't one
mount a dictionary attack against data that's transmitted across the
network from the secstore?  Granted, that's harder, since the attacker
would have to snif it and couldn't simply pursue it at his or her
leasure, but still possible, or no?

>   auth/aescbc -d < factotum.aes | read -m > /mnt/factotum/ctl

Hooray!  That's better than µsecstore.  Спасйбо!

> In this version, getpasswd() is called directly.  The idea
> in your post of using auth_getkey() is slick, but leaves the
> password in factotum.  With proto=pass, any other process
> could come along later and read the password.

That was sort of intentional; it made updating slightly easier.
Besides, in my case, everything that went into the µsecstore went into
factotum anyway.  aescbc is clearly more general, though, so having
the password *not* in factotum is better.

At anyrate, thanks for the addition to auth/aescbc.  Пока!

	- Dan C.

[9fans] Hmm, где secstore на KFS?

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

This is slightly goofy, please bear with me.

It occured to me that over the course of time, I tend to end up with a
lot of keys in the factotum on my local laptop.  However, it's always
the same keys, and it's repetative and annoying to type every time I
login.  Naturally, I want to put them this in a file, but because I'm
just a little paranoid about my laptop getting stolen (and someone
finding a file called ``passwords!''), I don't want it in plain text.
Secstore is the obvious answer, but only works on a network, and I
don't really want to bother running secstored locally.  It'd be nice
to have something simple that just encrypts and decrypts files on my
local machine.

Auth/aescbc does this, but isn't particularly convenient since you
have to pass the raw key to it (in hex) via the environment (in the
variable HEX).  So, I wrote a small program that acts as a wrapper
around auth/aescbc, and called it µsecstore.  It gets the key to use
from factotum, so it's pretty convenient, and I feel safer using this
than storing my passwords in a file in the clear.  I usually run it
out of my $lib/lib/profile as:

	µsecstore -r $home/lib/factotum.aes | read -m >
	/mnt/factotum/ctl

I've attached it below, along with a man page.  Is there another way
to do this, btw, that might be better?  Criticisms and suggestions are
welcome.

	- Dan C.



[-- Attachment #2: Type: text/plain, Size: 1744 bytes --]

/*
 *  Tiny version of secstore, for a local KFS.
 */

#include <u.h>
#include <libc.h>
#include <mp.h>
#include <libsec.h>
#include <auth.h>

#define	max(X, Y) ((X) > (Y) ? (X) : (Y))
#define	min(X, Y) ((X) < (Y) ? (X) : (Y))


void
usage(void)
{

	fprint(2, "Usage: µsecstore [-u user] {-r|-w} file.\n");
	exits("usage");
}

char *
getpass(char *u, char *s)
{
	UserPasswd *p;

	p = auth_getuserpasswd(auth_getkey,
	    "proto=pass service=µsecstore server=%q user=%q", s, u);
	if (p == nil) {
		exits("no key");
	}

	return(p->passwd);
}

char *
mkkey(char *p)
{
	uchar digest[MD5dlen];
	static char tmp[128];

	md5((uchar *)p, strlen(p), digest, nil);
	enc16(tmp, sizeof tmp, digest, sizeof digest);

	return(tmp);
}

void
µsread(char *f)
{
	close(0);
	if (open(f, OREAD) < 0) {
		sysfatal("can't redirect input from %s: %r\n", f);
	}
}

void
µswrite(char *f)
{
	int	fd;

	close(1);
	fd = open(f, OWRITE | OTRUNC);
	if (fd < 0) {
		fd = create(f, OWRITE, 0600);
	}
	if (fd < 0) {
		sysfatal("couldn't open or create %s: %r");
	}
}

void
main(int argc, char *argv[])
{
	char *f, *o, *p, *s, *u;
	void (*m)(char *f);

	m = nil;
	u = getuser();
	s = sysname();
	if (s == nil) {
		s = "localhost";
	}
	ARGBEGIN {
	case 'u':
		u = EARGF(usage);
		break;
	case 'r':
		if (m != nil)
			usage();
		o = "-d";
		m = µsread;
		break;
	case 'w':
		if (m != nil)
			usage();
		o = "-e";
		m = µswrite;
		break;
	} ARGEND
	f = argv[0];
	if (f == nil || m == nil || u == nil || s == nil) {
		usage();
	}
	p = getpass(u, s);
	rfork(RFCENVG);
	(*m)(f);
	putenv("HEX", mkkey(p));
	execl("/bin/auth/aescbc", "aescbc", o, nil);

	exits(0);
}

[-- Attachment #3: Type: text/plain, Size: 1422 bytes --]

.TH µSECSTORE 1
.SH NAME
µsecstore \- manipulate small repositories of secret
.SH SYNOPSIS
.B µsecstore
[
.B -u
.I user
]
.B -r
file
.PP
.B µsecstore
[
.B -u
.I user
]
.B -w
file
.SH DESCRIPTION
.I µsecstore
is a wrapper around
.IR aescbc (1)
and is intended to provide standalone machines functionality
similar to that of
.IR secstore(1).
.PP
When
.I µsecstore
starts up, it looks in the local
.IR factotum (4)
for an encryption key corresponding to the
current system and user, prompting if one
isn't found.  An alternate user name can
be specified with
.BR \-u .
.PP
If
.B \-w
is given, µsecstore reads data from the standard input,
encrypts it using the key it retrieved from
.IR factotum ,
and writes the result to the named file.  If
.B \-r
is given, it reads and decrypts data from the named file and
writes the result to the standard output.
.PP
In either case, the real work is done by invoking
.IR aescbc (1)
with the appropriate options.
.PP
To load the
.I factotum
with secrets from an encrypted file when logging in, invoke
.I µsecstore
from
.I $home/lib/profile
as:
.EX
    µsecstore -r $home/lib/factotum.aes | read -m > /mnt/factotum/ctl
.EE
.SH FILES
.B $home/lib/profile
.SH SOURCE
.B /sys/src/cmd/µsecstore.c
.SH SEE ALSO
.I Aescbc
in
.IR secstore (1),
.IR secstore (1),
.IR aes (2),
.IR factotum (4),
.IR secstored (1)