[Cryptech Tech] core size in cryptech.h

[Basil Dolmatov]

dol@ с iPad

> 4 мая 2015 г., в 10:25, Joachim Strömbergson <joachim at secworks.se> написал(а):
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Aloha!
> 
> Павел Шатов wrote:
>> Speaking of core sizes, as far as I remember, we wanted to have 
>> different segments for different types of cores. All hashes can be
>> in one segment and have the same size. ECDSA is a signature core, we
>> can place it in a different segment, where all cores will have
>> different size and so on.
> 
> Yes. And as long as we don't run out of address space in a segment I
> think grouping cores makes sence. We have five out of eight possible
> segments allocated so we do have a lot of headroom still. The globals
> segment could probably be squeezed a bit if it starts getting cramped.
> But for now I think we should just use what we have. As long as we can
> have the core sizes a bit different for modexp, ecdsa for example.
> 
> We could also bikeshed a bit about if math is the best name for the
> segmemt that supports rsa, ecdsa. I don't know how generic re curves
> your core. But for modexp the name works.
> 
> One similar issue is cipher modes. Having things like ctr, gcm in
> ciphers is straight forward. But should keywrap also be there. And for
> keywrap I would appreciate thoughts from you, Rob, Paul and anyone else
> how the use case should be.
Being "anyone else"...
> 
> Basically we want to be able to write read and write wrapped keys and
> wrap/unwrap keys stored in RAM inside the FPGA. But we then would also
> like to be able to send unwrapped keys to the other cores (or have them
> read from a common key memory.) (Having the CPU transfer the unwrapped
> keys would make the wrapping rather meaningless ;-)
Wrapping has no goal to wrap keys traversing between parts of the device.
(Especially, inside tamper boundary)

Wrapping is used for sending keys to other party along network.


> 
> This might mean that we need to add an internal top level controller/DMA
> unit (which could have addresses in the globals.) inside the FPHA. The
> controller can perform read/writes on the internal bus for us. Or some
> other mechanism. Thie controller would then also be able to access
> addresses the CPU can't.
> 
> 
> 
>> Joachim, we really need to write down what cores we have right now.
>> Can you update that memory map, that I created along with baseline
>> project?
> 
> Sure. I will update the cryptech.h and the RTL with all cores (aes,
> chacha are the main ones not in there). Where is the document in the repo?
> 
> - -- 
> Med vänlig hälsning, Yours
> 
> Joachim Strömbergson - Alltid i harmonisk svängning.
> ========================================================================
> Joachim Strömbergson          Secworks AB          joachim at secworks.se
> ========================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQIcBAEBCAAGBQJVRx76AAoJEF3cfFQkIuyNy9QP/0iIhC6cOQZLi7390i7MKD6f
> Rbf9pbMvA3FE6oegyaN/EtyPeuYZvGTSMjpBxm62js39mQA73s22krtEU256Zyp2
> iGSk8jXI69RbVwPrD/4xJTlYaHsGzeOnoydNYTRmTf1srqCvPfvzlE5ZET33mAi7
> yznLL2v3k5arJetx19JS/RG/7t74eHVI07LywRheTczJUJ0qf7LS4x4Oar9bph8l
> u+zWPLnjbaviX72QaV++II3uri8FiEF7I3n5EFu5fBpSOZoV6YDRZeU7RqtI2azW
> ep67y9z7O8sAK1z/uabvKoeGkOidzLeREbpYy0HVFNxaql1UJkmE6Af42dBtQUVr
> RFHDoPobCK91jAR9/YjvM8Lg6smgsGPH2C16OvdhaL90t9JVpj5cYuzGNsieeDvV
> KJzaZw9E9hXxPBmT8njJqFj/9k0c63ZTt/fUc1lTTktpWmnoijCdYIEqNxaYZwRq
> cGjYRFvkUJfeYyoxxr+W/1olg7v6ZPvdrJyky3iMpTxvUkqkjF5gnIpI4kuNKgP/
> MdxdY4sr0O4HxlL4PksbisVcB7JUgm43QkWx9c4aPyzqq8ILATan467fF1B5TQis
> eKlFPDrE81r+ZJTrBkRTP0P6mQO0edoFwB60Zx7JLWY7GTydDyCZdqAZWMw8lHqU
> pU761DgVTj14CkFR8VYg
> =XHGr
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech