[Cryptech Core] about that agenda

[Vasily Dolmatov]

Agree with Rob.


> 1 авг. 2017 г., в 23:05, Rob Austein <sra at hactrn.net> написал(а):
> 
> I think the big agenda from the tech side is what in a more corporate
> environment would be called the "Requirements Doc" ("MRD", "PRD",
> "URD", call it what you like based on your own work history).  I don't
> propose to spend any significant amount of time writing an actual
> document for this, but the basic questions that go into an MRD are
> probably the right ones:
> 
> * Who's the target customer?
> * What does the target customer require? (must-haves)
> * What else would the target customer like? (nice-to-haves)
> 
> We've spent a long time focused on a hypothetical DNSSEC signer
> customer, with "a demo box that will run OpenDNSSEC" as the
> deliverable.  Other than speed of RSA (Pavel's working on that), we're
> done with that one at this point.
Yes, we have «proof of concept» box, which can be used for DNSSEC, but is hardly suitable
for production use, first of all due to its formfactor (it is a real pain in ass to place such box in 19»
rack and connect in to production server).
> 
> RPKI is sort of waiting in the wings, but it's all RSA-2048, so it's
> not worth pursuing until we have faster RSA, and in any case doesn't
> really get us anything new on the Cryptech side.
AFAIU it can be used now, provided RKCS#11 is working.

> 
> So I think a big part of the technical discussion we need to have is:
> what's next that's useful, new, and at least a bit different, whether
> that's new use cases driving new algorithms,
I am still waiting for GOST cores, which were postponed in favor of
DNSSEC signer box to be complete. :(
> new use case driving new
> hardware, whatever.
> 
> The reason I phrase it in terms of an MRD is that, like all
> developer-driven projects, there's a risk of falling into a pattern
> where we just work on whatever we think is important, without
> bothering to find out what users want, which would be a mistake. :)
Ordinary pitfall I would say ;) And we have falled there several times already,
choosing something «interesting» for us as developers. ;)
And I suspect that pitfall will continue to be the most dangerous one.
> 
> Response to Peter's message follows under separate cover.
I would respond here, because it is closely tied with MRD.

Current communication design was chosen considering speed demands for given
application scenario AND mitigating a number of security implications.

Changing it to other one I think is not driven by new demands (we have none yet)
and will lead to necessity to reconsider security of whole  device.

Moreover, If we will need more communication speed (remembering that now we
have performance bottleneck inside the box, not on the communication line) for
some not yet defined use case (channel enciphering for instance), then we should
reconsider usage of USB as communication interface at all (along with changing
of formfactor, used hardware, analyzing changed security threats and possible attack vectors, etc.)

I would followup Rob in reiterating that at this time we have «Alpha-board» completed
by design and having several glitches to eliminate, which process we unfortunately did
not complete since Berlin (a year has passed). :(

What we need now is to  define a vector of development of the project from the «Alpha-board»
to «Beta-device» starting from use cases definition, determining necessary changes in design,
analyzing how these changes will change the security of the device (maybe this will lead to
another set of changes in design) and after that creating a list of tasks to perform to create
«Beta-device".

dol@



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.cryptech.is/archives/core/attachments/20170802/92e52343/attachment.sig>