§ Glossary

Glossary

Every acronym in a LOCUS bundle, explained from the general concept down to the details. For anyone who receives evidence and wants to truly understand it.

No term matches your search.

Hash functions

A cryptographic hash function turns data of any size into a fixed-length digest. It is deterministic (same input → same digest), shows the avalanche effect (flipping one bit changes the whole digest) and is one-way: from the digest it is computationally infeasible to recover the original data or to craft another input with the same digest (collision resistance). In LOCUS it is the fixity mechanism: every file has its digest in the manifests, so any alteration — even one byte — makes verification fail.
n byte f SHA-256 256 bit
Any input → fixed-length digest

Hash · Impronta

digest

The fixed-length value produced by a hash function: the file's digital "fingerprint".

SHA-2

Secure Hash Algorithm 2 · FIPS 180-4

NIST-standardised hash family (FIPS 180-4) including SHA-256 and SHA-512: today the de-facto standard for integrity.

SHA-256

256-bit digest

SHA-2 variant with a 256-bit digest (64 hex characters): it is the fixity algorithm of LOCUS' BagIt manifests.

SHA-512

512-bit digest

SHA-2 variant with a 512-bit digest: same logic, wider internal state. LOCUS computes it as manifest redundancy.

MD5

Message-Digest 5 · 128-bit

Legacy hash function, now insecure against intentional collisions. LOCUS includes it only for redundancy and historical interoperability, never as the sole guarantee.

Hash triplo

MD5 + SHA-256 + SHA-512

The three hashes computed over the media in a single pass: redundancy and compatibility with different tools.

Fixity

verifiable integrity

The property by which a file is shown to be unchanged, comparing the recomputed digest with the recorded, signed one.

Digital signatures & elliptic curves

Public-key (asymmetric) cryptography uses a key pair: a private key (secret, signs) and a public key (shareable, verifies). A digital signature proves data comes from the private-key holder and was not altered. Many modern signatures use elliptic curves: instead of RSA's large integers, they use the maths of points on a curve (y²=x³+ax+b); security rests on the hardness of the "discrete logarithm" over those points, which allows far shorter keys for the same strength. Ed25519 signs over an elliptic curve (Curve25519): 32-byte keys, 64-byte signatures, fast and deterministic.
−112 −2−112 xy P Q P+Q
y² = x³ − 2x + 1 (axes to scale, 1:1) — three collinear points: P + Q = R

Chiave pubblica / privata

asymmetric pair

The private key signs and stays secret on the device; the public key is in the bundle and lets anyone verify the signature.

Curva ellittica

ECC

A curve defined by y²=x³+ax+b; cryptography uses its points as a mathematical group, achieving strong security with small keys.

Ed25519

EdDSA on Curve25519

The signature scheme LOCUS uses to sign the manifest, with a device-bound key.

EdDSA

RFC 8032

Edwards-curve Digital Signature Algorithm: the deterministic signature family on Edwards curves to which Ed25519 belongs.

Firma digitale

authenticity + integrity

Cryptographic proof that data comes from a specific key and was not modified after signing.

Non ripudio

non-repudiation

The signer cannot deny it: only their private key could produce that valid signature.

Timestamping & time

A timestamp cryptographically binds a data digest to a certain date and time, without the authority seeing the content. A TSA (Time Stamping Authority) issues it by signing the digest under the RFC 3161 protocol. NTP is used to align the device clock. The EU eIDAS regulation distinguishes an "electronic" timestamp from a qualified one (issued by a QTSP), which enjoys a legal presumption of date/time accuracy.
hash TSA · RFC 3161 token .tsr
The digest + the time, signed by the TSA

TSA

Time Stamping Authority

The trusted third party that signs the digest, binding it to an instant. LOCUS uses Sectigo (and InfoCert for qualified timestamps).

RFC 3161

Time-Stamp Protocol

The IETF standard for the timestamp token signed by a TSA. Verifiable offline against the CA chain bundled in.

TimeStampToken

TST · .tsr

The actual RFC 3161 token: holds digest, instant and TSA signature. In the bundle these are the .tsr files.

NTP / SNTP

RFC 5905 / 4330

Protocol to sync the device clock with a reference server; the bundle records offset and RTT.

Data certa

legally certain date

The legally certain attribution of a moment to a document or digest, enforceable against third parties. The RFC 3161 timestamp (and PEC) provide it.

eIDAS

Reg. (EU) 910/2014

EU regulation on trust services (signatures, seals, timestamps). Defines when a timestamp is "qualified".

Marca qualificata · QTSP

legal presumption

Timestamp issued by a qualified provider (QTSP): in the EU it enjoys the legal presumption of date/time accuracy (eIDAS art. 41).

Packaging & integrity

The bundle is the thing you receive: the evidence package LOCUS produces at every acquisition. In plain words it is a sealed folder holding the evidence (photo, video or audio) together with all the supporting proof of when, where and that it hasn't been touched. Under the hood it uses the self-describing BagIt format (RFC 8493): the manifests list every file's digest and the package is valid only if every recomputed digest matches. The result: anyone can check it themselves, without trusting us.

Bundle

the LOCUS evidence package

The «package» LOCUS creates at every acquisition: a sealed folder (LOCUS-‹Type›-‹uuid›) wrapping the evidence (photo, video or audio) and all the supporting proof — hashes, signatures, timestamps — showing when and where it was made and that no one has touched it. In practice a sealed evidence bag, but digital and verifiable by anyone, without trusting the vendor.

BagIt

RFC 8493 v1.0

The standard (IETF spec) the bundle is structured with: it packages content together with its digests, for verifiable transfer.

Manifest

manifest-sha256.txt

The (signed) list of the SHA-256 digest of every evidence file: it is what lets you notice if even one file changed.

Tagmanifest

the package seal

The list of the digests of the control files (manifest + CASE/UCO sidecar). The timestamp goes on top of it: it is the seal that closes the whole bundle.

UUID

unique identifier

The unique code that acts as the acquisition's «license plate»: it names the bundle folder and is written in the manifest.

Provenance & containers

Content provenance is a signed statement that "travels inside the media", describing its origin and pipeline, so authenticity stays with the file even if extracted from the bundle. It is embedded in the format's native containers: a JUMBF/APP11 segment for JPEG, a BMFF box for MP4. C2PA is the industry framework; LOCUS-PROV-v1 is inspired by it but is not standard C2PA.

Provenance

content provenance

The signed information about how a media file came to be (origin, device, pipeline), embedded in the media itself.

BMFF

ISO/IEC 14496-12

ISO Base Media File Format: the "box" structure of MP4. A uuid box hosts the video provenance.

JUMBF

ISO/IEC 19566-5

JPEG Universal Metadata Box Format: the universal container for JPEG metadata, carried in APP11 segments.

APP11

JPEG segment 0xFFEB

The JPEG application segment where LOCUS inserts the JUMBF provenance, without altering the pixels.

C2PA

Coalition for Content Provenance and Authenticity

The industry standard for content provenance, on which LOCUS-PROV is modelled (without being conformant).

LOCUS-PROV-v1

proprietary provenance

LOCUS' provenance manifest, inspired by C2PA/JUMBF but with a proprietary label: not recognised by c2patool.

EXIF

Exchangeable Image File · 2.32

The JPEG shooting metadata (camera, exposure, etc.). LOCUS preserves them unaltered in the photo.

Watermark

burn-in watermark

The three lines (NTP time, UUID, GPS+heading) burned into the media's pixels at capture time.

Forensic standards

Forensic standards set how to acquire and preserve digital evidence so it holds up in court. ISO/IEC 27037 is the anchor (identification, collection, acquisition, preservation) and defines key requirements such as auditability, repeatability and reproducibility; SWGDE guidelines detail best practices for data, video and images.

ISO/IEC 27037

digital evidence

International guidelines for identification, collection, acquisition and preservation of digital evidence. LOCUS' anchor.

SWGDE 18-F-002

evidence collection

General collection best practices: multiple hashing, contextual documentation, integrity. Applied to all types.

SWGDE 17-V-002

forensic video

Video-evidence acquisition with data integrity. Cited for video.

SWGDE 23-I-001

imaging

Legal and scientific support for the admissibility of image examinations. Cited for photos and video frames.

Catena di custodia

chain of custody

The documented trail of who handled the evidence, when and how, from acquisition onward. In the bundle: the CASE/UCO sidecar + the timestamps.

DEFR / DES

ISO 27037 roles

Digital Evidence First Responder and Digital Evidence Specialist: the ISO 27037 roles of who acquires in the field and who analyses.

Ammissibilità

probative value

A piece of evidence's fitness to be admitted and weighed in court; depends on jurisdiction and the case's circumstances.

Ripetibilità & Riproducibilità

ISO 27037

Same results with the same method and conditions (repeatability) or with the identical method but different tools/operator (reproducibility).

Interoperability

For other forensic tools to read the evidence, a shared vocabulary is needed. CASE and UCO are JSON-LD ontologies describing media, device, location and chain of custody in an interoperable way, easing import into third-party suites.

CASE

Cyber-investigation Analysis Standard Expression

Ontology to represent investigation information in a standard way. In the bundle: the evidence.case.jsonld sidecar.

UCO

Unified Cyber Ontology

The base ontology CASE builds on: a shared vocabulary for objects, devices and relationships.

JSON-LD

JSON for Linked Data

JSON enriched with semantics (links to vocabularies): makes data readable and linkable across different machines.

Geolocation

Position comes from GNSS satellite systems (GPS being the best known): the device measures distance from several satellites and derives latitude, longitude and altitude. Coordinates are turned into a readable address via reverse geocoding (LOCUS uses Nominatim/OpenStreetMap, ODbL licence).
GNSS
Distance from several satellites fixes the position

GPS / GNSS

satellite positioning

GNSS is the category of satellite positioning systems; GPS is the US one, the most widespread. They provide coordinates and accuracy.

Reverse geocoding

coordinates → address

The conversion of latitude/longitude into a readable postal address.

Nominatim / OSM

OpenStreetMap

OpenStreetMap's geocoding service used by LOCUS to derive the address from coordinates.

ODbL

Open Database License

The licence of OpenStreetMap data, with an attribution requirement.

Fuso orario IANA

e.g. Europe/Rome

The standard time-zone identifier (IANA database) recorded next to UTC times to reconstruct local time.