Thomas Holenstein

(Closed)

This is a reasonable request, but it has been open for more than 4 years and it is clear that we will not get to this any time soon.

We agree that this should exist, but we do not have the headcount to consider working on this at the moment.

This feature request does not align anymore with what we aim for Tink to be. We currently do not have a lot of resources to maintain AndroidKeysetManager, and hence adding...

Thanks for the report. I think the issue here is that you call "GetPrimitive" in each thread separately. In Tink, GetPrimitive can be slow and performs optimizations. It also may...

I will close this so I have a better overview of open work items and since I assume that this is resolved. If this is still an issue, please reopen.

Thanks for insisting, I can reproduce this. Doing a thread dump with 5 threads I get that 2 of them are blocked as follows: "4" tink-crypto/tink#18 prio=5 os_prio=0 cpu=34757.19ms elapsed=41.17s...

Looking at it some more, a full stacktrace looks like this: java.lang.Thread.State: BLOCKED (on object monitor) at sun.security.provider.SecureRandom.engineNextBytes([email protected]/SecureRandom.java:222) - waiting to lock (a sun.security.provider.SecureRandom) at sun.security.provider.NativePRNG$RandomIO.implNextBytes([email protected]/NativePRNG.java:537) at sun.security.provider.NativePRNG.engineNextBytes([email protected]/NativePRNG.java:221) at java.security.SecureRandom.nextBytes([email protected]/SecureRandom.java:758)...

I will try to describe my current understand here. There might be bugs, I'm mainly writing this down in the hope that this helps me understand. Let's say we call...

I think I understand somewhat better now. In the end, the job of the RandomIO object above is to read from /dev/urandom or /dev/random. It produces a mix of a...