Readit News logoReadit News
Genbox commented on XOR_singleheader: Header-only binary fuse and XOR filter library   github.com/FastFilter/xor... · Posted by u/klaussilveira
Genbox · a month ago
I ported BinaryFuse filter to C#, along with tests and benchmarks. BinaryFuse filter is an incredibly clever data structure.

https://github.com/Genbox/FastFilter/tree/master

Genbox commented on Fibonacci Hashing: The Optimization That the World Forgot   probablydance.com/2018/06... · Posted by u/juancampa
Genbox · 5 months ago
I opened this post in a tab 3 days ago, but now it says "5 hours ago". Someone is playing around.
Genbox commented on Extracting DNA from the air – DNA evidence of human occupancy in indoor premises   nature.com/articles/s4159... · Posted by u/punnerud
serf · 6 months ago
>so DNA and fingerprints work just fine almost all the time.

except for all of those innocent folks that have had their lives ruined by that 'almost all the time' caveat, it's great!

here's a report[0] that says something like 80% + of criminal forensic work has major mistakes within it.

[0]: https://www.criminallegalnews.org/news/2024/may/15/report-fi...

Genbox · 6 months ago
A few years ago i picked up the old (but famous) cases of Brad Cooper and Casey Anthony as they have tons of available digital forensics evidence.

I double-checked the forensics work and found several mistakes in processes, assumptions and technical conclusions. I sent off my findings to people associated with Project Innocence - not because I found anything that proved Cooper or Anthony's innocence, quite the opposite. Instead, I wanted to let them know that forensics experts can make mistakes.

It is interesting that scientific work have fault-finding processes like peer-reviews, but forensics investigations in court cases does not.

Genbox commented on Why Tracebit is written in C#   tracebit.com/blog/why-tra... · Posted by u/mrcsharp
ngrilly · 7 months ago
I recently inherited a C# code base at work. I agree that C# is a powerful, productive, and mature language, but as someone who has been programming mainly in Go, Python, and a bit of Zig over the past few years, there are a few things that feel like a regression in C#:

- The absence of free-floating functions (everything is an object, and I must use static methods on static classes).

- When “using” a namespace, the convention is to make all the symbols in the “used” namespace available directly in the current namespace. That makes harder to know where symbols are coming from when reading code. And to avoid name collisions, people tend to use longer names. The convention in Go or Rust is to prefix most symbols with the package they are coming from. But perhaps I’m missing something and need to read/write more C#.

- The syntax for doc comments with tags such as <summary> is super verbose. I don’t see the point. Docs are working great without these tags in other languages. Reminds me of my J2EE days.

- I really prefer the name before type syntax (used in all new languages such as Go, TypeScript, Go, Swift, Kotlin, Zig, etc.) to the type before name syntax (used in C#, C, C++, Java, Dart).

Genbox · 7 months ago
C# started as a language tightly aligned with C++/Java, but has since moved to be something else entirely that is highly capable.

I assume that free-floating functions are global functions. You can achieve something similar by "global using". Put this in a file and tug it away somewhere:

"global using static YourStaticClass;"

Now you can call all the static methods on the class everywhere.

As for the using vs. naming convention, most people use the IDE and hover the mouse over the type to see its identity. Once you get proficient with the IDE, you can do it using shortcuts. However, if you really want to prefix all types with a shorthand of the package it came from, you can do it with aliases in C#.

Genbox commented on K4 – High performance open-source transactional, durable embedded storage engine   github.com/guycipher/k4... · Posted by u/alexpadula
alexpadula · 10 months ago
Hello everyone! I hope you are all well.

I've been working on a few storage engine designs recently implementing an LSM tree and would like to share K4.

K4 is a storage engine written completely in GO with no dependencies. The write speed surpasses RocksDB (7.8.3) with similar configuration.

I will write way more comprehensive benchmarks down the line.

The current features of K4

------------------------------

- High speed writes and reads

- Durability

- Variable length binary keys and values. Keys and their values can be any length

- Write-Ahead Logging (WAL). System writes PUT and DELETE operations to a log file before applying them to the LSM tree.

- Atomic transactions. Multiple PUT and DELETE operations can be grouped together and applied atomically to the LSM tree.

- Paired compaction. SSTables are paired up during compaction and merged into a single SSTable(s). This reduces the number of SSTables and minimizes disk I/O for read operations.

- Memtable implemented as a skip list.

- In-memory and disk-based storage

- Configurable memtable flush threshold

- Configurable compaction interval (in seconds)

- Configurable logging

- Configurable skip list

- Bloom filter for faster lookups. SSTable initial pages contain a bloom filter. The system uses the bloom filter to determine if a key is in the SSTable before scanning the SSTable.

- Recovery from WAL

- Granular page locking

- Thread-safe

- TTL (time to live) support

- Optional compression support (Simple lightweight and optimized Lempel-Ziv 1977 inspired compression algorithm

- Range and equi functionality (Get, NGet, Range, NRange, GreaterThan, GreaterThanEq, LessThan, LessThanEq)

- No dependencies

I am in the process of writing a C binding for K4 which will enable me to write FFI's for multiple other languages like Python, Node.JS, Ruby, etc.

I hope you get a chance to check it out and do let me know your thoughts!

Thank you kindly.

Genbox · 10 months ago
Do you have any regrets about an algorithm/data structure and wish you picked something else?
Genbox commented on Saturated fat: the making and unmaking of a scientific consensus (2022)   journals.lww.com/co-endoc... · Posted by u/mgh2
KempyKolibri · 10 months ago
Before anyone gets too excited, best to remember that Nina is regarded as something of a joke in nutrition science circles, and tends to take poetic license with the truth.

If you’d like to take a look at a critical review of her other work on this topic, I’d highly recommend this damning analysis of her “Big Fat Surprise” book: https://thescienceofnutrition.wordpress.com/2014/08/10/the-b...

Genbox · 10 months ago
"Maasai" is the correct spelling. They explain it on their website [1]

[1] https://maasai.com/conservation/maasai/

Genbox commented on Becoming physically immune to brute-force attacks (2021)   seirdy.one/posts/2021/01/... · Posted by u/emurlin
kragen · 10 months ago
Hmm, isn't it?
Genbox · 10 months ago
It isn't. You cannot derive an arbitrary length key with bcrypt.
Genbox commented on WordPress.org's latest move involves taking control of a WP Engine plugin   theverge.com/2024/10/12/2... · Posted by u/lsaferite
maxloh · a year ago
> Where is the CVE? What risk is there continuing to use the original plugin?

Here’s the diff showing what has changed: https://plugins.trac.wordpress.org/changeset?new=3167679%40a...

Genbox · a year ago
For those reviewing the changeset: There are two places where they read a value directly from $POST into an $args array. There is no validation applied, which means an attacker can inject whatever value they wish.
Genbox commented on Making CRC calculations in Mojo 18x faster than Python and 3x slower than Python   fnands.com/blog/2024/mojo... · Posted by u/fnands
onethumb · a year ago
FYI, I forked and improved [1] a Rust implementation that supports both table- and SIMD-accelerated CRC-64/NVME [2] calculations. The SIMD-accelerated (x86/x86_64 and aarch64) version delivers 10X over the table (16-bytes at a time) implementation.

The original implementation [3] did the same thing but for CRC-64/XZ [4].

[1]: https://github.com/awesomized/crc64fast-nvme

[2]: https://reveng.sourceforge.io/crc-catalogue/all.htm#crc.cat....

[3]: https://github.com/tikv/crc64fast

[4]: https://reveng.sourceforge.io/crc-catalogue/all.htm#crc.cat....

Genbox · a year ago
How does it compare to the built-in CRC32 instruction? [1]

[1] https://www.intel.com/content/www/us/en/docs/ipp/developer-g...

Genbox commented on Malicious SHA-1 (2014)   malicioussha1.github.io/... · Posted by u/greyface-
purkka · a year ago
> H0(H1(m)) has the security of just H0. Hashes are not made to protect the content of m, but instead made to test the integrity of m. As such, a flaw in H0 will break the security guarantee, no matter how secure H1 is.

But this isn't true for all flaws. For example, even with the collision attacks against SHA-1, I don't think they're even remotely close to enabling a collision for SHA-1(some_other_hash(M)).

Similarly, HMAC-SHA-1 is still considered secure, as it's effectively SHA-1-X(SHA-1-Y(M)), where SHA-1-X and SHA-1-Y are just SHA-1 with different starting states.

So there's some value to be found in nesting hashes.

[1]: https://en.wikipedia.org/wiki/HMAC#Definition

Genbox · a year ago
We are saying the same thing. H0 is SHA-1 in your example.

The strength of an HMAC depends on the strength of the hash function; however, since it uses two derived keys, the outer hash protects the inner hash (using the same hash function), which in turn provides protection against length extension attacks.

The case I was making, is that weakhash(stronghash(m)) has the security of weakhash, no matter how strong stronghash is.

u/Genbox

KarmaCake day551July 25, 2011
About
My name is Ian (Denmark) and I do science, security, algorithms, software architecture and high-performance stuff.

I built Farseer Physics Engine 3.0, SimpleS3 and about 25 other open source projects. Check them out over at https://github.com/genbox

I am also the founder and director of Chronos, a platform for investigating large-scale security incidents using forensics techniques.

View Original