Rfc4880bis Alternatives

Similar projects and alternatives to rfc4880bis

xxHash

28 8,939 8.0 C rfc4880bis VS xxHash

Extremely fast non-cryptographic hash algorithm
InfluxDB

www.influxdata.com featured

Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
dduper

6 166 5.4 Python rfc4880bis VS dduper

Fast block-level out-of-band BTRFS deduplication tool.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better rfc4880bis alternative or higher similarity.

Suggest an alternative to rfc4880bis

rfc4880bis discussion

rfc4880bis reviews and mentions

Posts with mentions or reviews of rfc4880bis. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-12-15.

NIST Retires SHA-1 Cryptographic Algorithm
3 projects | news.ycombinator.com | 15 Dec 2022

> The thing is, there doesn't seem to be any security weaknesses with the existing AE method. I have looked hard.
Even if nobody found any concrete security issues, there might be compliance reasons not to use SHA-1, as indicated by the OP. It's easier to switch to something new than to endlessly explain to auditors that actually in this particular case the use of SHA-1 is probably fine. Also note that there's no security proof for the MDC, making it harder to convince such auditors.
> There also doesn't seem to be any need for the AD (associated data) part.
I personally disagree: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145. The linked paper explains why having AD would be useful. But I'll grant you that the crypto refresh doesn't make significant use of it yet, so it can't really be counted as an advantage for AEAD yet.
> OCB seems to be the fastest out of all of them. If the proposal was just to add on OCB as an enhanced performance mode then I might be OK with that. Why make the people encrypting multi-TB files wait? I am mostly grumpy with the idea that we have to drop an existing well established standard for stuff like messaging and less extreme file sizes.
I'm not sure I understand what the concrete difference would be between what you're proposing and what the crypto refresh does? It introduces a new mode and encourages its use, but doesn't disallow the use of the current mode. Also, once OCB is widely deployed, why would you want to use CFB instead of OCB?