c***@gmail.com
2015-12-11 03:53:42 UTC
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?
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.
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.