Re: [e-lang] RumpelTree++

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.

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. 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.

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
>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk