[Cryptech Core] Questions regarding existing documentation

Randy Bush randy at psg.com
Mon Aug 10 21:25:22 UTC 2015


[ my personal opinion ]

swedes are sun-struck, so may be slow to respond.

> I've gone through every page listed in the trac sitemap

we have a badge waiting for you.  tinfoil, of course.

> 0. Is the ASIC still under consideration, or is that to be recorded as a
> path not followed? (query re:
> http://trac.cryptech.is/wiki/ASICImplementations)

yes, probably after alpha and beta, whatever that is.  the verilog is as
compatible as reasonably possible, but would need significant board
redesign and asics are not fun to burn.

> 1. With the Novena board as the prototype of choice, do we want/need the
> documentation on the TerasIC C5G Board? (query re:
> http://trac.cryptech.is/wiki/CoretestHashesC5G)

imiho, no

> 2. For the pages that include a plan or roadmap (e.g.,
> http://trac.cryptech.is/wiki/AlphaBoardStrategy) are there tickets or
> publicly archived email thread that document the specific items for
> reference?

chaos reigns

> 3. The following git repositories listed on the top level git
> repositories page do not have README files. Are these repositories still
> in use, and if so, who will write the README files for them?
> core/math/modexps6
> doc/design
> doc/presentations
> test/external_avalanche_entropy
> user/ft/stm32-dev-bridge
> user/js/test/novena_eim_base
> user/paul/releng
> user/shatov/gost/streebog_tester
> user/shatov/gost/streebog

the engs responsible for each need to speak for them (and write the
READMEs).  but i think that many are in process of moving to releng
status and some sort of organization.  

rob will be far better at explaining.  but we are caught between two
philosophies.  one is to create arbitrary and many repos and tie some
together when you want to make a coherent bundle (e.g. a release).
see
  https://lists.cryptech.is/archives/core/2014-October/000603.html
  https://lists.cryptech.is/archives/core/2014-October/000602.html

some of us come from more formal cultures.  we're trying to be polite.

> 4. Having the list of git repositories in one place is a good thing. Is
> there any reason not to link to specific repositories and/or READMEs in
> the body of the documentation on the wiki?

> 5. Not all git repositories shown in the trac sitemap are listed on the
> master Git Repositories page. Is there any reason not to include these
> on the master page for a single complete list of active repositories?
> Examples:
> GitRepositories/core/aes
> GitRepositories/core/avalanche_entropy
> GitRepositories/core/chacha
> GitRepositories/core/cipher
> ...
> These and other repositories can be found when going to to sub-pages
> like GitRepositories/core or GitRepositories/comm. I do not propose
> removing the sub-pages, but it seems odd to have a top level page that
> doesn't have everything, unless there's a reason for it (i.e., those are
> the pages someone wanting to play around with cryptech will need,
> whereas the other pages might be archival at this point).

another project, DRL rpki software, managed to make a rather complex
wiki, where install has many pages referencing eachother, hunks of
source and binaries, ...  after losing a grad student to the twisty
passages, i finally wrote a one-page (not short), installation recipe,
takes an hour, serves ten.

paul may save me from doing that here out of anger (in the german
sense).

> 6. There is one team member bio on the site and two pointers to off-site
> bios. Are other team members going to put information up? It makes for
> interesting reading when talking about the project. (query re:
> http://trac.cryptech.is/wiki/WhoWeAre)

it would probably be polite.

> 7. Do you want to keep the list of SSH keys from the Praha workshop on
> the wiki? (query re: http://trac.cryptech.is/wiki/PrahaWorkshopSSH)

if things go well, this would grow and be unmanageable.  so it will
probably be per workshop.  having the previous ones could be useful,
and poses no threat.

> 8. Is the Project Management page still useful and/or required? If you
> are using the ProjectManagement page to help make clear the resources
> required as you ask for funding, perhaps include the time frame
> expected? This page begs the question: 4-5 FTE for how long? Travel &
> Overhead of $7K per month for how many months?

dump it

> 9. Should early prototype work be moved to an archive at this point?
> (query re: http://trac.cryptech.is/wiki/RoughV1)

seems reasonable to me

> 10. Should the 2014-11-06 state of play be moved to an archive at this
> point? Can I convince anyone to write an update? (query re:
> http://trac.cryptech.is/wiki/StateOfPlay)

it is a good piece but outdated.  i am not sure it is worth maintaining
as it is considerable work.  interested in hearing opinions.

> 11. Was the SUnet funded work completed? Should this page be updated or
> moved to an archive? (query re:
> http://trac.cryptech.is/wiki/SunetInitialDevelopment)

archive

> 12. As the project has settled on a source of randomness, can this page
> be removed and the link added to Related Work? (query re:
> http://trac.cryptech.is/wiki/TRNGDevelopment)

yep

entropy and randomness are non-terminating obsessions for folk working
in this area.  we should document the trng on each board as part of the
product design page(s).  we have not done a good novena platform page,
  o overview
  o tech
  o repos
  o upper layer repos (e.g. where do ggm & lacnic put their rpki?)
  o install and use recipe(s)
  o logistics (how to acquire parts and assemble)

randy



More information about the Core mailing list