Discussion:
[urbit] Checking galaxy fingerprint
c***@gmail.com
2015-12-11 03:53:42 UTC
Permalink
I was playing with ames, trying to generate the fingerprint of ~zod from
dojo to check it against the hardcoded signature in ++zeno. I came up with
a couple different outputs, but none of them match:

`=+(a=;;(will .^(%a /=will=/~zod)) `@uw`(shaf %afig r:(step q:(snag 0
a))))` gives back 0wY.~kbN3.xmCFW.KnqQc.MHtJv, and even though r.step says
it's a fingerprint it's too long for a @uwH

`=+(b=;;(will .^(%a /=will=/~zod)) fig:ex:(haul r.q:(snag 0 b)))` gives
back 0v1.hn3b4.akcha.sp72e.jh4h5.qeiiu, which looks to me like it's the
actual fingerprint of ~zod. Running `=+(b=;;(will .^(%a
/=will=/~haptem-fopnys)) fig:ex:(haul r.q:(snag 2 b)))` gives the same
result, for example, and it's the same way ++pier generates the sig.

Not being able to get it working, I check through ames.hoon for `zeno` and
it looks like it only checks the key fingerprint against zeno when it's
*generating a czar will*, which obviously isn't very good.

On line 105, it's checked against the fig:ex:(haul r.q.wed) - but that's
only a check when you create your own will, it looks like, and is the same
as my second try that doesn't work.

On line 1006, it's checked against fig:ex again, but only to check if the
local ship, if it's a czar, is using -F
It also looks to me like it's checking the fingerprint of the *private
key*, instead of the public key, since it's using fig:ex on the result of
++bruw instead of ++haul?

=+ loy=?:(fak (bruw 2.048 our) (bruw 2.048 ger)) :: fake uses
carrier #
=+ fim==(fig:ex:loy (zeno our))
?: &(!fak !fim) !! :: not fake & bad
fig

Is my assumption correct that ames never actually checks the fingerprint of
the key it gets when it peers with ~zod, or did I overlook something
obvious?
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
c***@gmail.com
2015-12-11 04:23:15 UTC
Permalink
Hmm. I started up a fake ~del and a fake submarine with changed ++zeno sig,
and neither are able to peer with my fakezod. I must have missed something?

Oh darn: ++pier is used in ++grip, which is used in ++deng for creating
/all/ wills. Both %full and %open packets call it.
Post by c***@gmail.com
I was playing with ames, trying to generate the fingerprint of ~zod from
dojo to check it against the hardcoded signature in ++zeno. I came up with
a))))` gives back 0wY.~kbN3.xmCFW.KnqQc.MHtJv, and even though r.step says
`=+(b=;;(will .^(%a /=will=/~zod)) fig:ex:(haul r.q:(snag 0 b)))` gives
back 0v1.hn3b4.akcha.sp72e.jh4h5.qeiiu, which looks to me like it's the
actual fingerprint of ~zod. Running `=+(b=;;(will .^(%a
/=will=/~haptem-fopnys)) fig:ex:(haul r.q:(snag 2 b)))` gives the same
result, for example, and it's the same way ++pier generates the sig.
Not being able to get it working, I check through ames.hoon for `zeno` and
it looks like it only checks the key fingerprint against zeno when it's
*generating a czar will*, which obviously isn't very good.
On line 105, it's checked against the fig:ex:(haul r.q.wed) - but that's
only a check when you create your own will, it looks like, and is the same
as my second try that doesn't work.
On line 1006, it's checked against fig:ex again, but only to check if the
local ship, if it's a czar, is using -F
It also looks to me like it's checking the fingerprint of the *private
key*, instead of the public key, since it's using fig:ex on the result of
++bruw instead of ++haul?
=+ loy=?:(fak (bruw 2.048 our) (bruw 2.048 ger)) :: fake uses
carrier #
=+ fim==(fig:ex:loy (zeno our))
?: &(!fak !fim) !! :: not fake & bad
fig
Is my assumption correct that ames never actually checks the fingerprint
of the key it gets when it peers with ~zod, or did I overlook something
obvious?
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Curtis Yarvin
2015-12-11 19:02:54 UTC
Permalink
Hm, it's certainly possible. This is obviously old code and I'm not
terribly worried about it; not only are the keys test keys, but the
crypto code and the secret handling/verification code are both due for
existential levels of change. :-)
Post by c***@gmail.com
I was playing with ames, trying to generate the fingerprint of ~zod from
dojo to check it against the hardcoded signature in ++zeno. I came up with a
gives back 0wY.~kbN3.xmCFW.KnqQc.MHtJv, and even though r.step says it's a
`=+(b=;;(will .^(%a /=will=/~zod)) fig:ex:(haul r.q:(snag 0 b)))` gives back
0v1.hn3b4.akcha.sp72e.jh4h5.qeiiu, which looks to me like it's the actual
fingerprint of ~zod. Running `=+(b=;;(will .^(%a /=will=/~haptem-fopnys))
fig:ex:(haul r.q:(snag 2 b)))` gives the same result, for example, and it's
the same way ++pier generates the sig.
Not being able to get it working, I check through ames.hoon for `zeno` and
it looks like it only checks the key fingerprint against zeno when it's
*generating a czar will*, which obviously isn't very good.
On line 105, it's checked against the fig:ex:(haul r.q.wed) - but that's
only a check when you create your own will, it looks like, and is the same
as my second try that doesn't work.
On line 1006, it's checked against fig:ex again, but only to check if the
local ship, if it's a czar, is using -F
It also looks to me like it's checking the fingerprint of the *private key*,
instead of the public key, since it's using fig:ex on the result of ++bruw
instead of ++haul?
=+ loy=?:(fak (bruw 2.048 our) (bruw 2.048 ger)) :: fake uses
carrier #
=+ fim==(fig:ex:loy (zeno our))
?: &(!fak !fim) !! :: not fake & bad
fig
Is my assumption correct that ames never actually checks the fingerprint of
the key it gets when it peers with ~zod, or did I overlook something
obvious?
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to urbit-dev+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Continue reading on narkive:
Loading...