Finding flaw in cryptographic protocol

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite
2












If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.

How about Finding a flaw in cryptographic protocol?!



  • How can you report it or flag an issue?

  • If you can fix it, is it possible to contribute?









share|improve this question



























    up vote
    6
    down vote

    favorite
    2












    If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.

    How about Finding a flaw in cryptographic protocol?!



    • How can you report it or flag an issue?

    • If you can fix it, is it possible to contribute?









    share|improve this question

























      up vote
      6
      down vote

      favorite
      2









      up vote
      6
      down vote

      favorite
      2






      2





      If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.

      How about Finding a flaw in cryptographic protocol?!



      • How can you report it or flag an issue?

      • If you can fix it, is it possible to contribute?









      share|improve this question















      If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.

      How about Finding a flaw in cryptographic protocol?!



      • How can you report it or flag an issue?

      • If you can fix it, is it possible to contribute?






      protocol-analysis standards






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 3 at 22:54









      Ella Rose

      13.9k43674




      13.9k43674










      asked Oct 3 at 15:28









      R1w

      587223




      587223




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          17
          down vote



          accepted











          If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
          How about Finding a flaw in cryptographic protocol?!




          A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed by many different implementations.




          • How can you report it or flag an issue?

          • If you can fix it, is it possible to contribute?



          This depends on whether the protocol is something that is deployed and in use, e.g. TLS, or is a protocol that has merely been proposed academically.



          If it is a theoretical academic protocol, you would create a paper discussing the attack or relevant shortcomings of the protocol and publish it as appropriate.



          If the protocol in question is actually in use in the real world, then you would find who the authors of the protocol are and email them privately. Exactly who you email might vary depending on circumstances: Companies, individual implementors, and standards bodies might all be relevant. Try looking for white papers/RFCs/working groups/etc to locate the appropriate people to contact.



          Be sure to include the email:



          • A thorough description of exactly what the problem is

          • Who is affected

          • How serious the problem is

          • How long the problem has been present

          • An implementation of the attack (a.k.a proof of concept)

          • Recommendations for how to fix the problem

          Vulnerability reporting and disclosure can have multiple, orthogonal approaches and vendor responses may vary. If it is a widely used protocol like TLS your approach and response may very well be different from some random individuals project on GitHub.



          Oh, and apparently it's trendy to create a branding campaign for the vulnerability, including a name, logo, and website. Whether or not this is a good practice is debated.






          share|improve this answer


















          • 1




            Would the anonymous downvoter care to explain?
            – Ella Rose
            Oct 3 at 22:01






          • 2




            Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
            – SEJPM♦
            Oct 4 at 7:42






          • 2




            I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
            – kasperd
            Oct 4 at 11:46






          • 3




            @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
            – Ilmari Karonen
            Oct 4 at 12:02






          • 1




            @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
            – kasperd
            Oct 4 at 14:38

















          up vote
          0
          down vote













          First of all, if the protocol is under use, you have to warn them before publicly announce. Otherwise, there can be very catastrophic results. First day attacks are very common.



          Demonstrating only the flaw is a half paper, with countermeasures you will have a good paper. Of course, you have to give time to people to deploy the countermeasures.



          update: on examples due to valueble comments;



          1. Example Bleichenbacher's CCA attack on PKCS#1

          2. Example NeedhamSchroederr





          share|improve this answer






















          • good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
            – R1w
            Oct 3 at 21:14






          • 2




            Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
            – Ella Rose
            Oct 3 at 21:27











          • @EllaRose isn't it part of a protocol?
            – kelalaka
            Oct 4 at 5:27






          • 1




            @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
            – Martin Bonner
            Oct 4 at 10:21






          • 1




            Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
            – Martin Bonner
            Oct 4 at 10:49

















          up vote
          -2
          down vote













          Or, you try to cash in on it.



          If you're any good at finding flaws, there is a lucrative (and legal) yet very grey market in vulnerabilities and zero day exploits. The New York Times have listed some prices and companies that resell these. Outfits like Zerodium in Washington; Netragard in Acton, Mass.; Exodus Intelligence in Austin, Tex.; and ReVuln, and a Virginia start-up named Endgame. Typical exploits sell for 35,000 to 160,000 dollars, but you can get up to 500,000 dollars for Apple’s iOS.



          All of the security agencies pay to get these, presumably under some form of non disclosure agreements/secrecy legislation. The NSA seems to be the largest client, but the FBI also buys exploits such as for back dooring Firefox/Tor. If you're really good, you should be able to sell the same exploit to multiple buyers. It depends on your contacts as to whether you are able to access this market though.



          In the war on terror, it could literally be catastrophic to not exploit such flaws. Hawks would argue that it's your patriotic duty to pass such information onto the security agencies. Stuxnet, Flame and Duqu have all capitalised on zero day exploits with great success at disrupting Iran's nuclear program. It's to protect the children too. Or so the ideology goes. As the whether it's moral/ethical, those issues have been formalised by Obama's Special Assistant to the President and Cybersecurity Coordinator, Michael Daniel:-



          • How much is the vulnerable system used in the core internet infrastructure, in other critical infrastructure systems, in the U.S. economy, and/or in national security systems?

          • Does the vulnerability, if left unpatched, impose significant risk?
            How much harm could an adversary nation or criminal group do with knowledge of this vulnerability?

          • How likely is it that we would know if someone else was exploiting it?

          • How badly do we need the intelligence we think we can get from exploiting the vulnerability?

          • Are there other ways we can get it?

          • Could we utilize the vulnerability for a short period of time before we disclose it?

          • How likely is it that someone else will discover the vulnerability?

          • Can the vulnerability be patched or otherwise mitigated?

          This policy is called NOBUS in the US and is for "investing in groundbreaking cryptanalytic capabilities to defeat adversarial
          cryptography and exploit internet traffic." Examples of it are Dual_EC_DRBG, cracking Diffie-Hellman and EternalBlue in Windows. Quoting, "as a general rule, tries to focus on exploiting vulnerabilities used in its targets’ software".



          In summary, there's lots of money to be made. And you'd be contributing to your country's security as JFK asked of us all.






          share|improve this answer


















          • 2




            I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
            – R1w
            Oct 3 at 21:04






          • 4




            @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
            – e-sushi♦
            Oct 4 at 3:31






          • 4




            -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
            – dn3s
            Oct 4 at 3:59






          • 4




            "Cryptography is first and foremost a munition" - citation needed.
            – Martin Bonner
            Oct 4 at 10:23






          • 3




            @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
            – Martin Bonner
            2 days ago










          Your Answer




          StackExchange.ifUsing("editor", function ()
          return StackExchange.using("mathjaxEditing", function ()
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
          );
          );
          , "mathjax-editing");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "281"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f62847%2ffinding-flaw-in-cryptographic-protocol%23new-answer', 'question_page');

          );

          Post as a guest






























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          17
          down vote



          accepted











          If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
          How about Finding a flaw in cryptographic protocol?!




          A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed by many different implementations.




          • How can you report it or flag an issue?

          • If you can fix it, is it possible to contribute?



          This depends on whether the protocol is something that is deployed and in use, e.g. TLS, or is a protocol that has merely been proposed academically.



          If it is a theoretical academic protocol, you would create a paper discussing the attack or relevant shortcomings of the protocol and publish it as appropriate.



          If the protocol in question is actually in use in the real world, then you would find who the authors of the protocol are and email them privately. Exactly who you email might vary depending on circumstances: Companies, individual implementors, and standards bodies might all be relevant. Try looking for white papers/RFCs/working groups/etc to locate the appropriate people to contact.



          Be sure to include the email:



          • A thorough description of exactly what the problem is

          • Who is affected

          • How serious the problem is

          • How long the problem has been present

          • An implementation of the attack (a.k.a proof of concept)

          • Recommendations for how to fix the problem

          Vulnerability reporting and disclosure can have multiple, orthogonal approaches and vendor responses may vary. If it is a widely used protocol like TLS your approach and response may very well be different from some random individuals project on GitHub.



          Oh, and apparently it's trendy to create a branding campaign for the vulnerability, including a name, logo, and website. Whether or not this is a good practice is debated.






          share|improve this answer


















          • 1




            Would the anonymous downvoter care to explain?
            – Ella Rose
            Oct 3 at 22:01






          • 2




            Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
            – SEJPM♦
            Oct 4 at 7:42






          • 2




            I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
            – kasperd
            Oct 4 at 11:46






          • 3




            @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
            – Ilmari Karonen
            Oct 4 at 12:02






          • 1




            @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
            – kasperd
            Oct 4 at 14:38














          up vote
          17
          down vote



          accepted











          If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
          How about Finding a flaw in cryptographic protocol?!




          A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed by many different implementations.




          • How can you report it or flag an issue?

          • If you can fix it, is it possible to contribute?



          This depends on whether the protocol is something that is deployed and in use, e.g. TLS, or is a protocol that has merely been proposed academically.



          If it is a theoretical academic protocol, you would create a paper discussing the attack or relevant shortcomings of the protocol and publish it as appropriate.



          If the protocol in question is actually in use in the real world, then you would find who the authors of the protocol are and email them privately. Exactly who you email might vary depending on circumstances: Companies, individual implementors, and standards bodies might all be relevant. Try looking for white papers/RFCs/working groups/etc to locate the appropriate people to contact.



          Be sure to include the email:



          • A thorough description of exactly what the problem is

          • Who is affected

          • How serious the problem is

          • How long the problem has been present

          • An implementation of the attack (a.k.a proof of concept)

          • Recommendations for how to fix the problem

          Vulnerability reporting and disclosure can have multiple, orthogonal approaches and vendor responses may vary. If it is a widely used protocol like TLS your approach and response may very well be different from some random individuals project on GitHub.



          Oh, and apparently it's trendy to create a branding campaign for the vulnerability, including a name, logo, and website. Whether or not this is a good practice is debated.






          share|improve this answer


















          • 1




            Would the anonymous downvoter care to explain?
            – Ella Rose
            Oct 3 at 22:01






          • 2




            Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
            – SEJPM♦
            Oct 4 at 7:42






          • 2




            I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
            – kasperd
            Oct 4 at 11:46






          • 3




            @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
            – Ilmari Karonen
            Oct 4 at 12:02






          • 1




            @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
            – kasperd
            Oct 4 at 14:38












          up vote
          17
          down vote



          accepted







          up vote
          17
          down vote



          accepted







          If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
          How about Finding a flaw in cryptographic protocol?!




          A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed by many different implementations.




          • How can you report it or flag an issue?

          • If you can fix it, is it possible to contribute?



          This depends on whether the protocol is something that is deployed and in use, e.g. TLS, or is a protocol that has merely been proposed academically.



          If it is a theoretical academic protocol, you would create a paper discussing the attack or relevant shortcomings of the protocol and publish it as appropriate.



          If the protocol in question is actually in use in the real world, then you would find who the authors of the protocol are and email them privately. Exactly who you email might vary depending on circumstances: Companies, individual implementors, and standards bodies might all be relevant. Try looking for white papers/RFCs/working groups/etc to locate the appropriate people to contact.



          Be sure to include the email:



          • A thorough description of exactly what the problem is

          • Who is affected

          • How serious the problem is

          • How long the problem has been present

          • An implementation of the attack (a.k.a proof of concept)

          • Recommendations for how to fix the problem

          Vulnerability reporting and disclosure can have multiple, orthogonal approaches and vendor responses may vary. If it is a widely used protocol like TLS your approach and response may very well be different from some random individuals project on GitHub.



          Oh, and apparently it's trendy to create a branding campaign for the vulnerability, including a name, logo, and website. Whether or not this is a good practice is debated.






          share|improve this answer















          If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute.
          How about Finding a flaw in cryptographic protocol?!




          A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed by many different implementations.




          • How can you report it or flag an issue?

          • If you can fix it, is it possible to contribute?



          This depends on whether the protocol is something that is deployed and in use, e.g. TLS, or is a protocol that has merely been proposed academically.



          If it is a theoretical academic protocol, you would create a paper discussing the attack or relevant shortcomings of the protocol and publish it as appropriate.



          If the protocol in question is actually in use in the real world, then you would find who the authors of the protocol are and email them privately. Exactly who you email might vary depending on circumstances: Companies, individual implementors, and standards bodies might all be relevant. Try looking for white papers/RFCs/working groups/etc to locate the appropriate people to contact.



          Be sure to include the email:



          • A thorough description of exactly what the problem is

          • Who is affected

          • How serious the problem is

          • How long the problem has been present

          • An implementation of the attack (a.k.a proof of concept)

          • Recommendations for how to fix the problem

          Vulnerability reporting and disclosure can have multiple, orthogonal approaches and vendor responses may vary. If it is a widely used protocol like TLS your approach and response may very well be different from some random individuals project on GitHub.



          Oh, and apparently it's trendy to create a branding campaign for the vulnerability, including a name, logo, and website. Whether or not this is a good practice is debated.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Oct 3 at 23:23

























          answered Oct 3 at 21:36









          Ella Rose

          13.9k43674




          13.9k43674







          • 1




            Would the anonymous downvoter care to explain?
            – Ella Rose
            Oct 3 at 22:01






          • 2




            Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
            – SEJPM♦
            Oct 4 at 7:42






          • 2




            I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
            – kasperd
            Oct 4 at 11:46






          • 3




            @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
            – Ilmari Karonen
            Oct 4 at 12:02






          • 1




            @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
            – kasperd
            Oct 4 at 14:38












          • 1




            Would the anonymous downvoter care to explain?
            – Ella Rose
            Oct 3 at 22:01






          • 2




            Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
            – SEJPM♦
            Oct 4 at 7:42






          • 2




            I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
            – kasperd
            Oct 4 at 11:46






          • 3




            @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
            – Ilmari Karonen
            Oct 4 at 12:02






          • 1




            @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
            – kasperd
            Oct 4 at 14:38







          1




          1




          Would the anonymous downvoter care to explain?
          – Ella Rose
          Oct 3 at 22:01




          Would the anonymous downvoter care to explain?
          – Ella Rose
          Oct 3 at 22:01




          2




          2




          Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
          – SEJPM♦
          Oct 4 at 7:42




          Note that even if the protocol is non-academic you can / should still publish a paper after the issue is fixed.
          – SEJPM♦
          Oct 4 at 7:42




          2




          2




          I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
          – kasperd
          Oct 4 at 11:46




          I disagree with the proof of concept being needed. Often it will be much more work to implement a proof of concept than to implement a fix. And in those cases you will be increasing the time to get the vulnerability fixed by spending time on writing a proof of concept. I know there are companies who refuse to fix security vulnerabilities until a proof of concept has been presented, but that's a bad attitude that we should try to reverse. If you found a vulnerability and want to write proof of concept, feel free to do so. But you shouldn't feel obliged to do it.
          – kasperd
          Oct 4 at 11:46




          3




          3




          @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
          – Ilmari Karonen
          Oct 4 at 12:02




          @kasperd: I kind of agree, but while a proof of concept isn't (or at least should not be) necessary, it can be very helpful in getting people to accept that the issue you found is actually real and exploitable. Especially if you don't already have a reputation as a credible and competent security researcher. In an ideal world, you'd just point out the flaw and everyone would immediately go "oh, yes, that's wrong and we should fix it." In the real world, if the flaw is not obvious and you can't directly demonstrate its effects, that rarely happens.
          – Ilmari Karonen
          Oct 4 at 12:02




          1




          1




          @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
          – kasperd
          Oct 4 at 14:38




          @IlmariKaronen I don't question the effectiveness of a proof of concept in convincing others that a security vulnerability should be addressed. However I still think it is more productive to report vulnerabilities without implementing a proof of concept initially, and take such reports serious if you receive one. If you have reported a vulnerability without proof of concept and your report is not being taken serious, then you can consider whether it is worthwhile putting effort into a proof of concept. Sounds like for the most part we are in agreement.
          – kasperd
          Oct 4 at 14:38










          up vote
          0
          down vote













          First of all, if the protocol is under use, you have to warn them before publicly announce. Otherwise, there can be very catastrophic results. First day attacks are very common.



          Demonstrating only the flaw is a half paper, with countermeasures you will have a good paper. Of course, you have to give time to people to deploy the countermeasures.



          update: on examples due to valueble comments;



          1. Example Bleichenbacher's CCA attack on PKCS#1

          2. Example NeedhamSchroederr





          share|improve this answer






















          • good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
            – R1w
            Oct 3 at 21:14






          • 2




            Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
            – Ella Rose
            Oct 3 at 21:27











          • @EllaRose isn't it part of a protocol?
            – kelalaka
            Oct 4 at 5:27






          • 1




            @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
            – Martin Bonner
            Oct 4 at 10:21






          • 1




            Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
            – Martin Bonner
            Oct 4 at 10:49














          up vote
          0
          down vote













          First of all, if the protocol is under use, you have to warn them before publicly announce. Otherwise, there can be very catastrophic results. First day attacks are very common.



          Demonstrating only the flaw is a half paper, with countermeasures you will have a good paper. Of course, you have to give time to people to deploy the countermeasures.



          update: on examples due to valueble comments;



          1. Example Bleichenbacher's CCA attack on PKCS#1

          2. Example NeedhamSchroederr





          share|improve this answer






















          • good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
            – R1w
            Oct 3 at 21:14






          • 2




            Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
            – Ella Rose
            Oct 3 at 21:27











          • @EllaRose isn't it part of a protocol?
            – kelalaka
            Oct 4 at 5:27






          • 1




            @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
            – Martin Bonner
            Oct 4 at 10:21






          • 1




            Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
            – Martin Bonner
            Oct 4 at 10:49












          up vote
          0
          down vote










          up vote
          0
          down vote









          First of all, if the protocol is under use, you have to warn them before publicly announce. Otherwise, there can be very catastrophic results. First day attacks are very common.



          Demonstrating only the flaw is a half paper, with countermeasures you will have a good paper. Of course, you have to give time to people to deploy the countermeasures.



          update: on examples due to valueble comments;



          1. Example Bleichenbacher's CCA attack on PKCS#1

          2. Example NeedhamSchroederr





          share|improve this answer














          First of all, if the protocol is under use, you have to warn them before publicly announce. Otherwise, there can be very catastrophic results. First day attacks are very common.



          Demonstrating only the flaw is a half paper, with countermeasures you will have a good paper. Of course, you have to give time to people to deploy the countermeasures.



          update: on examples due to valueble comments;



          1. Example Bleichenbacher's CCA attack on PKCS#1

          2. Example NeedhamSchroederr






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Oct 4 at 11:06

























          answered Oct 3 at 15:58









          kelalaka

          795214




          795214











          • good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
            – R1w
            Oct 3 at 21:14






          • 2




            Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
            – Ella Rose
            Oct 3 at 21:27











          • @EllaRose isn't it part of a protocol?
            – kelalaka
            Oct 4 at 5:27






          • 1




            @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
            – Martin Bonner
            Oct 4 at 10:21






          • 1




            Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
            – Martin Bonner
            Oct 4 at 10:49
















          • good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
            – R1w
            Oct 3 at 21:14






          • 2




            Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
            – Ella Rose
            Oct 3 at 21:27











          • @EllaRose isn't it part of a protocol?
            – kelalaka
            Oct 4 at 5:27






          • 1




            @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
            – Martin Bonner
            Oct 4 at 10:21






          • 1




            Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
            – Martin Bonner
            Oct 4 at 10:49















          good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
          – R1w
          Oct 3 at 21:14




          good answer but one of my question remains without answer or maybe i did not got it,If you can fix it, is it possible to contribute?
          – R1w
          Oct 3 at 21:14




          2




          2




          Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
          – Ella Rose
          Oct 3 at 21:27





          Why is RSA mentioned next to Dual_EC_DRBG? Why is Dual_EC_DRBG mentioned at all (as it is not a protocol)?
          – Ella Rose
          Oct 3 at 21:27













          @EllaRose isn't it part of a protocol?
          – kelalaka
          Oct 4 at 5:27




          @EllaRose isn't it part of a protocol?
          – kelalaka
          Oct 4 at 5:27




          1




          1




          @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
          – Martin Bonner
          Oct 4 at 10:21




          @kelaka : No. Dual_EC_DRBG is an algorithm. Also, Heartbleed is not a flaw in a protocol, it was an implementation bug in a widely deployed library.
          – Martin Bonner
          Oct 4 at 10:21




          1




          1




          Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
          – Martin Bonner
          Oct 4 at 10:49




          Yes. Heartbleed was entirely equivalent to a flaw in the Linux kernel, and was reported to the OpenSSL team. A flaw in an underlying algorithm is not the same as a protocol flaw, but it is much more similar (in that both are a specification flaw). The Bleichenbecher attack on PKCS #1 v1.5 is the sort of thing I would describe as a protocol flaw.
          – Martin Bonner
          Oct 4 at 10:49










          up vote
          -2
          down vote













          Or, you try to cash in on it.



          If you're any good at finding flaws, there is a lucrative (and legal) yet very grey market in vulnerabilities and zero day exploits. The New York Times have listed some prices and companies that resell these. Outfits like Zerodium in Washington; Netragard in Acton, Mass.; Exodus Intelligence in Austin, Tex.; and ReVuln, and a Virginia start-up named Endgame. Typical exploits sell for 35,000 to 160,000 dollars, but you can get up to 500,000 dollars for Apple’s iOS.



          All of the security agencies pay to get these, presumably under some form of non disclosure agreements/secrecy legislation. The NSA seems to be the largest client, but the FBI also buys exploits such as for back dooring Firefox/Tor. If you're really good, you should be able to sell the same exploit to multiple buyers. It depends on your contacts as to whether you are able to access this market though.



          In the war on terror, it could literally be catastrophic to not exploit such flaws. Hawks would argue that it's your patriotic duty to pass such information onto the security agencies. Stuxnet, Flame and Duqu have all capitalised on zero day exploits with great success at disrupting Iran's nuclear program. It's to protect the children too. Or so the ideology goes. As the whether it's moral/ethical, those issues have been formalised by Obama's Special Assistant to the President and Cybersecurity Coordinator, Michael Daniel:-



          • How much is the vulnerable system used in the core internet infrastructure, in other critical infrastructure systems, in the U.S. economy, and/or in national security systems?

          • Does the vulnerability, if left unpatched, impose significant risk?
            How much harm could an adversary nation or criminal group do with knowledge of this vulnerability?

          • How likely is it that we would know if someone else was exploiting it?

          • How badly do we need the intelligence we think we can get from exploiting the vulnerability?

          • Are there other ways we can get it?

          • Could we utilize the vulnerability for a short period of time before we disclose it?

          • How likely is it that someone else will discover the vulnerability?

          • Can the vulnerability be patched or otherwise mitigated?

          This policy is called NOBUS in the US and is for "investing in groundbreaking cryptanalytic capabilities to defeat adversarial
          cryptography and exploit internet traffic." Examples of it are Dual_EC_DRBG, cracking Diffie-Hellman and EternalBlue in Windows. Quoting, "as a general rule, tries to focus on exploiting vulnerabilities used in its targets’ software".



          In summary, there's lots of money to be made. And you'd be contributing to your country's security as JFK asked of us all.






          share|improve this answer


















          • 2




            I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
            – R1w
            Oct 3 at 21:04






          • 4




            @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
            – e-sushi♦
            Oct 4 at 3:31






          • 4




            -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
            – dn3s
            Oct 4 at 3:59






          • 4




            "Cryptography is first and foremost a munition" - citation needed.
            – Martin Bonner
            Oct 4 at 10:23






          • 3




            @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
            – Martin Bonner
            2 days ago














          up vote
          -2
          down vote













          Or, you try to cash in on it.



          If you're any good at finding flaws, there is a lucrative (and legal) yet very grey market in vulnerabilities and zero day exploits. The New York Times have listed some prices and companies that resell these. Outfits like Zerodium in Washington; Netragard in Acton, Mass.; Exodus Intelligence in Austin, Tex.; and ReVuln, and a Virginia start-up named Endgame. Typical exploits sell for 35,000 to 160,000 dollars, but you can get up to 500,000 dollars for Apple’s iOS.



          All of the security agencies pay to get these, presumably under some form of non disclosure agreements/secrecy legislation. The NSA seems to be the largest client, but the FBI also buys exploits such as for back dooring Firefox/Tor. If you're really good, you should be able to sell the same exploit to multiple buyers. It depends on your contacts as to whether you are able to access this market though.



          In the war on terror, it could literally be catastrophic to not exploit such flaws. Hawks would argue that it's your patriotic duty to pass such information onto the security agencies. Stuxnet, Flame and Duqu have all capitalised on zero day exploits with great success at disrupting Iran's nuclear program. It's to protect the children too. Or so the ideology goes. As the whether it's moral/ethical, those issues have been formalised by Obama's Special Assistant to the President and Cybersecurity Coordinator, Michael Daniel:-



          • How much is the vulnerable system used in the core internet infrastructure, in other critical infrastructure systems, in the U.S. economy, and/or in national security systems?

          • Does the vulnerability, if left unpatched, impose significant risk?
            How much harm could an adversary nation or criminal group do with knowledge of this vulnerability?

          • How likely is it that we would know if someone else was exploiting it?

          • How badly do we need the intelligence we think we can get from exploiting the vulnerability?

          • Are there other ways we can get it?

          • Could we utilize the vulnerability for a short period of time before we disclose it?

          • How likely is it that someone else will discover the vulnerability?

          • Can the vulnerability be patched or otherwise mitigated?

          This policy is called NOBUS in the US and is for "investing in groundbreaking cryptanalytic capabilities to defeat adversarial
          cryptography and exploit internet traffic." Examples of it are Dual_EC_DRBG, cracking Diffie-Hellman and EternalBlue in Windows. Quoting, "as a general rule, tries to focus on exploiting vulnerabilities used in its targets’ software".



          In summary, there's lots of money to be made. And you'd be contributing to your country's security as JFK asked of us all.






          share|improve this answer


















          • 2




            I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
            – R1w
            Oct 3 at 21:04






          • 4




            @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
            – e-sushi♦
            Oct 4 at 3:31






          • 4




            -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
            – dn3s
            Oct 4 at 3:59






          • 4




            "Cryptography is first and foremost a munition" - citation needed.
            – Martin Bonner
            Oct 4 at 10:23






          • 3




            @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
            – Martin Bonner
            2 days ago












          up vote
          -2
          down vote










          up vote
          -2
          down vote









          Or, you try to cash in on it.



          If you're any good at finding flaws, there is a lucrative (and legal) yet very grey market in vulnerabilities and zero day exploits. The New York Times have listed some prices and companies that resell these. Outfits like Zerodium in Washington; Netragard in Acton, Mass.; Exodus Intelligence in Austin, Tex.; and ReVuln, and a Virginia start-up named Endgame. Typical exploits sell for 35,000 to 160,000 dollars, but you can get up to 500,000 dollars for Apple’s iOS.



          All of the security agencies pay to get these, presumably under some form of non disclosure agreements/secrecy legislation. The NSA seems to be the largest client, but the FBI also buys exploits such as for back dooring Firefox/Tor. If you're really good, you should be able to sell the same exploit to multiple buyers. It depends on your contacts as to whether you are able to access this market though.



          In the war on terror, it could literally be catastrophic to not exploit such flaws. Hawks would argue that it's your patriotic duty to pass such information onto the security agencies. Stuxnet, Flame and Duqu have all capitalised on zero day exploits with great success at disrupting Iran's nuclear program. It's to protect the children too. Or so the ideology goes. As the whether it's moral/ethical, those issues have been formalised by Obama's Special Assistant to the President and Cybersecurity Coordinator, Michael Daniel:-



          • How much is the vulnerable system used in the core internet infrastructure, in other critical infrastructure systems, in the U.S. economy, and/or in national security systems?

          • Does the vulnerability, if left unpatched, impose significant risk?
            How much harm could an adversary nation or criminal group do with knowledge of this vulnerability?

          • How likely is it that we would know if someone else was exploiting it?

          • How badly do we need the intelligence we think we can get from exploiting the vulnerability?

          • Are there other ways we can get it?

          • Could we utilize the vulnerability for a short period of time before we disclose it?

          • How likely is it that someone else will discover the vulnerability?

          • Can the vulnerability be patched or otherwise mitigated?

          This policy is called NOBUS in the US and is for "investing in groundbreaking cryptanalytic capabilities to defeat adversarial
          cryptography and exploit internet traffic." Examples of it are Dual_EC_DRBG, cracking Diffie-Hellman and EternalBlue in Windows. Quoting, "as a general rule, tries to focus on exploiting vulnerabilities used in its targets’ software".



          In summary, there's lots of money to be made. And you'd be contributing to your country's security as JFK asked of us all.






          share|improve this answer














          Or, you try to cash in on it.



          If you're any good at finding flaws, there is a lucrative (and legal) yet very grey market in vulnerabilities and zero day exploits. The New York Times have listed some prices and companies that resell these. Outfits like Zerodium in Washington; Netragard in Acton, Mass.; Exodus Intelligence in Austin, Tex.; and ReVuln, and a Virginia start-up named Endgame. Typical exploits sell for 35,000 to 160,000 dollars, but you can get up to 500,000 dollars for Apple’s iOS.



          All of the security agencies pay to get these, presumably under some form of non disclosure agreements/secrecy legislation. The NSA seems to be the largest client, but the FBI also buys exploits such as for back dooring Firefox/Tor. If you're really good, you should be able to sell the same exploit to multiple buyers. It depends on your contacts as to whether you are able to access this market though.



          In the war on terror, it could literally be catastrophic to not exploit such flaws. Hawks would argue that it's your patriotic duty to pass such information onto the security agencies. Stuxnet, Flame and Duqu have all capitalised on zero day exploits with great success at disrupting Iran's nuclear program. It's to protect the children too. Or so the ideology goes. As the whether it's moral/ethical, those issues have been formalised by Obama's Special Assistant to the President and Cybersecurity Coordinator, Michael Daniel:-



          • How much is the vulnerable system used in the core internet infrastructure, in other critical infrastructure systems, in the U.S. economy, and/or in national security systems?

          • Does the vulnerability, if left unpatched, impose significant risk?
            How much harm could an adversary nation or criminal group do with knowledge of this vulnerability?

          • How likely is it that we would know if someone else was exploiting it?

          • How badly do we need the intelligence we think we can get from exploiting the vulnerability?

          • Are there other ways we can get it?

          • Could we utilize the vulnerability for a short period of time before we disclose it?

          • How likely is it that someone else will discover the vulnerability?

          • Can the vulnerability be patched or otherwise mitigated?

          This policy is called NOBUS in the US and is for "investing in groundbreaking cryptanalytic capabilities to defeat adversarial
          cryptography and exploit internet traffic." Examples of it are Dual_EC_DRBG, cracking Diffie-Hellman and EternalBlue in Windows. Quoting, "as a general rule, tries to focus on exploiting vulnerabilities used in its targets’ software".



          In summary, there's lots of money to be made. And you'd be contributing to your country's security as JFK asked of us all.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Oct 5 at 0:50

























          answered Oct 3 at 20:51









          Paul Uszak

          6,11611332




          6,11611332







          • 2




            I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
            – R1w
            Oct 3 at 21:04






          • 4




            @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
            – e-sushi♦
            Oct 4 at 3:31






          • 4




            -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
            – dn3s
            Oct 4 at 3:59






          • 4




            "Cryptography is first and foremost a munition" - citation needed.
            – Martin Bonner
            Oct 4 at 10:23






          • 3




            @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
            – Martin Bonner
            2 days ago












          • 2




            I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
            – R1w
            Oct 3 at 21:04






          • 4




            @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
            – e-sushi♦
            Oct 4 at 3:31






          • 4




            -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
            – dn3s
            Oct 4 at 3:59






          • 4




            "Cryptography is first and foremost a munition" - citation needed.
            – Martin Bonner
            Oct 4 at 10:23






          • 3




            @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
            – Martin Bonner
            2 days ago







          2




          2




          I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
          – R1w
          Oct 3 at 21:04




          I confused how legal is to sell zero-day exploit and what is the difference between selling it to those people or in darknet?
          – R1w
          Oct 3 at 21:04




          4




          4




          @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
          – e-sushi♦
          Oct 4 at 3:31




          @R1w In some countries, selling zero-days is indeed illegal and may even be considered a terrorist act. Therefore, I would generally advise anyone contemplating to engage in such activity to first check the laws of current geo-location (read: ask a local lawyer first).
          – e-sushi♦
          Oct 4 at 3:31




          4




          4




          -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
          – dn3s
          Oct 4 at 3:59




          -1 until this answer properly hedges the legal claim, and has some acknowledgement of how deeply unethical this course of action is. Also would be worthwhile to provide more ideological context to the claims in the second paragraph. ("Hawks would argue..." gets at this but could be made more explicit)
          – dn3s
          Oct 4 at 3:59




          4




          4




          "Cryptography is first and foremost a munition" - citation needed.
          – Martin Bonner
          Oct 4 at 10:23




          "Cryptography is first and foremost a munition" - citation needed.
          – Martin Bonner
          Oct 4 at 10:23




          3




          3




          @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
          – Martin Bonner
          2 days ago




          @user2768 No. The fact that some (or even all) countries treat something a munitions, does not mean that is what it is "first and foremost". High explosives are certainly treated as munitions, but I would argue that first and foremost they are about mining and similar activities.
          – Martin Bonner
          2 days ago

















           

          draft saved


          draft discarded















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f62847%2ffinding-flaw-in-cryptographic-protocol%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          Peggy Mitchell

          Palaiologos

          The Forum (Inglewood, California)