What's the deal with Deno? We talk with a major contributor to find out. Listen now.
72

If you want to prove to others that you took the screenshot on a specific date and not later, you will not be able to do it yourself, you will have to rely on some common trusted third party. For low importance issues, this can be accomplished by simply posting the image on some well known public service where the date when the image has been posted will be ...


56

Uploading a hash of the screenshot to the Ethereum blockchain allows anybody in the future to make sure that the screenshot was taken before the hash was uploaded. Of course, you should choose a hash function that is cryptographically secure (and in particular, collision-resistant). If you however also need to make sure that the screenshot wasn't taken ...


39

If all parties can trust a common randomness beacon (like the NIST Randomness Beacon), this can be achieved by including a recent block from the beacon into the file along with its timestamp. The recipients then, in addition to verifying the signature, must also verify that the beacon data is authentic and as recent as they require. Other public random ...


17

Ask a mutually-trusted third-party to use their own independent equipment to make the screenshot and ask them to date and sign it (digitally or using ink) The normal way is to pay a solicitor/lawyer/notary to do this. It is trivial for you to fake a date in image metadata (EXIF etc) or in a digital signature - so you need certification by someone that will ...


16

Update 2017-11-05: "TLS-N" and others I only recently learned of the existence of a new project. Some guys from the university of Z├╝rich are working on something called "TLS-N" which is dedicated to bringing non-repudiation to TLS. There is no RFC that I know of yet. But they have a white paper. I'm not sure when/if we'll ever see this in ...


15

Encryption with a secret symmetric key does not prove authenticity unless you use an authenticated encryption mode of operation such as GCM. Authenticated encryption algorithms generate a Message Authentication Code (MAC) in addition to encrypting the message, and if the shared key is properly secured this can be used to prove the authenticity and integrity ...


11

Encryption does not protect against malicious alterations. If you encrypt some data with a stream cipher like RC4 or AES-CTR, then an attacker can decide to flip any bit he wants on the ciphertext, and, upon decryption, this flips the corresponding bit in the plaintext. This allows surgical modifications. With block ciphers in CBC mode, things are a bit less ...


11

There is no need to rely on a trusted third-party. Besides the excellent suggestion to use a blockchain (the answer by Christian), you could use a publically verifiable service like the excellent Stamper Even better, store the screenshot in several (unrelated) of these services. Even the most paranoid checker would no longer be able to complain. PunKeel on ...


8

I think there are 3 parts to this question, and I think I can reasonably answer all three. I think parts 1 & 2 have been mostly answered above, but I think this will link them together. I added a related followup question: Can I prove that a file (screenshot or otherwise) was generated on or before a particular timestamp? Add a copy or secure hash of ...


8

One simple protocol that can be verified by a certain target user but not by third party: Use a Diffe-Hellman keyexchange on your key and the receivers key Use the shared key to encrypt a message and add a MAC This protocol offers the first three properties, but not the fourth. So the answer is NO. Everybody who knows the shared secret can forge the MAC. ...


8

Non-repudiation is not done with public keys; non-repudiation is done with a legal framework which defines responsibilities and duties. Though details depend on the jurisdiction, most will more or less follow the following scheme: A signature that you perform is binding as long as you did it. That's the definition. The rest is about what happens in case of ...


6

This is an interesting question because it is almost entirely nontechnical. One presumes from your question that you are releasing something that would offend more than one national government. Digital Opsec Compartmentation: Only work on it using resources that are not associated to you. One cross-contamination will burn you (that is how DPR was sent up -...


5

As in any other aspect of life, one might have different information security goals in different situations. There are situations in which you want non-repudiation and there are situations in which you would want plausible deniability. Likewise, there are situations in which you would want non-repudiation on some aspects but plausible deniability on others. ...


4

MasterCard and VISA enforce very strict regulations on any system which operates in any way in the vicinity of their precious credit cards. If a bank or an ATM operator lets the communication be tapped, then the VISA thugs will skin them alive, trample their organs, then expose their dismembered bodies on the Wall Street Bull, as a warning for other banks. ...


4

You need a trusted 3rd-party to witness and vouch for every commit. For example, if you use an online repository such as GitHub, then there is an online record of each commit. If you are not using a trusted 3rd-party service, then you need to use a notary or similar service. This could be a person who witnesses each commit, or an online notary that performs ...


4

Search this site on non-repudiation. You'll find lots of information about the topic. In particular, you'll discover that non-repudiation is not a technical property (contrary to what cryptographers might tell you); it is primarily a socio-legal property. Thus, non-repudiation cannot be assured through technical means alone: it can only be achieved ...


4

Here is a rundown on the example of emails: Interception or Snooping or Sniffing An attacker intercepts the unencrypted traffic of an email server to record and modify the content of sent and received emails. (Your ISP, router or network administrator are all able to sniff/intercept the unencrypted traffic that they process.) Spoofing An ...


3

Answer 2 is nonsensical; it literally says "we can prove who the sender is because two people have the ability to create the MAC." With a MAC, either party could have created the MACed message; each party knows who created it (you know if you wrote something or not, and if you didn't the other guy did), but they can't prove that to anyone else, nor can they ...


3

If you are afraid of "snooping" then why would you use signatures ? A "snooper" is a passive eavesdropper, who wants to see the data but certainly not to make you aware that your emails are inspected. They won't alter emails, or send fake emails, which are the kind of things that signatures can help against. If you want to defeat such sniffing, then you ...


3

Legal matters depend on jurisdiction, and there are a lot of those. However, in many of them, a signature is "legally-binding" if the signer really did it. When you sign, how you do it does not matter as far as legal binding is defined; putting your name at the end of an email is also a legally binding signature. Several cases have shown that an oral ...


3

The answer to your question would be: no. The reason behind it being that the only one losing a bit of money if all of your previous mentioned exploits were possible, would be the bank. A bit of money you say? Yes a bit of money, the money you can loose with an ATM are rather low compared to, for instance, SWIFT transactions. Now does that mean there aren'...


3

how could the document-signing service verify that someone who signed a particular document really did so? They don't. They do create a log showing the IP address of the remote computer that issued the "signature"; but they can't identify the legal entity that caused the signature to be made. If the identity of the signer turns out to be in dispute, the ...


3

Technically -- yes, they could. However, there are few thoughts: 1) web page code cannot interact with browser's address bar. 2) an attacker may write a plugin/extension if web browser provides interfaces for such interactions. 2.1) an attacker can spoof browser's binary modules to change browser behavior. However, this will require source code knowledge ...


3

Digital signature can indeed provide non repudiation, provided that the procedure used to sign the certificat: ensures that the private key was at any moment under exclusive ownership of its recipient (optionally) ensures that the signed cert was given to the right person As soon as 1 is established, the certificate authority can attest they actually ...


3

It seems contradictory but it's not. One doesn't have to prove non-repudiation and plausible deniability at the same time. You can deny the ownership of the message while still keeping its authenticity or you can prove your authorship by digitally signing it. But you can't do both at the same time. A specific use case is in Signalapp messaging protocol, it ...


3

I suspect this will be a big "It depends on your architecture" and so random internet people won't be able to give you a complete answer. Off the top of my head, here's some scenarios where it might make sense to have client-auth TLS and payload signatures. The first are network constraints: The TLS is terminated by CloudFront and the app server / backend ...


2

None Repudiation refers to having proof of any transaction made from the requester to the authoriser and also from the authoriser to the requester. this is an electronical proof that will have information of the person who made any transaction. eg: a client will go to a bank and request to change a password for his/her bank account, the teller or the ...


2

I don't find any draft beyond the last one (expired since June 2008). I am not aware of any existing implementation. Anyway, the draft is incomplete and inconsistent (e.g. the ContentFormat type is defined twice, with distinct incompatible values; the tls_sign value is undefined) and quite poorly explained (from what I can see, it says nowhere what is ...


2

Non-repudiation binds the sender, not the recipient. I could, for example, digitally sign a message intended for you. I wouldn't be able to deny composing the message, but suppose I never sent it? You'd never get it, even though it was digitally signed. I can't think of any mechanism not requiring the cooperation of the recipient that proves receipt of ...


2

I'd like to to rephrase your question as this: "Is there a way to make sure, in a cryptographic way, that two different views of some data are, in effect, related the same information ?" I would see two approaches to that problem. The first one starts with the data, the second one, with the final view. Data-centric In order to implement this, you need to ...


Only top voted, non community-wiki answers of a minimum length are eligible