Vilket krypteringsformat är mest förekommande, när det gäller digitala signaturer/filsignering?

Om man vill signera filer (okrypterat), alltså med digital signatur och certifikat köpt av en 'CA authority', och signera filer enbart för avsikten att visa att A) filerna kommer från en källa som går att verifiera, och B) filerna är oförändrade från när källan skickade dom (checksum)

... vilken slags krypteringsnyckel är då mest förekommande, bland folk o företagare där ute, världen över?

Frågar för om jag ska köpa cert så .. vill jag bara folk och fä där ute ska kunna använda/verifiera det så lätt som möjligt. Vill bara så direkt kompatibel med vad som används mest där ute, så folk inte ska behöva installera en massa exotisk shit som inte är konventionell, bara för att kolla källan och checksum. Gärna för både privat och småföretag, globalt sett.

Privat är jag mest van vid att signera (okrypterat) med PGP nyckel (RSA), nån enstaka gång med AES-nyckel (openssl).
Antar att dom två är dom mest förekommande 'out there' ? Eller ...?

Eller ... har jag missförstått något i konceptet, och frågan är fel ställd?

Tack för tips

Tackar för svar.

Min tanke, är att filerna ska kunna verifieras inte bara av första 'slutkunden', utan även i andra-, tredje-, fjärde-, femte led osv om dom sprids vidare. Det är ju bara första mottagaren av filerna som kan verifiera (via t.ex. https, sftp el. dyl) att filerna kommer från rätt ursprung.

Vill man tillgodose behovet att ännu senare led ska kunna verifiera exakt ursprung, så räcker inte bara checksummor, eftersom en man-in-the-middle kan ha manipulerat filerna, och sen skapat ny checksum-fil från det manipulerade materialet, och ändrat 'creation date' infon för checksumme-filen till samma datum som filerna, så checksumman ser ut att vara lika ursprunglig som filerna.

Därav tanken på ett CA-certifikat som man kan signera filerna med. Sån signering innehåller ju automatiskt SHA256 checksumma som inte går att manipulera. Men så är det ju sant att ett cert har begränsad validitets-tid. *muttrar*

Men, om man fixar ett sånt cert, med giltighetstid 1 år ... är det inte så att en verifiering om 2 år kommer säga BÅDE att certet inte längre är giltigt OCH ändå visa vem certet ursprungligen var utställt till?
Inte direkt konventionellt eller proffsigt om man säger så, men ... ja ...

.. det kanske framgår vilket problem jag försöker lösa då Plus förstås att fråga vilket krypto-format som är mest direkt tillgängligt för så många som möjligt så verifiering ska gå så direkt/smidigt som möjligt (eg trådämnet). Ni kommer med irriterande bra utmaningar här ,..

Det går ju, t.ex. om man PGP-signerar både checksummefilen och källfilerna, med en PGP-nyckel som inte är CA verifierad. Men problemet är då att det kan ju lika gärna en man-in-the-middle göra i efterhand också (göra manipulation av filerna, skapa ny checksumma, och signera detta med falsk nyckel osv).

Men visst fasen ja?! Signering görs ju inte med publika nyckeln, och CA cert verifierar ju bara publika nyckeln. Hah, brain error där.

Så om nån ska kunna verifiera signerade filer, då måste dom fixa min publika nyckel OCH den måste vara verifierbar. CA kan göra den verifieringen, iaf under begränsad tidsperiod. Men man kan ju lika gärna posta icke-tidsbegränsad publik nyckeln på egen https-server, med eget CA-verifierat SSL-cert, som verifiering. Så länge man ser till att hålla det certet aktuellt och giltigt så .. fan det kan funka.

För/nackdelar blir då t.ex. att väga begränsningen CA-certs limiterade tidsperiod, mot risken för digitalt inbrott på egna servern (hacker ersätter min publika nyckel på servern med en fejkad). Och med tanke på att det inte är diamanthandel eller ekonomiska transaktioner man ägnar sig åt i det här fallet så ... är ju inte risken direkt kolossal ...

Hm ... ska låta det här snurra runt i skallen några timmar bara, så jag inte missar nåt

Mm, inte alltid man definierar det 100% för sig själv innan man frågar ens
Jag utgår enbart från behov i det här fallet, och försöker tillgodose dom behoven, utan att ta för stor hänsyn till konventioner och traditioner. Så jag kolliderar dom råa behoven med dom etablerade tekniska konventioner som kan finnas (som jag finner på vägen), och ser hur långt jag kan uppfylla behoven på den vägen.

Råa behoven är att ... filer, eller material som jag släpper ifrån mig, ska gå att helt säkert (100%) verifiera så att dom verkligen kommer från just mig OCH ej är manipulerade (av mellanhand). Båda faktorerna på samma gång, och ska vara möjligt för all framtid.

Till detta, ska det (helst) gå att verifiera utan kontakt med mig (ja kan vara död t.ex.), och vara så en så enkel procedur att även 'dator-dummies' kan göra det. Det ska helst vara utformat så att förfalskningar/manipulation blir lätta att märka av, på det här sättet, även av dator-dummies, utan att behöva nån slags avancerad procedur. Behöver man göra en avancerad procedur, är det lätt att dummies skiter i verifiering (eller kanske inte ens känner till själva förfarandet öht) och då kan förfalskningar/manipulering lätt gå dom förbi - även förbi erfarna användare som inte fått sitt morgonkaffe än.

Ser man från perspektivet 'hur det brukar gå till', eller vad som 'är realistiskt', då framstår jag nog som .. ja .. nånting skumt Jag får väl kalla mig "Visionär", i brist på andra smickrande termer .

Ja, instämmer. Och ännu färre kan spontant använda OpenSSL/AES256, som lär vara näst vanligaste (för symmetrisk kryptering).

Önskar det fanns lättare sätt. Tycker vi lever i en tillvaro där ID-kapning och deep-fejk, manipulation och missbruk är för lätt.

Så ... det finns alltså egentligen inget .. eh .. konventionellt använt sätt att liksom "vattenmärka" filer på, någon typ symmetrisk kryptografisk signatur eller något snarlikt, som t.ex. ett företag kan verifiera tillhör mig som individ?
Det är asymmetriskt som gäller?