Hi Warren, On 10/29/2015 06:50 PM, Warren Young wrote: > On Oct 29, 2015, at 3:40 PM, Eduard <[email protected]> wrote: >> On 10/29/2015 02:46 PM, Warren Young wrote: >>> (...) >> I had read 2/3 of them, yes. Thanks for the third one! > > The third one’s the mother lode. Don’t be fooled by the mail-archive.com UI, > which presents only 10 or so results at a time. That thread went on and on > and on. Hopefully we can avoid retreading some of the same ground in this > one.
Thanks! >>> most of the attacks on SHA-1 only apply to standalone blob cases >> >> And individual files (that are part of commits). That won't show up in >> the timeline. > > Do you mean newly-added files? They’re shown on the Check-in details screen, > the most likely thing you’re going to click on on the Timeline page. > > For a newly-added file to have an effect on a repo, it’ll probably also > require modification to an existing file, such as the Makefile. > > (Exceptions are files included by wildcard.) I'm talking about generating collisions for non-control artifacts (actual files), not control artifacts. This has a higher chance of being successful if the repository has the R-card disabled (for efficiency reasons). >>>> If the attacker is in control of the server >>> >>> …then he can serve you any content he likes, no matter how good your hash >>> algorithm is. >> >> True, but he shouldn't be able to convince me that ID "abcdef" >> corresponds to something other than the original artifact created with >> ID "abcdef”. > > How are you going to know that the legitimate file has ID abcdef? > Cross-reference to another repo? What if there is only one central repo? I'll check the PGP signature of a checkin manifest that has a checkin in its ancestry that contains this file. > If an evildoer has taken over the central server, they are just providing a > pile of artifacts, and you are trusting that those artifacts are legitimate. But if you do know that some subset of the (control) artifacts are legitimate (because you checked the PGP signature or because the lead dev told you the tip artifact ID in-person), it is so extremely useful to be able to infer that all of their ancestors must also be legitimate. >> I might know (through some other source, e.g. >> PGP-signed email) that artifact "abcdef" is genuine, and it shouldn't >> matter where I download it from. > > How many people will be doing such cross-checking? > > Again I bring up the XcodeGhost example. People do foolish things in the > name of expediency. Well, I know I will be doing such cross-checking. Hopefully I'm not the only one. Right? ...right? >> I don't have to trust my Debian mirror to download packages (and their >> sources) from it. > > You’re referring to the fact that DEBs are GPG-signed, I assume? > > That works because the Debian gatekeepers can sign the packages on an > assumed-secure box. (Such central package repos have been compromised in the > past.) The distro includes a copy of the central source’s public key, so if > the package signature doesn’t decrypt correctly, it isn’t legitimate. You're right; the binary packages are automatically signed on an assumed-secure box. But the source packages are also signed by the individual packagers, whose private keys reside only on their computers (and not on the server). > Where can you put such a root of trust in the Fossil case? > There is no central presumed-secure site with Fossil. Remember, you were just positing that the central repo’s server got rooted. There is more than one answer, but one is that the root of trust are the PGP private keys on the individual developers' personal computers. The developers' private keys should never ever reach the public central repo server. > You also can’t solve it by having people with checkin bits submit a GPG > public key to the repo along with their login creds and sign checkins, > because those keys live on the same compromised server. The evildoer can > just generate a new set of keys, re-sign the compromised artifacts, and store > the new keys in the user table instead of the original keys. > > It’s the problem with all PKIs: who do you trust? That's exactly correct! This is why it's important to set up a web of trust in PGP (sign the keys of the people you trust, etc). https://www.gnupg.org/gph/en/manual.html#AEN554 > because those keys live on the same compromised server (Sorry, I just couldn't let this one pass.) The entire point of PGP is that it's public key cryptography, so (in that scenario) the developers would only be submitting their *public* keys to the server (and would keep the private bits, well, private). >> That would avoid happenings like the XcodeGhost incident. > > Apple has a code-signing mechanism, too, and packages from Apple are always > signed. But, the client-side checker (Gatekeeper) is not mandatory, and > developers often turn it off entirely, since it gets in the way of developing > software. > > Plus, you can bypass Gatekeeper for $99: get a code signing cert from Apple > and sign your evil packages with it. It’ll work until Apple catches you and > revokes your cert. Almost no one checks *who* signed the package; all they > know is that the OS let them install it when they double-clicked it. That's actually kind of depressing. >> - Every artifact must be hashed by every known algorithm. > > I’m assuming it's possible to change from one algorithm to another > mid-stream, as long as the client knows all of the algorithms in use, and is > told where the change points occur. > > Do you know for a fact that you cannot do this? I'm not sure what you mean nor why it would be necessary. > (snip) >> Consider a checkin manifest from 3 years ago. It is >> very likely that no new checkin/branch will ever refer to it directly, >> so nobody will ever refer to it by new-hash. Worse yet, it is likely >> nobody will ever refer to the files inside that checkin by new-hash. If >> a preimage attack on old-hash becomes possible (or even easy), one could >> mess with the artifacts that are only referred to using old-hash. > > Yes, if you want old artifacts to be unassailable, you’d have to recompute > all the hashes. > > But, I think you’re not realizing that artifact chaining removes the > attraction of replacing old artifacts. As I understand it, you can’t replace > an artifact 10 checkins back from the tip of the branch without recomputing > the 9 other hashes on the way back to the tip. Therefore, an attack that > takes a year of CPU time to attack a leaf node takes 10 years to attack a > node 10 checkins back from the tip. That's (probably) true, but I'm mostly referring to colliding on non-control artifacts (i.e. actual files). >> I personally don't think we'll ever need to go past BetterHash-512. > > I’m not sure if you’re saying that 512 bits will be enough forever, or that > we already have the last hash algorithm we will ever need. > > History says either is a foolish prediction, and that the best hash > algorithms remain state-of-the-art for only about a dozen years. I wouldn't be so quick to jump to that conclusion (at least the part that 512 bits won't be enough forever; cryptanalysis may very well advance sufficiently to break BetterHash-512). As for the 512-bit security part, please see the end of http://www.mail-archive.com/[email protected]/msg21704.html (starting at "I know that it may appear so"). > Maybe the sunsetting of Moore’s Law will break us out of that pattern. But > if Fossil is going to go through the pain of replacing SHA-1, it should be > done in a way that makes it easier to do again later. Absolutely agree. > (snip) >> (Also are there any issues on any of the supported platforms with having >> dollar signs in filenames (or URLs)? Just a random thought.) > > Why do file names come into it? The MCF tag would be in one of the cards, > which live in the DB. > > I don’t even see that it has to be reported in the UI, or accepted on the > command line, since the chance of two algorithms having a conflicting hash > are near zero. Even if you do come across, say, a 10 hex digit prefix of two > hashes that are the same under, say, SHA-1 and SHA-512, Fossil already knows > how to stop and make you be specific about which one you mean, if it can’t > see that one is obviously correct. > > Therefore, command line usage will remain unchanged in this scheme: “fossil > up EA5D538D23A7C” will most often uniquely identify one artifact, or none, > not 2+. You're right, never mind. Best, Eduard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
