4 ms·

His view is not correct, nor are the links you've provided directly relevant to this discussion. The "German Tank Problem" requires knowledge of variables that

by dimino 10y ago

His view is not correct, nor are the links you've provided directly relevant to this discussion. The "German Tank Problem" requires knowledge of variables that aren't present in the VeraCrypt security audit. In fact, your second link begs the question, as it requires the prior knowledge of a "bug hit rate", which is defined in the blog post as a fairly arbitrary number, with plenty of caveats, and requires multiple independent audits. In fact, from your linked blog, "Maybe the Lincoln estimate is not at all accurate, but it does tell you to be worried that there may be a lot more bugs to find since the overlap between the two bug lists was so small." I begin to wonder if you actually read your own links...

ChrisLomont 10y ago
From the link [1] "There’s a simple statistic called the Lincoln Index that lets you estimate the total number of errors based on the number of errors found" "Suppose two testers independently search for bugs. Let E1 be the number of errors the first tester finds and E2 the number of errors the second tester finds. Let S be the number of errors both testers find. The Lincoln Index estimates the total number of errors as E1 E2/S. " E1 = count from searcher 1 E2 = count from searcher 2 S = Number overlapping If S != 0, then a good estimate of the number of bugs in the code is E1E2/S. One can derive error bounds and confidence intervals if desired Nowhere does this formula need prior knowledge. All is needs is at least two testers to count the bugs each found and the overlaps. This is precisely* the example I gave above. As one analyzes how this works, one finds that this is likely lower than the true bug count. A simple reason is explained in "Beginning Software Engineering" by Rod Stephens, p197, which you can find on google books and read. Alternatively, try searching for "estimate number of software bugs" in Google scholar and you can see a vast literature based exactly on refining methods like this.
- dimino 10y ago
  > Nowhere does this formula need prior knowledge I never said the Lincoln Index required prior knowledge, I said the German tank problem required prior knowledge that isn't available in the VeraCrypt security audit. Your example may have been copied from the blog post, but you failed to include any of the caveats that were present in the blog post, which are also present in the "vast literature" in Google Scholar. Rod Stephens even says, in the very citation you attempt to make, "Like all the other bug estimation techniques, this one isn’t perfect. It relies on the assumption that the testers have an equal chance to find any particular bug, and that’s probably not true." It does go on to say the Lincon Index, "probably underestimates the true number of bugs." but in that aspect, Rod Stephens disagrees with the body of work available both in your own links, and in the Google Scholar articles. He then cites Wikipedia, so in that he's basically admitting he's not an expert. I am not and have not been saying there are no further bugs in VeraCrypt. I am saying the likelihood of there being "many" more bugs in VeraCrypt is not available, given the data we currently have. We don't have E2, for example, since you're focused so intently on the Lincoln Index.
  - ChrisLomont 10y ago
    >I never said the Lincoln Index required prior knowledge You wrote >In fact, your second link begs the question, as it requires the prior knowledge of a "bug hit rate", so you wrote exactly that the Lincoln index "requires the prior knowledge of a bug hit rate". >which are also present in the "vast literature" in Google Ah, so you read all the literature. Good. Then you're realize there are other methods than Lincoln, so your complaint about not knowing E2 is mitigated. >I am not and have not been saying there are no further bugs in VeraCrypt. You wrote above > If there were more bugs, why weren't they found? What did you mean here except to imply you believe there are no more bugs? >I am saying the likelihood of there being "many" more bugs in VeraCrypt is not available, given the data we currently have. Here [1] is the report. It states in multiple places not all code was checked. For example, page 6, states that "Some components of VeraCrypt have not been investigated" including "the OS X and Linux versions of VeraCrypt". Want to bet if there are bugs in there? Of the parts checked, bugs were found by multiple independent groups, including Open Crypto Audit Project, Fraunhofer Institute for Secure Information Technology, and James Forshaw. These bugs have very little overlap. OCAP phase I found 11 bugs, page 4. OCAP Phase II found 4, page 16, two of which overlap previously known bugs. James Forshaw found 2 more bugs, page 18. Sections 5, 6, and 7 each list more bugs by (presumably) the two people listed working on this portion. Given less than 100% code coverage and the lack of independent groups finding the same set of bugs, makes it extremely likely there are more bugs. This paper itself demonstrated audits by one group followed by later audits by another group, each finding more bugs. Yet you want people to believe there are no more bugs since we have not located them, despite the vast evidence and literature that the above points to more bugs lurking. As you stated, "If there were more bugs, why weren't they found?" [1] https://ostif.org/wp-content/uploads/2016/10/VeraCrypt-Audit-Final-for-Public-Release.pdf https://ostif.org/wp-content/uploads/2016/10/VeraCrypt-Audit...
    - dimino 10y ago
      Thanks for catching my mistake, I was referring to the first link when I said it "requires the prior knowledge of a bug hit rate". I think you've misread the report, as there weren't independent groups, it was two people from QuarksLab who performed the audit. Right there on page 6, the page you cite. There weren't multiples of the same bugs found by these two people in the report (why would they both report it?), OCAP phase I and II weren't done on VeraCript, and James Forshaw hasn't looked at VeraCrypt at all. This was E1. There is no E2. The alternative methods for determining bugs are all as flawed in this context as the one you've weirdly chosen to champion, the Lincoln index. What other specific method would you like to attempt to apply here? I'll gladly walk you through why it won't make sense in this context. I'll say it again: I never said there were no more bugs. You've built this strawman because it's easy to dismantle, however it isn't real. What I asked was, as you've quoted, "If there were more bugs, why weren't they found?" This draws an important line between the theoretical and the actual; the accusation of bugginess can be levied at any program. It is of no use or value to anyone to say such vague things as, "VeraCrypt may have more bugs!" Of course it could, that's a worthless statement. What's valuable is actually demonstrating those bugs. It's painfully clear you didn't actually understand the report, and you quote me twice, despite admitting you didn't understand the quoted text. I'll repeat here for you: I don't think and never said there are no remaining bugs in VeraCrypt, I do however believe it is useless to essentially exclaim to everyone that VeraCrypt is a piece of software (that's what you're doing when you're saying it might have other bugs). If there are other bugs, where are they? Surely you can find them if you know they exist.

by dimino 10y ago

ChrisLomont 10y ago

From the link [1] "There’s a simple statistic called the Lincoln Index that lets you estimate the total number of errors based on the number of errors found" "Suppose two testers independently search for bugs. Let E1 be the number of errors the first tester finds and E2 the number of errors the second tester finds. Let S be the number of errors both testers find. The Lincoln Index estimates the total number of errors as E1 E2/S. " E1 = count from searcher 1 E2 = count from searcher 2 S = Number overlapping If S != 0, then a good estimate of the number of bugs in the code is E1E2/S. One can derive error bounds and confidence intervals if desired Nowhere does this formula need prior knowledge. All is needs is at least two testers to count the bugs each found and the overlaps. This is precisely* the example I gave above. As one analyzes how this works, one finds that this is likely lower than the true bug count. A simple reason is explained in "Beginning Software Engineering" by Rod Stephens, p197, which you can find on google books and read. Alternatively, try searching for "estimate number of software bugs" in Google scholar and you can see a vast literature based exactly on refining methods like this.

dimino 10y ago
> Nowhere does this formula need prior knowledge I never said the Lincoln Index required prior knowledge, I said the German tank problem required prior knowledge that isn't available in the VeraCrypt security audit. Your example may have been copied from the blog post, but you failed to include any of the caveats that were present in the blog post, which are also present in the "vast literature" in Google Scholar. Rod Stephens even says, in the very citation you attempt to make, "Like all the other bug estimation techniques, this one isn’t perfect. It relies on the assumption that the testers have an equal chance to find any particular bug, and that’s probably not true." It does go on to say the Lincon Index, "probably underestimates the true number of bugs." but in that aspect, Rod Stephens disagrees with the body of work available both in your own links, and in the Google Scholar articles. He then cites Wikipedia, so in that he's basically admitting he's not an expert. I am not and have not been saying there are no further bugs in VeraCrypt. I am saying the likelihood of there being "many" more bugs in VeraCrypt is not available, given the data we currently have. We don't have E2, for example, since you're focused so intently on the Lincoln Index.
- ChrisLomont 10y ago
  >I never said the Lincoln Index required prior knowledge You wrote >In fact, your second link begs the question, as it requires the prior knowledge of a "bug hit rate", so you wrote exactly that the Lincoln index "requires the prior knowledge of a bug hit rate". >which are also present in the "vast literature" in Google Ah, so you read all the literature. Good. Then you're realize there are other methods than Lincoln, so your complaint about not knowing E2 is mitigated. >I am not and have not been saying there are no further bugs in VeraCrypt. You wrote above > If there were more bugs, why weren't they found? What did you mean here except to imply you believe there are no more bugs? >I am saying the likelihood of there being "many" more bugs in VeraCrypt is not available, given the data we currently have. Here [1] is the report. It states in multiple places not all code was checked. For example, page 6, states that "Some components of VeraCrypt have not been investigated" including "the OS X and Linux versions of VeraCrypt". Want to bet if there are bugs in there? Of the parts checked, bugs were found by multiple independent groups, including Open Crypto Audit Project, Fraunhofer Institute for Secure Information Technology, and James Forshaw. These bugs have very little overlap. OCAP phase I found 11 bugs, page 4. OCAP Phase II found 4, page 16, two of which overlap previously known bugs. James Forshaw found 2 more bugs, page 18. Sections 5, 6, and 7 each list more bugs by (presumably) the two people listed working on this portion. Given less than 100% code coverage and the lack of independent groups finding the same set of bugs, makes it extremely likely there are more bugs. This paper itself demonstrated audits by one group followed by later audits by another group, each finding more bugs. Yet you want people to believe there are no more bugs since we have not located them, despite the vast evidence and literature that the above points to more bugs lurking. As you stated, "If there were more bugs, why weren't they found?" [1] https://ostif.org/wp-content/uploads/2016/10/VeraCrypt-Audit-Final-for-Public-Release.pdf https://ostif.org/wp-content/uploads/2016/10/VeraCrypt-Audit...
  - dimino 10y ago
    Thanks for catching my mistake, I was referring to the first link when I said it "requires the prior knowledge of a bug hit rate". I think you've misread the report, as there weren't independent groups, it was two people from QuarksLab who performed the audit. Right there on page 6, the page you cite. There weren't multiples of the same bugs found by these two people in the report (why would they both report it?), OCAP phase I and II weren't done on VeraCript, and James Forshaw hasn't looked at VeraCrypt at all. This was E1. There is no E2. The alternative methods for determining bugs are all as flawed in this context as the one you've weirdly chosen to champion, the Lincoln index. What other specific method would you like to attempt to apply here? I'll gladly walk you through why it won't make sense in this context. I'll say it again: I never said there were no more bugs. You've built this strawman because it's easy to dismantle, however it isn't real. What I asked was, as you've quoted, "If there were more bugs, why weren't they found?" This draws an important line between the theoretical and the actual; the accusation of bugginess can be levied at any program. It is of no use or value to anyone to say such vague things as, "VeraCrypt may have more bugs!" Of course it could, that's a worthless statement. What's valuable is actually demonstrating those bugs. It's painfully clear you didn't actually understand the report, and you quote me twice, despite admitting you didn't understand the quoted text. I'll repeat here for you: I don't think and never said there are no remaining bugs in VeraCrypt, I do however believe it is useless to essentially exclaim to everyone that VeraCrypt is a piece of software (that's what you're doing when you're saying it might have other bugs). If there are other bugs, where are they? Surely you can find them if you know they exist.