-
Notifications
You must be signed in to change notification settings - Fork 57
Conversation
'ob', a core that implemented a permutation cipher for planet-sized atoms, contained a critical bug that allowed multiple inputs to encipher to the same output. This created collisions between some planet-sized @p values. The rewritten version corrects this bug, and also rewrites +ob to more clearly match both 1) the paper that the algorithm comes from, and 2) the parallel implementation in urbit-ob that has gone through an exhaustive test. This also adjusts two calls to 'ob' elsewhere in hoon.hoon such that they match the updated core.
This allows us to test the +ob functions exhaustively on smaller input spaces.
We can test +ob exhaustively over a smaller input space; if it behaves correctly, that gives us much greater assurance that the implementation is correct for the full planet space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The dojo behavior you're seeing seems like #1078, or maybe still some form of #796? It should Just Work if you build a pill and boot from that, in any case.
@Fang- nice, I'll try whipping up a pill. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could generally use a bit more documentation, as I mentioned in a couple other comments. I'd also like to see a long-form comment at the place where the new permutation was added that describes the bug and the solution.
(The cipher's domain was documented incorrectly.)
Added a few previously-known-to-conflict cases to tests that were missing them.
After scratching my head for awhile as to why a pill wouldn't work, I realised I was using the one in Using the correct one persisted my changes to dojo:
|
fwiw @jtobin I made the exact same mistake when I was learning to make modifications to hoon.hoon. It took me way too long to realize what I was doing wrong. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jtobin, I've noted a couple minor style quibbles. Otherwise, this looks great!
I believe =/ is the superior choice and is worth standardising on.
Indent lengthy subexpressions after using =/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple tweaks to the tweaks, and one more idiom consideration I missed:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I'll merge this in -- don't want to sidestep @belisarius222, but I reckon the changes meet his approval, so I'll be bold. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, LGTM
(Resolves #1105)
+ob
, a core that implemented a permutation cipher for planet-sized atoms, contained a critical bug that allowed multiple inputs to encipher to the same output. This created collisions between some planet-sized@p
values.The rewritten version corrects the bug, and also rewrites
+ob
to more clearly match both 1) the paper that the algorithm comes from, and 2) the parallel implementation in urbit-ob that has gone through a full-scale exhaustive test.The rewritten version is also itself easier to test; this PR adds a small-scale exhaustive test, as well as small battery of sanity checks on
+ob
internals (including on@p
values previously known to collide).NOTE: One thing I'm observing here is that dojo may be lagging behind on changes to hoon.hoon. For example, the following in
tests/sys/hoon/auras.hoon
passes:but in dojo, I still get collisions:
Should I trust the test suite here? I'd like to figure out what's going on, regardless.