Re: [cap-talk] RumpelTree++

On Mon, November 3, 2014 05:59, David Barbour wrote:
> I've recently been contemplating Rumpelstiltskin hash trees for my current
> project, Wikilon, a wiki-based IDE and software platform oriented around
> my
> concatenative capability language, AO. Wikilon will provide a
> filesystem-like abstraction, albeit oriented around the language.

Sounds interesting.

> One question: to the best of your knowledge, is Rumpelstiltskin hash tree
> patent encumbered in any way? Will it become so? I'd rather not deal with
> that.

No, I'm highly allergic to patents myself, but next to that, aren't
computer algorithms excluded from patentability? In any case, in the worst
case we have the cap-talk mailing list archive to prove prior art ;-)

http://www.eros-os.org/pipermail/cap-talk/2012-February/thread.html



> I have other approaches in mind if necessary, e.g. conventional
> Type/ID/Auth/HMAC identifiers.
>
> My second question is whether you've considered how to handle
> *revocability*. For example, a user wishes to delegate an expert an
> authority to poke around a bit, help with configuration of a service for
> example, but wants to revoke the granted authority shortly after the help
> is performed.

Not at that level. I'm still trying to come up with a 'storage-friendly'
caretaker like overlay, no luck yet though.

> Seems to me that your Rumpelstiltskin tree hash doesn't really offer any
> sort of attenuation on the temporal dimension.
>
> With the more conventional model, I could add a token to the Auth field
> representing a revocable authorization-path of sorts, and offer a few
> methods to attenuate the session. Such IDs grow large quickly. An
> appealing
> aspect of your hash trees is the constant size identifier.
>
>
> On Sun, Aug 3, 2014 at 4:53 PM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:
>
>> Added a web page with some usage documentation:
>>
>> http://pibara.github.io/Rumpeltreepp/
>>
>> Anyone know a good place to find people who might be willing to
>> contribute
>> a security and crypto oriented code-review?
>>
>>
>> T.I.A
>>
>> Rob
>>
>>
>> On Sat, August 2, 2014 13:03, Rob Meijer wrote:
>> > For most of you on cap-talk this will probably all be old/known stuff,
>> but
>> > to make sure I communicate the urgency of my plea for a peer review of
>> the
>> > code of this library, let me draw a dense context.
>> >
>> > Some years ago I wrote a set proof of concept implementation of a set
>> of
>> > cooperating least authority providing user space file-systems for
>> AppArmor
>> > based Linux systems. This proof of concept was/is called MinorFS. For
>> some
>> > context, here is a Linux Journal article I wrote on this system 5
>> years
>> > ago.
>> >
>> > http://www.linuxjournal.com/magazine/minorfs
>> >
>> > At the core of these file systems was a sparsecap (or password
>> capability
>> > if you prefer that term) file-system called capfs. This file-system
>> was
>> > based on an sqlite database with sparsecap to path mappings.
>> >
>> > Some time later, I came up with an alternative hash based algorithm
>> that
>> > could possibly do away with the need of a database for capfs. After
>> asking
>> > feedback on this algorithm on the cap-talk mailing list, David Barbour
>> > suggested I' d use HMAC instead of just SHA.
>> >
>> > http://www.eros-os.org/pipermail/cap-talk/2012-February/015332.html
>> >
>> > Resulting from this feedback, and driven by the idea that a library
>> for
>> > sparsecaps that give access to a DAG shaped authority structure might
>> be
>> > usefull for other things than just a rewrite of Minorfs::capfs, I
>> recently
>> > created a C++ (c++11) library that implements the algorithm, using
>> > crypto++ for its hmac/sha2 crypto primitives.
>> >
>> > https://github.com/pibara/Rumpeltreepp
>> >
>> > This library basically implements the algorithm described here:
>> >
>> >
>> http://minorfs.wordpress.com/2014/02/20/rumpelstiltskin-and-his-children/
>> >
>> >
>> http://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and-his-children-part-2/
>> >
>> > Given the fact that my crypto knowledge and my knowledge regarding
>> > implementation and usage pitfalls is relatively limited, I desperately
>> > need a peer review on my Rumpleltree++ source code.  When the
>> file-system
>> > in finished, the logic in this library will become a pivotal part of
>> the
>> > TCB of any system built using the full set of file systems that will
>> be
>> > layered on them together with AppArmor. A rewrite of the original
>> MinorFS
>> > that wil aim at retrofitting the taming of shared mutable file system
>> > provided by MinorFS to non MinorFS aware applications in a way that
>> should
>> > help mitigate the effects that Trojans might have in a major way:
>> >
>> > http://www.slideshare.net/RobMeijer3/ohm2013-trojans-slides
>> >
>> > Thus, if anyone would be able and willing to contribute a peer review
>> to
>> > this library, you will be playing a crucial role in the ultimate goal
>> of
>> > creating a trojan free environment.
>> >
>> > Tnx,
>> >
>> > Rob
>> >
>> >
>> > On Fri, July 25, 2014 20:42, Rob Meijer wrote:
>> >> Just did a last bugfix. All tests run correctly and without memory
>> >> leaks.
>> >> Would anyone be interested in contributing a security-oriented
>> >> code-review
>> >> on my library? Its C++11 code and I took extra effort to make sure
>> >> memory
>> >> containing security sensitive authority tokens gets wiped after usage
>> >> while maintaining the friendly almost fully string like interface.
>> >>
>> >>
>> >>
>> >> T.I.A.
>> >>
>> >> Rob
>> >>
>> >> On Mon, July 21, 2014 14:11, Rob Meijer wrote:
>> >>> Oops, that one should have gone to cap-talk, not e-lang :-(
>> >>>
>> >>> On Mon, July 21, 2014 13:51, Rob Meijer wrote:
>> >>>> I thought some of you might be interested in the following.
>> >>>>
>> >>>> I've migrated my Rumpelstiltskin tree-graph algorithm code from
>> using
>> >>>> openssl to using crypto++, and from being some deep part of
>> MinorFS2
>> >>>> to
>> >>>> being its own hopefully more widely usable C++ library. Its still a
>> >>>> work
>> >>>> in progress (need to write a whole lot of extra tests, need to look
>> at
>> >>>> memory wiping that seems not to be working, and at writing a solid
>> >>>> cmake
>> >>>> config file without hard-coded llvm tools, but anyhow, I think its
>> in
>> >>>> a
>> >>>> state that its suitable to play around with a bit for those
>> interested
>> >>>> in
>> >>>> using it.
>> >>>>
>> >>>> https://github.com/pibara/Rumpeltreepp
>> >>>>
>> >>>> I'm very interested in any feedback, and if anyone thinks it
>> usefull
>> >>>> that
>> >>>> I've seperated my code from MinorFs2 into a seperate general
>> purpose
>> >>>> library.
>> >>>>
>> >>>>
>> >>>> The interface of the library is defined in rumpelstiltskin.hpp, and
>> an
>> >>>> API
>> >>>> usage example can be found in test.cpp.
>> >>>>
>> >>>>
>> >>>> Rob
>> >>>>
>> >>>> _______________________________________________
>> >>>> e-lang mailing list
>> >>>> [email protected]
>> >>>> http://www.eros-os.org/mailman/listinfo/e-lang
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> cap-talk mailing list
>> >>> [email protected]
>> >>> http://www.eros-os.org/mailman/listinfo/cap-talk
>> >>>
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> cap-talk mailing list
>> >> [email protected]
>> >> http://www.eros-os.org/mailman/listinfo/cap-talk
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > cap-talk mailing list
>> > [email protected]
>> > http://www.eros-os.org/mailman/listinfo/cap-talk
>> >
>> >
>>
>>
>> _______________________________________________
>> cap-talk mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
>