sdrapkin

5 ms·

1.
.NET: Avoid Using Guid.CreateVersion7(gist.github.com)
2 points by sdrapkin 11mo ago|1 comments
2.
by sdrapkin 11mo ago
Guid.CreateVersion7 in .NET 9+ claims RFC 9562 compliance but violates its big-endian requirement for binary storage. This causes the same database index fragmentation that v7 UUIDs were designed to prevent. Testing with 100K PostgreSQL ins
3.
Fcrand (Go language): drop-in replacement for crypto/rand, up to 10x faster(github.com)
14 points by sdrapkin 1y ago|6 comments
4.
by sdrapkin 1y ago
fcrand (fast crypto/rand) is a high-performance drop-in replacement for Go's crypto/rand.
5.
by sdrapkin 1y ago
No, Guid/uuids are defined as 128-bit labels used to uniquely identify objects in computer systems. This 128-bit/16-byte definition predates any RFCs that one may or may not choose to implement. I'm obviously aware of RFC 956
6.
by sdrapkin 1y ago
Agreed. So at worst they (Golang developers) should be indifferent, and at best they should opt for the faster choice. With serverless code billing by the second, faster choices are directly correlated to lower costs.
7.
by sdrapkin 1y ago
Amazon AWS S3 web servers process millions of requests per second, and each response generates a random Request-Id. It’s not exactly 16 bytes, but this is a very realistic scenario where guids are used in hot path. If you are writing a cute
8.
by sdrapkin 1y ago
Guid/uuid is defined as a 16-byte structure. Are you questioning the “byte” part, or the “random” part?
9.
by sdrapkin 1y ago
Fast guid/uuid generators are NOT a security risk. You want such generators to be as fast as possible, without compromising cryptographic strength.
10.
by sdrapkin 1y ago
The vast majority of Golang developers would benefit from using Guid library instead of UUID library. It’s substantially faster in all cases, more secure (by 2^6) and has more functionality. For random token-as-string generation Golang deve
11.
by sdrapkin 1y ago
> This shouldn't really matter as your import paths are obviously different. I'm aware of that, of course. Guid is intentionally named differently from "uuid" (both as a package and as a type) to ensure there is no co
12.
by sdrapkin 1y ago
You are correct - Guid very specifically and intentionally generates a structure of 16 random bytes. In decades of programming I've never needed a random 16-byte structure to have a "internal versioned structure". In very rar
13.
by sdrapkin 1y ago
Guid package generates guids/uuids. Your linked package generates variable length strings. These are different usecases (oh, and your benchmarks are inferior to https://github.com/sdrapkin/randstring ). Nothing to
14.
by sdrapkin 1y ago
cuid2 generates variable-length strings. If you want fast cryptographically strong string generation, I recommend https://github.com/sdrapkin/randstring . It will likely be faster than cuid2.
15.
by sdrapkin 1y ago
It's on the roadmap (already implemented in a similar .NET library - https://github.com/sdrapkin/SecurityDriven.FastGuid ).
16.
by sdrapkin 1y ago
In case you missed it, "guid.Read()" is a much faster alternative to "crypto/rand". https://pkg.go.dev/github.com/sdrapkin/guid#Read
17.
by sdrapkin 1y ago
IMHO "Guid" is just as well known (Wikipedia agrees: https://en.wikipedia.org/wiki/Universally_unique_identifier ), and "UUID" was already taken by Google.
18.
by sdrapkin 1y ago
Thanks for your feedback. If you are skilled in Golang, I suggest you review the code more thoroughly for a more accurate understanding (especially compared to what standard uuid does).
19.
by sdrapkin 1y ago
It generates entropy 4kb-at-a-time (instead of on each call), and uses a cache-pool instead of single cache behind a lock (which is what standard uuid does in "RandPool=ON" mode).
20.
Fast cryptographically safe GUID generator for Go(github.com)
20 points by sdrapkin 1y ago|41 comments
21.
by sdrapkin 1y ago
Much faster (~10x) than standard github.com/google/uuid package I'm interested in feedback from the HN community.
22.
by sdrapkin 3y ago
Indeed. But FIPS is not the only problem. Both the McGrew/Viega spec and subsequent NIST spec of GCM mandate a 4-byte counter - any departure from that would be "no longer GCM".
23.
by sdrapkin 3y ago
GCM (ie. AES-GCM) has the following problems, which extended variants - those that deterministically randomize (key,nonce) pair - do not solve: Inability to encrypt more than 64Gb with the same (key,nonce) pair. Lack of commitment (whether
24.
Show HN: Streaming chunked AEAD cryptography [pdf](github.com)
1 points by sdrapkin 4y ago|0 comments
25.
CryptoRandom – .NET Random done right(github.com)
1 points by sdrapkin 5y ago|1 comments
26.
by sdrapkin 5y ago
Modern, fast, safe, cryptographically strong .NET replacement for Random and RandomNumberGenerator.
27.
by sdrapkin 9y ago
"OMG, you're totally right - if only the OP knew that scrypt ends with pbkdf2.." Um, no. But thanks for playing. For those who wish to argue that everything that precedes PBKDF2 in scrypt should be considered as "key ext
28.
by sdrapkin 9y ago
The OP is referring to the OP-linked 18F writeup (you might want to read it), which says "Based on consultation with NIST we follow these steps..."
29.
Login.gov encryption is badly designed(gist.github.com)
67 points by sdrapkin 9y ago|36 comments
30.
RSA APIs in .NET(gist.github.com)
2 points by sdrapkin 9y ago|0 comments

More ›