bascule

14 ms·

91.
by bascule 10y ago
Bitrot detection doesn't need a cryptographic hash. Not only is a cryptographic hash unnecessary, under certain circumstances it will actually do a worse job. Cryptographic hashes operate under a different set of constraints than e
92.
by bascule 10y ago
Though blockchain is an ill-defined term, this seems to be missing the most important part of one: consensus. Bitcoin achieves this in two ways: - Proof-of-Work, which effectively functions as a leader election algorithm - Consensus p
93.
by bascule 10y ago
For context, this is describing an updated AES-GCM-SIV construction following a number of attacks reported by NSA earlier this year: https://mailarchive.ietf.org/arch/attach/cfrg/pdfL0pM_N.pdf Several cryptog
94.
RFC 6920 – Naming Things with Hashes(rfc-editor.org)
3 points by bascule 10y ago|0 comments
95.
by bascule 10y ago
I'm glad you've at least looked into this, but you have a number of things wrong: First of all, it is not a single algorithm, it is a family of algorithms This argument holds for SHA1, but all modern cryptographic hash func
96.
by bascule 10y ago
Clearly it's not, because it's both several times slower than the CRC family, and was known to have cryptographic flaws before git was even released. "The worst of both worlds" so to speak...
97.
by bascule 10y ago
I am likewise perplexed why "cryptographic hash functions are unnecessary in the absence of an attacker" is such a difficult concept for you to grasp. It is not an "odd angle". It is literally the very purpose for which
98.
by bascule 10y ago
If you feel CRC64 does not meet the requirements, use CRC128. For what it's worth, I think CRC64 should be fine for git-like workloads (but would still recommend using a cryptographically secure hash function, because git's usage
99.
by bascule 10y ago
I absolutely believe git should use a cryptographically secure hash function. But you're completely missing my point, which is about Linus's claims that git's use of SHA1 isn't security-critical, but why he's using
100.
by bascule 10y ago
"maybe the 1 in a million collision chance for a few million hashes is too high" Well, let's look at what the actual numbers are. There's a nice table on this page: https://en.wikipedia.org/wiki/Birt
101.
by bascule 10y ago
You seem to be operating under the same sort of "cryptographic hash functions are magic!" delusions as Linus. CRC and SHA1 both produce a uniform distribution. SHA1 does not magically do this better because cryptography. The only
102.
by bascule 10y ago
There is nothing to be gained from using cryptographic primitives in a non-security context. You could just as easily use e.g. CRC32 for the case you're describing. There is, however, a performance cost in using cryptographic primitive
103.
by bascule 10y ago
Yes, exactly. If Linus truly doesn't care about security, then git could use any error correcting code that produces a uniform distribution of tags, such as CRC64. The size of the tag only affects the number of objects we'd expect
104.
by bascule 10y ago
Thanks for the link. Re: snark, I did hit "next in thread" but managed to skim over that in his response. But again, thanks anyway. (Note: this still sounds more like spitballing than "the plan", but at least it's a
105.
by bascule 10y ago
Yes this is possible. It's called a preimage attack: https://en.wikipedia.org/wiki/Preimage_attack It's computationally infeasible against most cryptographically secure hash functions. However, Grover's
106.
by bascule 10y ago
Can you please link me to "the plan" then? I have been trying to follow some of the ML discussion and that was the last plan I saw him put forth, e.g.: https://marc.info/?l=git&m=148787047422954
107.
by bascule 10y ago
Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 com
108.
Blockchains in a Quantum Future: Preventing Post-Quantum Cryptographic Attacks(blog.chain.com)
13 points by bascule 10y ago|0 comments
109.
Hidden in Plain Sight: Transacting Privately on a Blockchain(medium.com)
28 points by bascule 10y ago|0 comments
110.
by bascule 10y ago
Whenever someone asks this question, I point them at this... Learning Rust With Entirely Too Many Linked Lists: http://cglab.ca/~abeinges/blah/too-many-lists/book/ The point of this tutorial is not &quot
111.
by bascule 10y ago
Most key change events are innocuous, so a key change in and of itself carries much more noise than signal, in the same way most HTTPS errors are not MitM attacks but misconfigurations. Asking the proverbial Johnny to make a security decisi
112.
by bascule 10y ago
Neither was the Johnny Can't Encrypt issue. Now 1/7th of humanity is using E2E encryption. Making that happen involved some "security" vs usability tradeoffs (see my response here for the explanation of the scare quotes
113.
Key rotation, user experience, and crypto reporting(tonyarcieri.com)
4 points by bascule 10y ago|0 comments
114.
by bascule 10y ago
Why? Your GPG key is airgapped and inextricable (except possibly via something like a DPA-style attack), and you can set a PIN required to perform any private key operations, complete with a configurable number of attempts before the device
115.
by bascule 10y ago
Azul's C4 collector can handle 2TB heaps with "pauseless" (<50 microsecond) operation: https://www.azul.com/press_release/azul-systems-extends-supp...
116.
by bascule 10y ago
Came here to post this... yEnc is about as compact as you can get, and has been around for over a decade. Besides that, the Z85 encoding is the next runner up as a compact "string safe" encoding: https://rfc.zeromq.org&
117.
by bascule 10y ago
Security isn't an end in and of itself, it's a means to an end. A tool which delivers on security but isn't usable still fails to fulfill its purpose, in the same way an unplugged computer is both secure and useless. I know t
118.
Flaws in deterministic password managers(tonyarcieri.com)
196 points by bascule 10y ago|102 comments
119.
by bascule 10y ago
One of the requirements given in the OP (the one I was referencing in my previous post) is that the server can tell spam from non-spam without the client being online. The FHE solution doesn't work for this requirement. The functiona
120.
by bascule 10y ago
No, I didn't mean FHE, because FHE does not meet the criteria given in the post, namely that it must happen as quickly as possible and cannot rely on the liveness of the client. The OP practically rules out schemes that involve looping

More ›