David E. Wheeler
David E. Wheeler
> but until the Mac package supports that interface there is no way to iterate over all the keys aside from using the PrimitiveSet, yes? Sorry, that just applies to...
> I think that approximates the new methods pretty well, and they work for my use case nicely. When I'm able to upgrade, I should be able to eliminate this...
>> We are planning to add similar types for other primitives as well. Would that help? > > Yes, I believe so, as long as it iterates over all keys,...
> That's assuming that `Entry.Key()` will allow me to use type assertion to get a `MyKey` (or AEAD or MAC). And that `Entry.Key().Paramters()` will let me get at params I...
> Yes, one would have to use the type to distinguish the key type, e.g.: I guess that's do-able, but it means I'd have to map URLs to Tink-internal types....
And I just realized an issue without access to the primitives: my code was using the Prefix for my key, not from the aead key. I can change that, but...
One last thing: how do I implement and integrate a `key.Key` for my key? I need a way to get at my params (field 2): ```proto message MyKey { uint32...
I was able to get everything to work. However, to access the params in my key, I had to hack a public function into tink in theory/tink-go@e36b890. I could find...
> One way to get a primitive for each key (without casting) is to import the key into a new keyset with only that key, and get the primitive out,...
I managed to get everything cleaned up and working perfectly using the aforementioned theory/tink-go@e36b890. The upshot to all this, I think, is then need for key implementations without access to...