Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

So, you want to crypto

blog.existentialize.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: So, you want to crypto

#41

Post by EpicEng »

phaus wrote: post #25
EpicEng wrote: post #9

Earlier quoted context omitted.

But how many people are going to be interested in a crypto product which is unproven? Sure, perhaps a few technical types will give it a whirl, but most people just want something that works. If I'm in the market for something like this I'm certainly not going to use a product with a big disclaimer stating "Hey, we don't really know if this works yet, but help us test it out!" This is mission critical stuff, not some…

How many people would have been interested in a digital currency when it was worthless and not accepted as a form of payment anywhere? Perhaps the general population won't be interested, but techies are often willing to play around with unproven technologies.

I suppose that's fine as long as your target market is techies, but that is pretty limiting. Also, BTC is pretty unproven and, with massive volatility, unsustainable. If it doesn't improve it will never gain wide adoption.

Re: So, you want to crypto

#42

Post by alinajaf »

haberman wrote: post #40

I'm curious to hear people's thoughts about git. Git is "crypto" to some extent, Linus does not appear to have tons of crypto expertise, and it uses SHA1 as a MAC AFAICT (which according to tptacek's earlier comment is invalid). And yet I've never heard about attacks on its crypto. This was interesting for me to think about because it seems like a counterpoint to the article, in that it is a very successful project t…

AFAIK the only "crypto" in git is GPG used to sign tags.

The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents.

If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object with that SHA1[1].

Maybe there's some other mechanism in Git that you're referring to that uses SHA1 as a MAC that I'm perhaps unaware of?

[1]: http://stackoverflow.com/questions/9392365/how-would-git-han...

Re: So, you want to crypto

#43

Post by alinajaf »

plg wrote: post #37
alinajaf wrote: post #36

Earlier quoted context omitted.

This is a good choice. One of the challenges had me stuck for months because I hadn't realised that you really need fine-grained control over bitshifting that e.g. Ruby doesn't appear to give you. Taking twenty minutes to re-write my solution to that challenge in C sorted it out straight away.

I'm presently stuck on #6 in problem set 1...

Yeah, that ain't it! I'd warn you that it gets much tougher in later challenges. The beginning of set three resulted in many, many pages of ones and zeros in my notebook. All good fun though!

Re: So, you want to crypto

#44

Post by alinajaf »

derefr wrote: post #38

> And don't make your cryptography project sound like snake oil. Saying military grade encryption or N-bits of security makes you sound like you don't know what you're talking about. Interesting to contrast this with patio11's statement from just a few days ago ( https://training.kalzumeus.com/newsletters/archive/sco_remin... ): > People are better at remembering images than they are remembering claims or facts. "256…

For Joe Public, you say "Bank Level Security", for hackers you drill down into the details. There's no reason why your marketing material can't give the visual security imagery that people want and then walk through the exact countermeasures you're taking on your security page.

N.B. Patrick also says to use your powers for good rather than for evil :)

Re: So, you want to crypto

#45

Post by haberman »

alinajaf wrote: post #42
haberman wrote: post #40

I'm curious to hear people's thoughts about git. Git is "crypto" to some extent, Linus does not appear to have tons of crypto expertise, and it uses SHA1 as a MAC AFAICT (which according to tptacek's earlier comment is invalid). And yet I've never heard about attacks on its crypto. This was interesting for me to think about because it seems like a counterpoint to the article, in that it is a very successful project t…

AFAIK the only "crypto" in git is GPG used to sign tags. The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents. If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object…

Git assumes that a matching SHA1 means that the content is equal to the original content. Is that not crypto? For example, if you sign a tag, it appears to sign the SHA1 of the associated content.

This is definitely outside of my expertise, so I'm sure that my understanding is incomplete. The larger questions for me are:

- if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes?

- is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply?

Re: So, you want to crypto

#46

Post by Nursie »

haberman wrote: post #45
alinajaf wrote: post #42

Earlier quoted context omitted.

AFAIK the only "crypto" in git is GPG used to sign tags. The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents. If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object…

Git assumes that a matching SHA1 means that the content is equal to the original content. Is that not crypto? For example, if you sign a tag, it appears to sign the SHA1 of the associated content. This is definitely outside of my expertise, so I'm sure that my understanding is incomplete. The larger questions for me are: - if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from soft…

SHA1 is a hash. That alone does not make it 'crypto'. It's just a hash.

It happens to be a hash with fairly good collision resistance. Maybe not the best we have for modern crypto purposes, but that's not what it's being used for. It's being used to check and record unique tags for patches (as far as I know, my git knowledge is far from complete).

Cryptography does concern itself with data integrity but the reverse does not have to be true if you're not talking about part of a system you care about mitigating attacks on.

That's my take anyway.

--Edit-- for completeness I should add that SHA1 by itself is absolutely not a MAC

Re: So, you want to crypto

#47

Post by alinajaf »

haberman wrote: post #45
alinajaf wrote: post #42

Earlier quoted context omitted.

AFAIK the only "crypto" in git is GPG used to sign tags. The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents. If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object…

Git assumes that a matching SHA1 means that the content is equal to the original content. Is that not crypto? For example, if you sign a tag, it appears to sign the SHA1 of the associated content. This is definitely outside of my expertise, so I'm sure that my understanding is incomplete. The larger questions for me are: - if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from soft…

I'm not a cryptography expert either, but I'll give this a crack...

In as much as SHA1 is a "cryptographic hash function", Linus isn't taking advantage of a few of it's cryptographic properties in his usage of it in git. It would for example, make no difference to the workings of git if you could reverse-engineer the contents of an object from its SHA1. In the same way, it doesn't matter much to the operation of git that you can generate collisions for SHA1, though if you were running into collisions all the time, it would make everyday usage difficult.

> if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes?

If I'm understanding you correctly, software that "uses cryptographic primitives for useful purposes" is usually trying to guarantee one or more of the following:

* Confidentiality - Keeping data secret

* Integrity - Making sure data hasn't been tampered with

* Authentication - Making sure that the person you think sent the data is in fact the person who sent the data.

* Non-repudiation - Ensuring that the person who sent the data can't deny that they in fact sent the data.

Git makes guarantees about none of the above in its usage of SHA1. You could argue that it makes a guarantee of integrity in its content addressable file store, but it doesn't. If you can modify the files in the .git/ directory, you can screw up the repository to your hearts content. There's no way to do so remotely, i.e. by creating and pushing a Git commit with an existing SHA1. You typically protect Git from local tampering by only allowing access via SSH, which has plenty of crypto in it.

When it does make guarantees about authentication (signing tags) it uses GPG more or less off the shelf. In that case the SHA1 is a reference to a commit object, and you're saying that "I, Najaf Ali, sign off on the commit with this SHA1". It doesn't guarantee anything about the contents of that commit if the repository has been tampered with.

> is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply?

See above on git not making the guarantees that software that "uses cryptographic primitives for useful purposes" tend to make. Since Git makes none of those guarantees, it's (I think) a safe/sane thing for a non-cryptographer to design and implement. In practice, what Linus has done has let other off-the-shelf crypto (SSH and GPG) make the required guarantees for him.

Re: So, you want to crypto

#48

Post by josephlord »

haberman wrote: post #40

I'm curious to hear people's thoughts about git. Git is "crypto" to some extent, Linus does not appear to have tons of crypto expertise, and it uses SHA1 as a MAC AFAICT (which according to tptacek's earlier comment is invalid). And yet I've never heard about attacks on its crypto. This was interesting for me to think about because it seems like a counterpoint to the article, in that it is a very successful project t…

You can use hashes for security but you can also use them in non-security critical systems to get a unique (with a very high probability) number for use as an ID. Git uses them for this I believe.

Attacks like mentioned can be prevented by a number of mechanisms and checks for changes. If a hash being secure helps that is great but that isn't why git uses hashes. Or by separately signing commits.

git does use crypto but reuses existing crypto (https and ssl to communicate between repos and someone mentions you can use GPG to sign commits) rather than developing it's own secure protocol.

Re: So, you want to crypto

#49

Post by Nursie »

Ok so I do want to crypto and (to the best of my ability) I already do. I follow best practices, read about the subject matter, did coursera's crypto 1 (and where the hell is pt2? 1 was awesome!). I use established algorithms and I use, well audited implementations etc etc. where available.

I have a question about MACs. We're using HMAC based on SHA256 with 32-byte keys on our new system, but our security architect only wants us to send and verify 4 or 8 bytes of the MAC output. Am I wrong to be suspicious of this? It massively reduces the number of bits an attacker has to guess or calculate, though at 8 bytes that's 128 bits so not exactly a quick brute-force...

Re: So, you want to crypto

#50

Post by haberman »

alinajaf wrote: post #47
haberman wrote: post #45

Earlier quoted context omitted.

Git assumes that a matching SHA1 means that the content is equal to the original content. Is that not crypto? For example, if you sign a tag, it appears to sign the SHA1 of the associated content. This is definitely outside of my expertise, so I'm sure that my understanding is incomplete. The larger questions for me are: - if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from soft…

I'm not a cryptography expert either, but I'll give this a crack... In as much as SHA1 is a "cryptographic hash function", Linus isn't taking advantage of a few of it's cryptographic properties in his usage of it in git. It would for example, make no difference to the workings of git if you could reverse-engineer the contents of an object from its SHA1. In the same way, it doesn't matter much to the operation of git…

Thanks for this, you answered my questions thoroughly. I'm not entirely convinced by this though:

> [A signed commit] doesn't guarantee anything about the contents of that commit if the repository has been tampered with.

I think most people would intuitively expect the signed commit to guarantee the contents of the tree being signed. The idea that you could "git pull" a repo from a compromised machine, verify the signed commit, but not actually have a guarantee about the tree matching the one that was signed would run counter to most people's expectations, I suspect.

In other words, this to me seems like a "technically, we don't guarantee" statement about something that is de facto thought to be guaranteed.

Post reply on HN