HMAC cipher and a TRNG...

If anybody ever chooses to play around with my HMAC cipher, be sure to remove the call to the PRNG that is used to create the random numbers in the plaintext. Remove the call and replace it with a TRNG. It is meant to use a TRNG, but my experimental implementation uses Java's prng. My cipher is not even meant to be used with a CSPRNG! It needs a TRNG, damn it! I think it should be hard to find a period in a TRNG. For instance, is this a number? Think of a base 10 number where each digit uses a TRNG for its value, 0 through 9.
A decimal expansion with regard to digits, for instance:
TRNG().[TRNG(), TRNG(), TRNG(), ...]
Is this a number, or not a number.
A 10-ary die should be able to do this, right?
Here is an example of my HMAC Cipher example. You should all be able to examine the plaintext because it was encrypted using the default key. Now, keep in mind, that if I encrypted this again, it would have a different ciphertext. This is where I _really_ need to use a TRNG in a real impl, so to speak...
http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=7d1be1354c3747f47031d9957ada1d2eece3850f30739d202c7b3c8347d4e144dde0afb6626243b2a5c60434025d40f033f636c785d8f1e3b30ac1888d34c1ea4a1d33b8ed9ed114126291fc4cb7cfadb875355b269972d993bc91d5a464bdd74fc64daabaf95c92ee6b387b6d152a3f4b970a57c17764d1f4ce3513a001f9544b53f0f78d0db45783da1b3a43b4e194ba5ad7abc30422140033c587a1ccc8da843b30d341b74e01914ac26451e34ee3f4057ca1f7cc92d832157ad19664b9c96c7db724f168a3fbbc4cfedd7cdfc1a3fcfff84b46e4df556f87c63960df62140ae56d89db8af1b465e5599c1e23ecaad35fa40f5d92fe8a1dfa57ea5f5726a0d5300d93581de70d1ec8009105984c24ea9f9a3337e30dd995a59e36af4c44534db8c28d35d0c6e086043175be5022cf7e2750fb401a095d926afbdb7f4754d52565c96d12db47a317df026dee567bb15cc71ea378c114bf83be7ec65cdc56d5820caa6a01a823a14b9cdef1249cb3f6bf02cc4a7ff5c98f980c2a4a0f69c72bbfbf