* Re: [9fans] retry with aescbc
@ 2002-10-16 8:49 Charles Forsyth
0 siblings, 0 replies; 6+ messages in thread
From: Charles Forsyth @ 2002-10-16 8:49 UTC (permalink / raw)
To: 9fans
i suggested
>>> ramfs -m /n/kremvax >[2] /dev/null #suppress unmount message
>
> those that worry can include -p to make ramfs's memory private
> for the short time it lives.
but of course there was more to protect than just ramfs in that interaction.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] retry with aescbc
@ 2002-10-18 3:02 Russ Cox
0 siblings, 0 replies; 6+ messages in thread
From: Russ Cox @ 2002-10-18 3:02 UTC (permalink / raw)
To: 9fans
It should be read -m.
Factotum shouldn't accept
the multiline control message.
Russ
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] retry with aescbc
2002-10-16 2:48 rob pike, esq.
@ 2002-10-18 2:59 ` Micah Stetson
0 siblings, 0 replies; 6+ messages in thread
From: Micah Stetson @ 2002-10-18 2:59 UTC (permalink / raw)
To: 9fans
> # retry until good password
> ramfs -m /n/kremvax >[2] /dev/null #suppress unmount message
> status = 'failed to authenticate'
> while(~ $status *'failed to authenticate'*)
> auth/aescbc -d < lib/factotum.aes > /n/kremvax/factotum
> cp /n/kremvax/factotum /mnt/factotum/ctl
> unmount /n/kremvax
When I use cp to inject keys into factotum, I get weird results.
Should read -m always be used, or is this a bug in factotum?
Here's what I get reading /mnt/factotum/ctl after read -m:
key ek=2F n=reallylongnumber proto=sshrsa size=1024 !dk? !p? !q? !kp? !kq? !c2?
key dom=outside.plan9.bell-labs.com proto=p9sk1 user=micah !password?
key proto=vnc server=cephas !password?
But using cp, I get this:
key dom=outside.plan9.bell-labs.com ek=2F key='' key='' n=reallylongnumber proto=sshrsa server=cephas size=1024 user=micah !dk? !p? !q? !kp? !kq? !c2? !password? !password?
key dom=outside.plan9.bell-labs.com ek=2F key='' key='' n=reallylongnumber proto=p9sk1 server=cephas size=1024 user=micah !dk? !p? !q? !kp? !kq? !c2? !password? !password?
key dom=outside.plan9.bell-labs.com ek=2F key='' key='' n=reallylongnumber proto=vnc server=cephas size=1024 user=micah !dk? !p? !q? !kp? !kq? !c2? !password? !password?
I think this is a consequence of cp using a single write to copy
the file. I wouldn't bring it up except that rob uses cp in his
example.
Micah
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] retry with aescbc
@ 2002-10-16 8:29 Charles Forsyth
0 siblings, 0 replies; 6+ messages in thread
From: Charles Forsyth @ 2002-10-16 8:29 UTC (permalink / raw)
To: 9fans
>> ramfs -m /n/kremvax >[2] /dev/null #suppress unmount message
those that worry can include -p to make ramfs's memory private
for the short time it lives.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [9fans] retry with aescbc
@ 2002-10-16 2:48 rob pike, esq.
2002-10-18 2:59 ` Micah Stetson
0 siblings, 1 reply; 6+ messages in thread
From: rob pike, esq. @ 2002-10-16 2:48 UTC (permalink / raw)
To: 9fans
Russ fixed the rc buglet, so if you get new stuff from sources you can use
# retry until good password
ramfs -m /n/kremvax >[2] /dev/null #suppress unmount message
status = 'failed to authenticate'
while(~ $status *'failed to authenticate'*)
auth/aescbc -d < lib/factotum.aes > /n/kremvax/factotum
cp /n/kremvax/factotum /mnt/factotum/ctl
unmount /n/kremvax
Also, Eric fixed a buglet in aescbc so it takes <CR> for an answer,
making it possible to get out of this loop by providing an empty
password.
-rob
^ permalink raw reply [flat|nested] 6+ messages in thread
* [9fans] retry with aescbc
@ 2002-10-16 2:05 rob pike, esq.
0 siblings, 0 replies; 6+ messages in thread
From: rob pike, esq. @ 2002-10-16 2:05 UTC (permalink / raw)
To: 9fans
auth/aescbc detects a bad password but generates output anyway, so
if you use it as a μsecstore you'll be disappointed the first time
you type a bad password. that is, if you
auth/aescbc -d < lib/factotum.aes > /mnt/factotum/ctl
and get the password wrong, factotum will get delivered garbage.
here's a clumsy wrapper that addresses the issue; perhaps someone
else will find a better way. (the need for $result is due to a
buglet in rc regarding $status at the top of a while loop.)
# retry until good password
ramfs -m /n/kremvax >[2] /dev/null #suppress unmount message
result = 'failed to authenticate'
while(~ $result *'failed to authenticate'*){
auth/aescbc -d < lib/factotum.aes > /n/kremvax/factotum
result = $status
}
cp /n/kremvax/factotum /mnt/factotum/ctl
unmount /n/kremvax
aescbc is a little too liberal with the exit string 'failed to
authenticate' but i've asked ehg to tighten it up.
-rob
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-10-18 3:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-16 8:49 [9fans] retry with aescbc Charles Forsyth
-- strict thread matches above, loose matches on Subject: below --
2002-10-18 3:02 Russ Cox
2002-10-16 8:29 Charles Forsyth
2002-10-16 2:48 rob pike, esq.
2002-10-18 2:59 ` Micah Stetson
2002-10-16 2:05 rob pike, esq.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).