This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-11
Channels
- # architecture (1)
- # babashka (61)
- # babashka-sci-dev (1)
- # beginners (85)
- # calva (112)
- # clj-kondo (279)
- # cljdoc (16)
- # cljs-dev (15)
- # cljsrn (7)
- # clojure (168)
- # clojure-europe (36)
- # clojure-nl (10)
- # clojure-spec (6)
- # clojure-uk (5)
- # clojured (1)
- # clojurescript (20)
- # core-async (16)
- # crypto (2)
- # cursive (13)
- # datomic (25)
- # events (7)
- # fulcro (21)
- # google-cloud (3)
- # graalvm (2)
- # graalvm-mobile (2)
- # gratitude (3)
- # helix (20)
- # honeysql (4)
- # hugsql (15)
- # introduce-yourself (15)
- # leiningen (2)
- # lsp (24)
- # luminus (22)
- # malli (21)
- # meander (11)
- # midje (1)
- # other-languages (1)
- # pathom (8)
- # re-frame (5)
- # reagent (5)
- # releases (2)
- # reveal (1)
- # shadow-cljs (18)
- # spacemacs (17)
- # sql (9)
- # tools-build (12)
- # tools-deps (4)
- # vim (12)
#crypto
<
2022-02-11https://github.com/weavejester/crypto-random/issues/9 Currently, this library uses SecureRandom, which defaults to SHA1PRNG. I try to read up on SHA1PRNG, there are some really broken impls (Android 2013 or so).
Also, I found out that SHA1PRNG, with a state space of 160 bits, cannot generate more that approx 2^160 combinations of random values. A key of 256 bits, is not truly random, but restricted to a 2^160 bit combinations. It is somewhat surprising that most Java things still uses the default SecureRandom.