• 1 Post
  • 61 Comments
Joined 1 year ago
cake
Cake day: November 10th, 2023

help-circle






  • Possible? Yes. Likely? Not at all.

    To perform a zero knowledge proof, you’d have to have structured data to support the claim, which most whistleblowers would not have. If a whistleblower already had the hard evidence in hand, e.g., serial numbers and timestamps, they could have just provided those anonymously, and someone could follow up. The problem is, you can’t always get a copy of the hard evidence without revealing your intent to the employer, or at least, other employees.

    Presumably most whistleblowers are making unsubstantiated claims that something happened, or maybe with light evidence. Based on who they are, a journalist or investigator may then elect to follow up and dig up the hard evidence to support the claim. This requires revealing your name and position/relationship to at least one person. Rarely, they would be willing to put themselves out there to provide an affidavit under oath, which itself is not enough to pursue criminal charges (though it could help build a case around intent or willful neglect, or help support a warrant or discovery).

    It’s illegal, but not unheard of, to try to force journalists to reveal their sources, but the same protections are not universally in place if you reported a finding to a company’s internal affairs, for example. But unlike attorney-client privilege, or shield law protections, the risk in signing an affidavit is, as we’ve seen in recent US trials, that records will not stay sealed, and your name will be revealed to the defense and/or public.




  • For encryption, the client and server need to share their private keys.

    This is incorrect, for asymmetric (public-private) encryption. You never, ever share the private key, hence the name.

    The private key is only used on your system for local decryption (someone sent a message encrypted with your public key) or for digital signature (you sign a document with your private key, which can be validated by anyone with your public key).

    For the server, they are signing their handshake request with a certificate issued by a known certificate authority (aka, CA, a trusted third party). This prevents a man-in-the-middle attack, as long as you trust the CA.

    The current gap is in inconsistent implementation of Organization Validation/Extended Validation (OV/EV), where an issuer will first validate that domains are legitimate for a registered business. This is to help prevent phishing domains, who will be operating with TLS, but on a near-name match domain (www.app1e.com or www.apple.zip instead of www.apple.com). Even this isn’t perfect, as business names are typically only unique within the country/province/state that issues the business license, or needed to be enforced by trademark, so at the end of the day, you still need to put some trust in the CA.