Re: [e-lang] RumpelTree++
David Barbour <[email protected]> Sun, 2 Nov 2014 22:59:04 -0600
| Newsgroups | gmane.comp.capabilities.general,gmane.comp.lang.e.general |
|---|---|
| Message-ID | <CAAOQMSvXchmhFXxaH_ezL4Hp8qFWieYHcabkCuW5=5KyiV4aRQ@mail.gmail.com> |
--===============0299017640954028603== Content-Type: multipart/alternative; boundary=f46d04374acdaa1bbc0506ed3476 --f46d04374acdaa1bbc0506ed3476 Content-Type: text/plain; charset=UTF-8 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 > --f46d04374acdaa1bbc0506ed3476 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">I've recently been contempl= ating Rumpelstiltskin hash trees for my current project, Wikilon, a wiki-ba= sed IDE and software platform oriented around my concatenative capability l= anguage, AO. Wikilon will provide a filesystem-like abstraction, albeit ori= ented around the language.=C2=A0</div><div class=3D"gmail_extra"><br></div>= <div class=3D"gmail_extra">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 neces= sary, e.g. conventional Type/ID/Auth/HMAC identifiers.</div><div class=3D"g= mail_extra"><br></div><div class=3D"gmail_extra">My second question is whet= her 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 aut= hority shortly after the help is performed.</div><div class=3D"gmail_extra"= ><br></div><div class=3D"gmail_extra">Seems to me that your Rumpelstiltskin= tree hash doesn't really offer any sort of attenuation on the temporal= dimension.=C2=A0</div><div class=3D"gmail_extra"><br></div><div class=3D"g= mail_extra">With the more conventional model, I could add a token to the Au= th field representing a revocable authorization-path of sorts, and offer a = few methods to attenuate the session. Such IDs grow large quickly. An appea= ling aspect of your hash trees is the constant size identifier.=C2=A0</div>= <div class=3D"gmail_extra">=C2=A0<br></div><div class=3D"gmail_extra"><br><= /div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Sun, Aug 3, 2= 014 at 4:53 PM, Rob Meijer <span dir=3D"ltr"><<a href=3D"mailto:rmeijer@= xs4all.nl" target=3D"_blank">rmeijer-qWit8jRvyhVmR6Xm/[email protected]</a>></span> wrote:<br><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= ing-left:1ex">Added a web page with some usage documentation:<br> <br> <a href=3D"http://pibara.github.io/Rumpeltreepp/" target=3D"_blank">http://= pibara.github.io/Rumpeltreepp/</a><br> <br> Anyone know a good place to find people who might be willing to contribute<= br> a security and crypto oriented code-review?<br> <br> <br> T.I.A<br> <span><font color=3D"#888888"><br> Rob<br> </font></span><div><div><br> <br> On Sat, August 2, 2014 13:03, Rob Meijer wrote:<br> > For most of you on cap-talk this will probably all be old/known stuff,= but<br> > to make sure I communicate the urgency of my plea for a peer review of= the<br> > code of this library, let me draw a dense context.<br> ><br> > Some years ago I wrote a set proof of concept implementation of a set = of<br> > cooperating least authority providing user space file-systems for AppA= rmor<br> > based Linux systems. This proof of concept was/is called MinorFS. For = some<br> > context, here is a Linux Journal article I wrote on this system 5 year= s<br> > ago.<br> ><br> > <a href=3D"http://www.linuxjournal.com/magazine/minorfs" target=3D"_bl= ank">http://www.linuxjournal.com/magazine/minorfs</a><br> ><br> > At the core of these file systems was a sparsecap (or password capabil= ity<br> > if you prefer that term) file-system called capfs. This file-system wa= s<br> > based on an sqlite database with sparsecap to path mappings.<br> ><br> > Some time later, I came up with an alternative hash based algorithm th= at<br> > could possibly do away with the need of a database for capfs. After as= king<br> > feedback on this algorithm on the cap-talk mailing list, David Barbour= <br> > suggested I' d use HMAC instead of just SHA.<br> ><br> > <a href=3D"http://www.eros-os.org/pipermail/cap-talk/2012-February/015= 332.html" target=3D"_blank">http://www.eros-os.org/pipermail/cap-talk/2012-= February/015332.html</a><br> ><br> > Resulting from this feedback, and driven by the idea that a library fo= r<br> > sparsecaps that give access to a DAG shaped authority structure might = be<br> > usefull for other things than just a rewrite of Minorfs::capfs, I rece= ntly<br> > created a C++ (c++11) library that implements the algorithm, using<br> > crypto++ for its hmac/sha2 crypto primitives.<br> ><br> > <a href=3D"https://github.com/pibara/Rumpeltreepp" target=3D"_blank">h= ttps://github.com/pibara/Rumpeltreepp</a><br> ><br> > This library basically implements the algorithm described here:<br> ><br> >=C2=A0 <a href=3D"http://minorfs.wordpress.com/2014/02/20/rumpelstiltsk= in-and-his-children/" target=3D"_blank">http://minorfs.wordpress.com/2014/0= 2/20/rumpelstiltskin-and-his-children/</a><br> ><br> > <a href=3D"http://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and= -his-children-part-2/" target=3D"_blank">http://minorfs.wordpress.com/2014/= 03/21/rumpelstiltskin-and-his-children-part-2/</a><br> ><br> > Given the fact that my crypto knowledge and my knowledge regarding<br> > implementation and usage pitfalls is relatively limited, I desperately= <br> > need a peer review on my Rumpleltree++ source code.=C2=A0 When the fil= e-system<br> > in finished, the logic in this library will become a pivotal part of t= he<br> > TCB of any system built using the full set of file systems that will b= e<br> > layered on them together with AppArmor. A rewrite of the original Mino= rFS<br> > that wil aim at retrofitting the taming of shared mutable file system<= br> > provided by MinorFS to non MinorFS aware applications in a way that sh= ould<br> > help mitigate the effects that Trojans might have in a major way:<br> ><br> > <a href=3D"http://www.slideshare.net/RobMeijer3/ohm2013-trojans-slides= " target=3D"_blank">http://www.slideshare.net/RobMeijer3/ohm2013-trojans-sl= ides</a><br> ><br> > Thus, if anyone would be able and willing to contribute a peer review = to<br> > this library, you will be playing a crucial role in the ultimate goal = of<br> > creating a trojan free environment.<br> ><br> > Tnx,<br> ><br> > Rob<br> ><br> ><br> > On Fri, July 25, 2014 20:42, Rob Meijer wrote:<br> >> Just did a last bugfix. All tests run correctly and without memory= <br> >> leaks.<br> >> Would anyone be interested in contributing a security-oriented<br> >> code-review<br> >> on my library? Its C++11 code and I took extra effort to make sure= <br> >> memory<br> >> containing security sensitive authority tokens gets wiped after us= age<br> >> while maintaining the friendly almost fully string like interface.= <br> >><br> >><br> >><br> >> T.I.A.<br> >><br> >> Rob<br> >><br> >> On Mon, July 21, 2014 14:11, Rob Meijer wrote:<br> >>> Oops, that one should have gone to cap-talk, not e-lang :-(<br= > >>><br> >>> On Mon, July 21, 2014 13:51, Rob Meijer wrote:<br> >>>> I thought some of you might be interested in the following= .<br> >>>><br> >>>> I've migrated my Rumpelstiltskin tree-graph algorithm = code from using<br> >>>> openssl to using crypto++, and from being some deep part o= f MinorFS2<br> >>>> to<br> >>>> being its own hopefully more widely usable C++ library. It= s still a<br> >>>> work<br> >>>> in progress (need to write a whole lot of extra tests, nee= d to look at<br> >>>> memory wiping that seems not to be working, and at writing= a solid<br> >>>> cmake<br> >>>> config file without hard-coded llvm tools, but anyhow, I t= hink its in<br> >>>> a<br> >>>> state that its suitable to play around with a bit for thos= e interested<br> >>>> in<br> >>>> using it.<br> >>>><br> >>>> <a href=3D"https://github.com/pibara/Rumpeltreepp" target= =3D"_blank">https://github.com/pibara/Rumpeltreepp</a><br> >>>><br> >>>> I'm very interested in any feedback, and if anyone thi= nks it usefull<br> >>>> that<br> >>>> I've seperated my code from MinorFs2 into a seperate g= eneral purpose<br> >>>> library.<br> >>>><br> >>>><br> >>>> The interface of the library is defined in rumpelstiltskin= .hpp, and an<br> >>>> API<br> >>>> usage example can be found in test.cpp.<br> >>>><br> >>>><br> >>>> Rob<br> >>>><br> >>>> _______________________________________________<br> >>>> e-lang mailing list<br> >>>> <a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a><br> >>>> <a href=3D"http://www.eros-os.org/mailman/listinfo/e-lang"= target=3D"_blank">http://www.eros-os.org/mailman/listinfo/e-lang</a><br> >>>><br> >>>><br> >>><br> >>><br> >>> _______________________________________________<br> >>> cap-talk mailing list<br> >>> <a href=3D"mailto:[email protected]" target=3D"_blank"= >[email protected]</a><br> >>> <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" t= arget=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br> >>><br> >>><br> >><br> >><br> >> _______________________________________________<br> >> cap-talk mailing list<br> >> <a href=3D"mailto:[email protected]" target=3D"_blank">cap= [email protected]</a><br> >> <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" targe= t=3D"_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br> >><br> >><br> ><br> ><br> > _______________________________________________<br> > cap-talk mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank">cap-tal= [email protected]</a><br> > <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" target=3D= "_blank">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br> ><br> ><br> <br> <br> _______________________________________________<br> cap-talk mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">cap-talk@mai= l.eros-os.org</a><br> <a href=3D"http://www.eros-os.org/mailman/listinfo/cap-talk" target=3D"_bla= nk">http://www.eros-os.org/mailman/listinfo/cap-talk</a><br> </div></div></blockquote></div><br></div></div> --f46d04374acdaa1bbc0506ed3476-- --===============0299017640954028603== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk --===============0299017640954028603==--