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

Permalänk
Medlem

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

Permalänk
Medlem

Om du enbart vill att slutanvändaren ska kunna verifiera att filen kommer från dig, så räcker det väl att du anger checksumman på hemsidan och ber slutkunden verifiera att filen de laddat ner har samma checksumma?

Windows har ju inbyggt stöd för att kontrollera filers checksummor, så det borde ju vara det absolut enklaste.

Visa signatur

MSI PRO Z790-P WIFI | Intel i9 13900K | 128 GB DDR5
GTX 4070 12 GB
Samsung 990 Pro 4 TB | WD Black SN850X 2 TB Gen 4 | 2 x 1 TB Samsung 970 EVO Plus
3 x ASUS 27" | 1 x Philips 49"

Permalänk
Medlem

CA-certifikat har idag begränsad 'hållbarhet' och är tänkt för att auktorisera själva resursen man hämtar ifrån som en website.
Det vore nog dumt att låsa en fil mot en CA-certifikat som tiden går ut på medans en hashvärde av god kvalitet är något som består.

Många opensource-site har ofta ett flertal olika typer av hash-värden för samma fil att tanka ned separat.

Permalänk
Medlem
Skrivet av Superfrog:

Om du enbart vill att slutanvändaren ska kunna verifiera att filen kommer från dig, så räcker det väl att du anger checksumman på hemsidan och ber slutkunden verifiera att filen de laddat ner har samma checksumma?

Windows har ju inbyggt stöd för att kontrollera filers checksummor, så det borde ju vara det absolut enklaste.

Skrivet av xxargs:

CA-certifikat har idag begränsad 'hållbarhet' och är tänkt för att auktorisera själva resursen man hämtar ifrån som en website.
Det vore nog dumt att låsa en fil mot en CA-certifikat som tiden går ut på medans en hashvärde av god kvalitet är något som består.

Många opensource-site har ofta ett flertal olika typer av hash-värden för samma fil att tanka ned separat.

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).

Permalänk
Medlem

PGP-signering funkar alldeles utmärkt. Det är bara att publicera pubkey själv. Se till att den är publicerad på en http-server som har TLS bara.

Signatur görs inte med certifikat, signaturer skapas med den privata nyckeln.

Permalänk
Medlem
Skrivet av Dooley:

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).

Vad är det faktiska problemet du försöker lösa egentligen? Det låter lite krystat allt du beskriver. Det normala är att man publicerar checksummor på orginalkällan som redan nämnt i tråedn. Användare kan sedan ladda ner filerna från var som helst men de måste naturligtvis kontrollera checksummorna mot de som publicerats hos orginalkällan.

Du kan ju även signera filen med pgp men även där krävs lite arbete från slutanvändaren. En CA signerad pgp nyckel har jag aldrig hört talas om och då har jag nog pillat mer med pgp än de flesta (men skulle fortfarande inte beskriva mig som expert).

Så vad exakt är problemet du behöver lösa?

Visa signatur

Archlinux, Sway och Rust, vad mer behövs?

Permalänk
Medlem
Skrivet av dlq84:

PGP-signering funkar alldeles utmärkt. Det är bara att publicera pubkey själv. Se till att den är publicerad på en http-server som har TLS bara.

Signatur görs inte med certifikat, signaturer skapas med den privata nyckeln.

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

Permalänk
Medlem
Skrivet av Gräs-Mannen:

Vad är det faktiska problemet du försöker lösa egentligen? Det låter lite krystat allt du beskriver. Det normala är att man publicerar checksummor på orginalkällan som redan nämnt i tråedn. Användare kan sedan ladda ner filerna från var som helst men de måste naturligtvis kontrollera checksummorna mot de som publicerats hos orginalkällan.

Du kan ju även signera filen med pgp men även där krävs lite arbete från slutanvändaren. En CA signerad pgp nyckel har jag aldrig hört talas om och då har jag nog pillat mer med pgp än de flesta (men skulle fortfarande inte beskriva mig som expert).

Så vad exakt är problemet du behöver lösa?

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 .

Permalänk
Medlem
Skrivet av Dooley:

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 .

Den enda tekniska lösningen jag skulle använda isåfall vore pgp som lär finnas kvar under lång tid då den mesta pakethanteraringen under Linux använder detta för den typ av verifikation du pratar om.

Det är inte magi dock och någonstans måste tilliten läggas oavsett. Antingen möter du dina användare fysiskt och get dem din publika nyckel samtidigt som du visar fotolegitimation eller så måste du lita på en tredje part någonstans.

Och den absoluta majoriteten av datoranvändare har ingen aning om vad pgp är eller hur det används

Visa signatur

Archlinux, Sway och Rust, vad mer behövs?

Permalänk
Medlem
Skrivet av dlq84:
Skrivet av Gräs-Mannen:

Den enda tekniska lösningen jag skulle använda isåfall vore pgp som lär finnas kvar under lång tid då den mesta pakethanteraringen under Linux använder detta för den typ av verifikation du pratar om.

Det är inte magi dock och någonstans måste tilliten läggas oavsett. Antingen möter du dina användare fysiskt och get dem din publika nyckel samtidigt som du visar fotolegitimation eller så måste du lita på en tredje part någonstans.

Och den absoluta majoriteten av datoranvändare har ingen aning om vad pgp är eller hur det används

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?

Permalänk
Medlem

Med tanke vilket stön och stånk det var att få användare att börja använda 'https' med TLS/SSL med risken för sin framtid existens när Firefox och Google Chrome gjorde 'all in' samtidigt (på dagen typ) genom att göra det besvärligt att surfa på website som inte hade https:

Nu klarade man det och få ens tänker på det idag bara för att Google Chrome (via mobiltelefoner i enorma antal) och Firefox tillsammans var större än Internet Explorer räknat i antal - då MS som i många andra sammanhang släpade benen efter sig ganska rejält och införde liknande mekanism först efter att de flesta av de stora website som pga. Firefox/Chrome agerande tvingades siterna att aktivera https för att behålla sina besökssiffror och därmed ge tryck med https-stöd på alla andra webbrowser också - typ.

Att bygga infrastruktur som också hanterar säkerhet och spårbar källa är inte lätt då varje extra moment för den som tar emot innehållet upplevs väldigt störande och jobbigt och hellre avstår i många fall om det finns enklare väg... - och som redan sagt - väldigt få vet vad PGP och openSSL/AES256 är för något och än mindre i hur det skall användas - skall sådant fungera så måste det gå på automatik.

Varför CA-certifikat har kort hållbarhet beror på att sådana slarvas bort, kapas eller luras till sig - företagen som har CA-certifikaten kan byta skepnad från seriös till oseriös nivå, använda hash och krypto-algoritmer visade sig för svaga (md5 och SHA1) etc.

Därav utställs inte längre några långlivade CA-Certifikat mer än på enstaka år.

---

Symmetrisk kryptering innebär att båda sidorna måste känna till samma nyckel och det har varit ett klassisk problem sedan romartiden i hur man för över nyckeln utan risk för läckage på vägen och också från motståndarsidan lagt massor av kraft och resurser för att komma åt dessa nycklar och tex. fått folk att gräva i latriner efter lappar som har torkats i röven för att lapparna hade engångskryperingsnycklarna tryckta på sig då det producerades massor av dem under krigssituation medans det var ont om toapapper...

Asymmetrisk krypto är en rätt modern företeelse och blev inte publik känd förrän typ under 80 och 90-talet även om matematiker och kryptoexperter känt till det sedan mitten av 1970-talet men var belagda med munkavlar och den publikation Ron Rivest, Adi Shamir and Len Adleman (RSA) gjorde var med risk för sina liv och sina karriärer då det var stora intressen från militärt håll att det inte läckte ut, och tex. England hade utarbetat ett liknande system redan 1973 (och lyfte sekretessen om detta först 1997) och var inte helt glada när principerna för detta blev publika till slut.

hur eller hur - asymmetrisk kryptering löste ett jätteproblem - nyckeldistrubition - att kunna kryptera med en publik nyckel allmänt känd men kan bara 'öppnas' igen med den privata nyckeln som den publika nycken skapades av en gång i tiden - kryptografers våta dröm och löste ett flertuseårigt problem.

Därför går det inte att 'ersätta' en asymmetrisk del med en symmetrisk del, men samtidigt är asymmetrisk kryptering jättejobbig och inget för volymdata - därav att dagens krypteringsprotokolla har båda delarna - asymmetrisk del för att hantera nyckeldistrubitionerna/förhandlingen för de symmetriska sessions-nycklarna som sedan används för volymdatat.

tex. SSH förhandlar om ny session-nyckelpar typiskt per minut eller när viss mängd med data är överfört då det farliga som många inte tänker på och inför potentiell vekhet i kryptering är om för mycket data körs på samma nyckel så använde man för stor del av nyckelns totala kod-rymd för att behålla den tänkta attackmotståndet.