Re: ECC keygen for PR #528 ("Attestation driver and proxy")

Hi Nicolai,

On 4/29/25 6:46 PM, Nicolai Stange wrote:
> Hi Stefano,
> 
> Stefano Garzarella <[email protected]> writes:
> 
>> On Wed, 16 Apr 2025 at 16:08, Nicolai Stange <[email protected]> wrote:
>>>
>>> I managed to carve out and cleanup the first batch ([1]) from my work on
>>> an encrypted FS by now. The FS cleanup itself is still WIP, but the
>>> crypto parts should be in a usable state.
>>>
>>> As mentioned on last week's svsm-devel call, it might help with
>>> addressing those stack size related issues with ECC keygen in the
>>> context of PR #528 ([2]).
>>>
>>> I prepared some example code for generating an ECC key with NIST P-521,
>>> to be found at [3].
>>>
>>>  From some lax experiments in userspace, peak stack usage is at about 2.3kB.
>>> (Which is still way above what I would have expected, given that no
>>>   buffers are stored on the stack. I'm currently investigating that).
>>>
>>> I'm not sure whether merely generating the key is all you need -- FWIW
>>> there's also support for ecdh, ecdsa and ecschnorr, in case you're
>>> wondering. I'd be happy to come up with some example code for these as
>>> well.
>>>
>>> Please let me know if you have any questions, either here or in today's
>>> call.
>>
>> Cool, thanks for the example code, I guess this can unlock for now
>> Tyler's PR and FS support, but as we discussed yesterday in the
>> community call, the long term plan is to use OpenSSL/BoringSSL. I'll
>> open an issue ASAP to track that work, and I'll start to investigate
>> it.
> 
> I've implemented a BoringSSL FFI backend as a configurable alternative
> to the cocoon-tpm-crypto now (example code is updated accodingly), and
> did a POC integration into SVSM, c.f. [4]. Good news is it still boots :)
> 

Thanks for this. I'm currently updating PR #528 to use cocoon-tpm-crypto 
for generating ECC keys. For now, should I err towards using the 
BoringSSL feature?


Tyler