Some random quick VIDA things

[hackerfactor]

From "Named Relay":

Some random quick VIDA things i thought of:

• Alternatively of TXT records, the /.well-known/ directory could probably also be used as a fall-back?
• With leaked and revoked keys, how do you know an image is truly from before the leak and not crafted? (You don't enforce my third step?)
• RSA is expected to be completely broken when we hit Post Quantum Computing. (Shor's algorithm)
• About the byte ranges, should there be a warning if part of the image data is outside the range?
• No Perl implementation planned? (for Exiftool)

Lastly, where is VIDA coordinated?
(Is there a Discord server?)

[named-dodo]

So it's coordinated here...
(I'm "Named Relay", hi!)

[hackerfactor]

Hello Named Relay,

I've moved your questions here since my blog isn't the right forum for them.

1. Using /.well-known/ instead of TXT:

While /.well-known/ is definitely a convenient location, it makes the protocol dependent on a web server. That means the owner of the web server knows each time someone wants to authenticate the signature, the IP address of the person making the request (includes geo-location and identifying their company based on ASN), the user-agent string of the request (operating system), the OS platform (TCP profiling), and more. Basically, it enables tracking and privacy violations.

DNS is a distributed store-and-forward system. If I run my own DNS server, I can only tell "when" someone wanted to validate, but not who or other personal information. Moreover, DNS servers cache results, so it won't identify repeated queries.

While using /.well-known/ is technically doable, I'm going to need some convincing that it is worth the privacy concern.

2. With leaked and revoked keys, how do you know an image is truly from before the leak and not crafted? (You don't enforce my third step?)

Timestamps are only as reliable as the person signing the timestamp. I'm going to assume you're using a third-party signer (the more complicated workflow). If you run your own timestamp server, then you can definitely backdate/postdate the signature. However, if you use someone else's timestamp server, then they need to be in on the forgery. It's a safe bet that a widely trusted time service won't be in on it.

If you sign your own timestamp, then: yes, it can be backdated/postdated.

I'm very open to suggestions for how to record and report the 'trust level' to the user who is trying to validate it!

3. RSA is expected to be completely broken when we hit Post Quantum Computing. (Shor's algorithm)

Yeah! I'm waiting for NIST to approve something beyond RSA. When that happens, we'll need to support the new algorithm. Meanwhile, VIDA supports a "ka=" parameter for specifying the algorithm. Right now, it's defaulting to "ka=rsa". My C/C++ implementation (still in developement) also supports "ka=ec" for any elliptic curve algorithm supported by openssl (version 3.x) libssl and libcrypt.

4. About the byte ranges, should there be a warning if part of the image data is outside the range?

That's covered in: https://github.com/hackerfactor/VIDA/blob/master/SPECIFICATION.md#metadata-signature-format
If the byte range begins before the file or ends after the end-of-file, then it's an error.
However, I explicitly permit people to exclude parts of the file if they really want to. (If you want to make your signature insecure by not covering the entire file, that's up to you.) The reason I permit this: streaming videos may have a signature every x record (e.g., every 2 minutes, every 100 megs, etc. using "b=p-s,s" and databases might require some tables to be excluded.

It probably wouldn't be a bad idea for the validation tool to include a warning, such as "x bytes were not covered by the signature", but I think that needs to be validation program dependent. (Please convince me that it should be in the spec!)

5. No Perl implementation planned? (for Exiftool)

Oh! I absolutely want a perl plugin for Exiftool! Phil has an API for ExifTool "exiftool --config vida.pl" where you can insert your own add-on. However, Phil doesn't want to modify his copy of ExifTool (and I agree): the base ExifTool has no external dependencies so it never calls openssl or DNS. Those would be the functions added to vida.pl.

If my perl wasn't so rusty, I'd do it myself. But I'm faster at programming in C, so I'm building the C/C++ version first. If you're interested, please do it!

[named-dodo]

What i think of that can be validly excluded:
- checksums
- signatures of following VIDA records (VIDA records should always include previous signatures to seal them against tampering.)
- possibly other signing standards. (How would C2PA react to an additional VIDA signature in the file?)

So determining the needed/acceptable byte ranges is indeed a per-fileformat job.
(You would need to recalculate the checksums anyways.)

What do you think about my idea of timestamping signatures?
I'm not a cryptography expert, so i am not sure if it's good, unnecessary or perhaps even flawed.
Seeking your input on this.

[hackerfactor]

Honestly, I think VIDA is flexible and both work.

Option 1: Using an external signing service, the timestamp can be set and signed at the same time as the signature.
<vida ... d=DomainOfSigner id=Username b=p~S,S- fs=date s=Date:Signature>
This means only one provider (the external signer) knows that the data existed at a specific time, and username identifies the registered user at domain who attests to the signature.
<vida ... d=domain.com id=abc123 b=p~S,S- fs=date s=Date:Signature>
In this case, domain.com attests that the time is accurate and that there is some user "abc123" registered at the domain who attests to the contents being signed. User abc123 could be anonymized.

Option 2: Sign it yourself AND then have a a second VIDA signature that includes an external signer.

<vida ... d=mydomain.com b=F~s  s=signature>
<vida ... d=domain.com id=abc123 b=p~S,S- fs=date s=Date:Signature>

In this case, the domain "mydomain.com" attests to the contents, while domain.com attests to the timestamp, and account abc123 at domain.com attests to the contents with the timestamp. The benefit of this approach is that account abc123 may be anonymous, but mydomain.com is not.

Both options work and are supported.

[named-dodo]

Option one is probably something that would happen within larger organizations.
Or perhaps at online websites that focuses on media sharing, allowing end users to sign off on their media.
(But it still allows for backdating the moment that that single private key is leaked.)

Both options will have to send something to sign to a remote server.
Is there already a protocol spec for? (If not, that should be it's own discussion)

For option 2, you need a timestamping service who accepts this protocol. (or translate it to an already existing one?)

• We must not let big tech do it. (for obvious reasons)
• We could roll out our own timestamping servers
• We could let other unknown users roll out these servers.
• We could poke Let's Encrypt or other CA's to see if they are interested.

[hackerfactor]

Funny you mention that... I've started work on a third-party timestamp signer for VIDA. It will have account registration and signing.

[named-dodo]

There is an RFC for trusted timestamping: https://www.rfc-editor.org/rfc/rfc3161
And it seems that at least digicert has a (public?) timestamping service:
https://knowledge.digicert.com/general-information/rfc3161-compliant-time-stamp-authority-server
Sectigo also provides one: https://www.sectigo.com/resource-library/time-stamping-server
Let's encrypt does not, as far as i can tell.

But the more i look into it, the more it seems that setting up our own public timestamping servers isn't that weird of an idea.

[hackerfactor]

Regarding a discord server:

Great idea! I just don't know what sort of moderator effort it would take. (I really don't want to be inundated by spammers, haters, etc., so it will require monitoring.)

[andreysaf]

@hackerfactor you can also drop your username here, this way I know it's you. @named-dodo same here, what's your username? You can see it as a user first.

[named-dodo]

I sent you a DM, i'm that 🦤.

[andreysaf]

Sorry, where did you send? I didn't think GitHub had DMs. For discord, I am @speckle0514

[hackerfactor]

(Sorry for the delay in replying, Thursday and Fridays are busy days around here as we have meetings to discuss the upcoming meetings about future meetings.) I don't see your DM on discord and discord doesn't see anyone named "@speckle0514". On discord, I'm using "@hackerfactor".

[hackerfactor]

I just clicked the "+" to create a discord server.

[named-dodo]

In the spec about the b=range field:
The s literal may be included in a parenthetical with offsets. For example: b=-(s-100),(s-50)-s,(s+10)-. This denotes a concatenation of three byte ranges. The first goes from the beginning of the file to 100 bytes before the start of the signature. The second is 50 bytes before the signature to the start of the signature. The third denotes 10 bytes after the signature to the end of the file. (Why would you do this? You probably wouldn't; this is just an example. What about fileformats that have their own digests/checksums? You would want to exclude that and calculate them after you signed the file, so it doesn't break the file's own spec. )

Here my quick thoughts:
I would suggest replacing the - (minus) for range indication with a : (colon).
This removes ambiguity between a subtraction and range indication, eliminating the need for parsing parentheses:

b=-s,s- becomes b= :s,s:
b=-(s-100),(s-50)-s,(s+10)- becomes b=:s-100,s-50:s,s+10:
It may look less pretty, but it's a lot easier to parse.

And if there's a checksum at the end of the file, you would need to specify that somehow.
Beginning of the file is easy, that's (probably) 0. End of the file can be anywhere.
Suggestion: introduce begin and end of file markers next to signature marker: b=b:s,s:e.
Example: b=b:s,s:e-32 <- last 32 bytes are fileformat own's checksum. Can be calculated after VIDA signing if it's critical to be correct.

[named-dodo]

Ah yes, we are going to write a math parser... 😅
I think that we should keep it easy to parse, for security and implementation correctness sake.

Something like this: b=b:s-100,s-50:s,s+10:e

1. Split on , to get an array of ranges. s-50:s
2. Split on : or _ or <insert alternative range separator> s-50
3. First character is always a letter: b for begin of file (0), s for begin or end of signature, e for end of file.
4. After the first character is an optional +/- followed by a decimal number.
5. Anything not following this format is considered malformed.

Though regardless of choice, it may be tricky to determine whether s is representing the begin or the end of the signature.
It should be possible to determine, but it might be better to make d represent the end of the signature. (d because it's next to s 🙃 )

[hackerfactor]

I understand the ambiguity for using "-" for both math and range.
How about using tilda "~" for range? b=b~s,s~e

Regarding the ambiguity of whether "s" is the beginning or end of the signature... I was just thinking about that last night. Would it be better to use capitals and lowercases? "S" for the start and "s" for the end? Then P and p is also no longer ambiguous. Then again, begin and end of file (b and e) could be replaced with "F...f" for file. b=F~S,s~f

Thoughts?

(By the way, THANK YOU for being a sounding board here. This is exactly the type of shake-out that the specification needs.)

[named-dodo]

Tilde ~ for range seems like a decent choice to me.
Lets go with that.

Personally i would love to avoid lower/capital differences.
(I usually prefer to pull data trough a toLowerCase function just to be sure my string comparisons fail on that...)
But in this case it might be okay. Especially since casing must be preserved anyways.

You're welcome.

[hackerfactor]

I usually prefer to pull data trough a toLowerCase function

That's going to screw up any base64 encoding for the signature. Also, other fields, like uid and id, are case-sensitive.

[named-dodo]

I know, i obviously use toLowerCase only on data that is not case-sensitive.
I think i have had a bad experience somewhere in the past where someone provided data that was uppercased while the spec said otherwise...

[jsklein]

- - Alternatively of TXT records, the /.well-known/ directory could probably also be used as a fall-back? - IETF RFC 9116 for ‘security.txt’ File - Digital Signature - Contact - mailto, tel as a URI - Encrypted field - URL: https://example.com/pgp-key.txt - DNS: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY - OpenPGP fingerprint: openpgp4fpr:5f2de5521c63a801ab59ccb603d49de44b29100f - Canonical: https://www.example.com/.well-known/security.txt - Canonical: https://someserver.example.com/.well-known/security.txt - Expire time: Less than 1 year in the future - Policy: https://example.com/security-policy.html - Many more features - RSA is expected to be completely broken when we hit Post Quantum Computing. (Shor's algorithm) - Post-Quantum Cryptography Status - I am monitoring NIST, IEEE, and IETF for early code - NIST: - Migration to Post-Quantum Cryptography: Preparation for Considering the Implementation and Adoption of Quantum Safe Cryptography https://www.nccoe.nist.gov/sites/default/files/2023-04/pqc-migration-nist-sp-1800-38a-preliminary-draft.pdf - Migration to Post-Quantum Cryptography Quantum Readiness: Cryptographic Discovery https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38b-preliminary-draft.pdf - Note: Initial testing will include: - Post Q algorithms are being tested. Currently, with SSH. - Kyber-512, Kyber-768, Kyber-1024 698 - P256+Kyber-512, P384+Kyber-768, P521+Kyber-1024 - Current RFC updates available: https://wiki.ietf.org/group/sec/PQCAgility - OS: Ubuntu 22.04, Windows 10/11 - Apps: Google Chrome, VLC Media Player, OpenVPN COnnect, GRR Rapid Response, SLACK - No IPv6: Java Runtime Environment - "Currently, many openjdk tests fail when run in an environment where IPv4 is non-existent, notably because 127.0.0.1 is no longer a valid IP address for the local host. All tests should pass, and hopefully various organizations will do regular testing in such environments." Note: No testing has been done since 2019. Seems they are using the RFC 2460 (1998) https://bugs.openjdk.org/browse/JDK-8179037. They need to update to IETF RFC 8200. - About the byte ranges, should there be a warning if part of the image data is outside the range? - I have no context on this? Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) "*I skate to where the puck is going to be, not to where it has been." -- *Wayne Gretzky "I never lose. I either win or learn" - Nelson Mandela

…

On Mon, Jul 8, 2024 at 4:50 PM Dr. Neal Krawetz ***@***.***> wrote: From "Named Relay": Some random quick VIDA things i thought of: - Alternatively of TXT records, the /.well-known/ directory could probably also be used as a fall-back? - With leaked and revoked keys, how do you know an image is truly from before the leak and not crafted? (You don't enforce my third step?) - RSA is expected to be completely broken when we hit Post Quantum Computing. (Shor's algorithm) - About the byte ranges, should there be a warning if part of the image data is outside the range? - No Perl implementation planned? (for Exiftool) Lastly, where is VIDA coordinated? (Is there a Discord server?) — Reply to this email directly, view it on GitHub <https://github.com/hackerfactor/VIDA/discussions/4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3ULXR5RH7JLALCB4FZDO3ZLL3SLAVCNFSM6AAAAABKRR2A2SVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWHEYTGMBTGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hackerfactor]

Joe, you were a little terse and hard to follow, so I'm going to summarize your concern here:

The concern he's trying to address... RSA is going to be going away. It will be replaced with Quantum. The public key size for quantum algorithms might be too large for DNS over UDP. (Packet fragmentation over UDP isn't fun or high performance.) That leads to looking at other protocols and how they are supported on different platforms.

[hackerfactor]

This is a long thread on a variety of topics. I'm going to start some of these individual points as their own discussion threads.

I'm starting new discussions for ka=rsa (defaulting to a soon-deprecated algorithm) and b= (formatting) into their own discussions.

[hackerfactor]

All of these topics have been turned into separate discussions. I'm going to close this general discussion so we can focus on each individual item.