Lätt att knäcka BASE64-d scramblad text?

2017-01-21 07:20

Medlem

Plats: Mumindalen
Registrerad: Maj 2003

●

Lätt att knäcka BASE64-d scramblad text?

Skulle va tacksam för lite hjälp att utvärdera säkerheten i en funktion jag kör.

Jag backar upp en del data till ett online-konto. Men bara ifall nån måhända skulle ta sig in, så krypterar backup-programmet all data. Programmet sparar varje fil och mapp för sig, det slår inte ihop all data till stora arkiv-filer. Så backup-programmet scramblar även namnen på varje fil och mapp så ingen kan läsa namnen på filerna och mapparna. För den vanliga inloggaren har filer och mappar namn som t.ex:

n_yPTqrc01rbPOsZVarixjI
eller
_9Frk2psMCl8S4r0FfT6_eg

Manualen säger att programmet krypterar filerna i AES256, men att "File names and headers" scramblas som "Base64-d to readable strings" (så står det i manualen). Jag antar "File names and headers" hänvisar till fil/mapp-namn och deras typbeskrivning(?) men Base64 är (såvida jag inte är felinformerad) en någorlunda enkel metod att skriva data till/från ASCII-värden?

Innebär det är det är ganska lätt att scrambla fram filers/mappars egentliga namn genom nån metod som översätter tillbaka Base64 värdena?

Exemplen på dom två filnamnen ovan, är live-exempel på filer som scramblats genom den här funktionen. Om det är möjligt att unscrambla fram filernas riktiga namn genom någon metod, så får någon kunnig gärna göra det och visa

I övrigt, är min misstanke relevant?

Tackar för tips

Visa signatur

Jag använder datorn för att göra jobb bättre, inte för att jobba med att göra datorn bättre

Rapportera Redigera

Citera flera Citera

2017-01-21 07:36

Medlem

Registrerad: Jan 2015

●

Njaa, det måste vara så att även filnamnen är krypterade med AES och därefter kodat med base64..

Känn ingen oro, ta en bulle och slappna av.

Rapportera Redigera

Citera flera Citera (2)

2017-01-21 07:51

Medlem

Plats: Mumindalen
Registrerad: Maj 2003

●

@krft: Ja det är ingen fara, käkar inte naglar här Är lite nyfiken i största allmänhet också.
Vad får dig misstänka filnamnen kodats i AES först?
All kryptering jag varit med om innan (vilket inte är så mycket) brukar inte döpa om filnamnen ...

Visa signatur

Jag använder datorn för att göra jobb bättre, inte för att jobba med att göra datorn bättre

Rapportera Redigera

Citera flera Citera

2017-01-21 08:09

Medlem

Plats: Uppsala
Registrerad: Mar 2008

●

Du kan själv testa att decoda namnen på: https://www.base64decode.org/

Visa signatur

Göm hornen ko!

Rapportera Redigera

Citera flera Citera (1)

2017-01-21 08:16

Medlem

Registrerad: Jan 2015

●

Skrivet av TomKe:

@krft: Ja det är ingen fara, käkar inte naglar här Är lite nyfiken i största allmänhet också.
Vad får dig misstänka filnamnen kodats i AES först?
All kryptering jag varit med om innan (vilket inte är så mycket) brukar inte döpa om filnamnen ...

Gå till inlägget

Det finns ingen anledning att koda filnamnen med base64 om dom inte vore krypterade först.

Rapportera Redigera

Citera flera Citera (1)

2017-01-21 08:25

Medlem

Plats: Mumindalen
Registrerad: Maj 2003

●

Skrivet av bobonolla:

Du kan själv testa att decoda namnen på: https://www.base64decode.org/

Gå till inlägget

Hm, ja det gick ju inte alls - oavsett charset.

Skrivet av krft:

Det finns ingen anledning att koda filnamnen med base64 om dom inte vore krypterade först.

Gå till inlägget

Tja kanske Base64 bara används för att dölja filnamnen, medan filkroppen är kodad i AES. Finns dom som inte tänker så långt, även mjukvaruutvecklare.
Om filnamnen ändras via kryptering till AES, då finns det väl ingen anledning att tillämpa ytterligare lager scrambling (Base64) på dom? Eller så är jag helt out of my depth här ...

En ledtråd är: om man tillämpar filnamn-scramblingen (man kan kryptera utan den också), så säger manualen säger varje fils storlek ökar med exakt 32 byte.

Senast redigerat 2017-01-21 08:31

Visa signatur

Jag använder datorn för att göra jobb bättre, inte för att jobba med att göra datorn bättre

Rapportera Redigera

Citera flera Citera

2017-01-21 08:31

Medlem ★

Plats: Stockholm / Vendelsö
Registrerad: Mar 2010

●

Base64 är ju inte en kryptering, Base64 tar bara bort alla mysko tecken o ersätter dessa med tecken som man vet kommer fungera överallt. T.ex. för att skicka på Url:n eller över nätet.

Ordet "filer" blir "ZmlsZXI=" i Base64 - varför så konstiga tecken? Jo, det blir ju så för att jag kommer från UTF8, med 256 skrivbara tecken, som nu skall skrivas med bara 64 tecken. Detta innebär t.ex att det behöver fler tecken för att få till ordet "filer" i Base64 än i UTF8. Man kan se det som ett gammalt ersättnings-krypto om man vill. Men det finns inget nyckel eller hash bakom det, så det är INTE krypterat på riktigt.

En anledning att ha filer/folders i Base64 och INTE krypterat kan vara för att det skall gå snabbt för den rättmätiga ägaren att återställa enstaka filer o mappar, utan att restore funktionen skall dekryptera filnamnen/foldernamnen när man väljer dem.

// LZ

Rapportera Redigera

Citera flera Citera (3)

2017-01-21 08:43

Medlem

Plats: Mumindalen
Registrerad: Maj 2003

●

Skrivet av Tea42BBS:

Base64 är ju inte en kryptering, Base64 tar bara bort alla mysko tecken o ersätter dessa med tecken som man vet kommer fungera överallt. T.ex. för att skicka på Url:n eller över nätet.

Ordet "filer" blir "ZmlsZXI=" i Base64 - varför så konstiga tecken? Jo, det blir ju så för att jag kommer från UTF8, med 256 skrivbara tecken, som nu skall skrivas med bara 64 tecken. Detta innebär t.ex att det behöver fler tecken för att få till ordet "filer" i Base64 än i UTF8. Man kan se det som ett gammalt ersättnings-krypto om man vill. Men det finns inget nyckel eller hash bakom det, så det är INTE krypterat på riktigt.

En anledning att ha filer/folders i Base64 och INTE krypterat kan vara för att det skall gå snabbt för den rättmätiga ägaren att återställa enstaka filer o mappar, utan att restore funktionen skall dekryptera filnamnen/foldernamnen när man väljer dem.

Gå till inlägget

Så verkar det funka här för mig. Enda sättet för mig (som inte vet bättre) att återställa från backup, är att läsa av filstrukturen på servern genom backup-programmet. Gör man det, och har angivit rätt krypteringslösenord, så visar programmet en lista av dom ursprungliga fil/mapp-namnen, som man kan återställa (tankas hem och avkrypteras i ett svep).
Det är datamängder på ett antal gigabyte och flera hundra filer som visas i listan, finns inte en chans att programmet hunnit avkryptera alla dessa på så kort tid, och medan dom ligger på fjärr-server dessutom. Varför skulle dom avkrypteras där liksom. Det är det som får mig tro att namnen är Base64-scramblad medan filkroppen är AES, och anledningen att man måste ange krypteringslösenordet i programmet är bara för OM man skulle vilja trycka på 'Restore'.

Men .. jag kan ändå inte avkoda något av dessa filnamn i någon Base64>Plaintext konverterare jag hittat hittills. Resultatet blir bara mumbo-jumbo. Det är det jag är lite nyfiken på.

Senast redigerat 2017-01-21 09:02

Visa signatur

Jag använder datorn för att göra jobb bättre, inte för att jobba med att göra datorn bättre

Rapportera Redigera

Citera flera Citera

2017-01-21 08:54

Medlem

Registrerad: Jan 2015

●

@TomKe "Eller så är jag helt out of my depth här ..." - Ja det är du

Rapportera Redigera

Citera flera Citera

2017-01-21 09:07

Hedersmedlem ★

Plats: Uppsala
Registrerad: Jul 2001

●

Enligt manualen så verkar det finnas en inställning för detta:

Citat:

Encrypt File Name (un-checked by default)
If checked then Encrypt file names (inside the sync folder) before uploading them to this folder.
AES with 256-bit key is used for encryption.
Encrypted file names are Base64-d to readable strings.

Så om den är aktiverad så verkar den först kryptera filnamnen, sedan köra Base64 för att få bort oläsbara bytes från kryptotexten.

Ang. kryptering och att det inte skulle hinna dekryptera allt när den visar, vad får dig att tro att den inte helt enkelt avkrypterar alla filnamn direkt när man öppnar, och att det bara är själva filinnehållet som inte avkrypteras förrän när man tar restore? Att avkryptera några tusen filnamn tar ju i princip ingen tid alls.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
Mobil: Moto G200

Rapportera Redigera

Citera flera Citera (1)

2017-01-21 09:17

Medlem

Plats: Mumindalen
Registrerad: Maj 2003

●

Skrivet av Thomas:

Enligt manualen så verkar det finnas en inställning för detta:

Så om den är aktiverad så verkar den först kryptera filnamnen, sedan köra Base64 för att få bort oläsbara bytes från kryptotexten.

Ang. kryptering och att det inte skulle hinna dekryptera allt när den visar, vad får dig att tro att den inte helt enkelt avkrypterar alla filnamn direkt när man öppnar, och att det bara är själva filinnehållet som inte avkrypteras förrän när man tar restore? Att avkryptera några tusen filnamn tar ju i princip ingen tid alls.

Gå till inlägget

Se där, du hittade t.o.m. manualen Japp, finns två checkboxar: 'Kryptera filkropp' och 'Kryptera filnamn'. Båda är oberoende av varandra.
Ang hastighet på avkryptering, så antog jag programmet inte kunde avkryptera några få GB på fjärrserver på <10 sek, för att det tar ju ett tag att kryptera filer - överlag. Är ju en del tal som processorn ska tugga igenom, särskilt om det är 2-3 GB. Kanske avkryptering går fort(?)

Hängde dock inte helt med på ditt 'först kryptera filnamnen..'. Vad är "Kryptotexten" för något? Menade du filen/mappens namn efter AES-kryptering? Att Base64 tar bort dom tecken från filnamnet som inte ingår i Base64 alfabetet, efter AES-processning? Kanske så det blir mer webb-vänliga adresseringar till filer o mappar?
Skulle i så fall förklara varför varianten Base64-d används. Läste just att -D varianten ignorerar dom tecken som inte kan göras om till Base64.

Senast redigerat 2017-01-21 09:28

Visa signatur

Jag använder datorn för att göra jobb bättre, inte för att jobba med att göra datorn bättre

Rapportera Redigera

Citera flera Citera

2017-01-21 11:59

Medlem ★

Registrerad: Aug 2016

●

Base64 tar inte bort några tecken alls - de omvandlar bara tecken med 256 val i omfång till ett annat alfabet med 64 tecken val i omfång med skrivbara tecken men med kostnaden att det blir fler tecken istället (strängen växer med 25% i storlek/antal tecken)

Nu har de förmodligen tagit filnamnet och därefter AES-krypterat filnamnet - vilket ger en binärsekvens i x antal byte och därefter base64-koda det för att vara skrivbart som ett filnamn i ett filsystem. Detta gör också att du kan få problem om du har väldigt långa filnamn eftersom filnamnen växer med minst 25% i längd + kanske lite padding och annat inlagt både i AES-kodningen och för base64-kodningen - Denna kryptering/kodning görs med största sannolikhet i din klientprogram i din dator innan det skickas över till filhotellet. De flesta datorer/OS brukar ha en maximal filnamnslängd av 255 tecken.

Om de har gjort rätt så skall du få en mer eller mindre konstig binär-sekvens när du avkodar den scramblade och krypterade filnamnet med (rätt version av) base64 - då den binära sekvensen sedan går vidare in i AES-dekodningen (med rätt nyckel förstås) och i slutändan levererar den korrekta filnamnet.

Att ta bort några tecken eller bara enstaka bitar i den processen är inge bra och kommer att haverera filnamnet fullständigt vid avkodning igen....

Observera att det finns flera sorters 'base64' och förmodligen används varianten för "URL and filename" då standard base64 (traditionellt skickas i email) har '/' som index-tecken i 64-kodningen och denna är förbjuden i filnamn inom unix/linux och även windows.

Därför finns det en "URL and filename safe" version av base64 enligt RFC 4648 §5 där index-tecken 62 och 63 är ersatt från '+' och '/' till '-' och '_' för att teckensekvensen garanterat skall kunna skrivas som filnamn i en filsystem. (det finns ytterligare några varianter av base64 till för XML mfl.)

Med andra ord hittar man '+' och '/' i en base64-sekvens så är den felkodad för att kunna skrivas ned som filnamn i ett filsystem men går utmärkt att skicka i tex email.

---

Att koda/avkoda AES snabbt är ingen problem idag - en modern 64-bits Intel och AMD-propp har hårdvara i sig som gör det upp till flera GB/s och fillagringstjänster med krypteringsmöjligheter så görs krypteringen i användarens dator och inte centralt hos filhotellet.

Dels så minska det kravet på HW i filhotellets maskinpark när det gäller att kalkylera AES - och av rena säkerhetsskäl vill man att datat skall vara krypterat _innan_ det lämnar användarens dator så att inget förståeligt sniffas på vägen även om NSA har skjutit in sina CA-certifikat hos de stora ISP:nas infrastruktur (vare sig de vill eller inte ungefär) och tappar data.

---

Att man snabbt kan lista filerna avkodade i din klientprogram är inge konstigt. När man gör 'dir' så skickas bara det krypterade namnen på filerna och meta-datat (datum, rättigheter etc.) till din klient lokalt på datorn och först där avkrypteras med den nyckel du har i klienten - det handlar bara om några 10-100 kB även för en ganska stor listning. när du börja tanka tillbaka filer från filhotellet så görs avkodningen lokalt i din klient i din dator och då är det överföringshastigheten från filhotellet som begränsar - inte din dators AES-avkodningskapacitet.

Senast redigerat 2017-01-21 13:00

Rapportera Redigera

Citera flera Citera (3)

2017-01-21 22:25

Medlem

Plats: Mumindalen
Registrerad: Maj 2003

●

@xxargs: Det du skriver låter lovande. Kan också förklara varför jag inte kan avkoda filnamnen genom vanliga Base64>plaintext funktioner. Så namnet krypteras också, något jag verkar vara ovan vid, och Base64 används för att göra namnen mer server-vänliga. Står att den Base64 som används är baserad på RFC 2045, "primarily used to encode binary attachments in MIME e-mail but is widely used in many other applications as well".

Att AES var så pass snäll mot hårdvaran (o vice versa) visste jag inte. Visste iofs att PGP modellen tar 5-6 gånger så lång tid att räkna fram, men så använder ju dom 2048, och inte 256 bit eller mindre, som AES gör.

Att Base64-d 'utelämnar' vissa tecken fick jag från ett par sidor som hävdar att varianten -D gör just detta. "-d places base64 into decode mode. It will read from standard input or the supplied file name, ignore all characters that are not part of the base64 alphabet, decode the ones that are, and output the decoded data on standard output." Men då är förstås frågan, om tecken utelämnas, hur faen kan backup-programmet i så fall återskapa 100% rätt filnamn i efterhand. Så det är nåt som inte stämmer med min förståelse där.

NSA och liknande bryr jag mig inte mycket i. Är knappast nån fiende till nån stat
Snowden-dokumenten antydde att dom hade hade jobbat med AES i ca 5 år och hade fortfarande grymma problem med att låsa upp AES-kodning snabbare än deras egna bruteforce-tid, som Snowden sa var ungefär 1 biljon gissningar i sekunden, då. Allt detta för 3½ år sen dock. Om man väljer tro på att det är det bästa motmedlet som fanns då, så kan man nog vara lugn så länge filerna kodas på ens egna dator innan överföring, och att man har långt o bra lösenord.

Men då får jag välja att tro att AES-kodningen är gjord först, och Base64 efteråt. Ska skriva till tillverkaren av programmet och få det bekräftat med, för säkerhets skull. Får tacka för alla tålmodiga och hjälpsamma tips och beskrivningar här

Senast redigerat 2017-01-21 22:31

Visa signatur

Jag använder datorn för att göra jobb bättre, inte för att jobba med att göra datorn bättre

Rapportera Redigera

Citera flera Citera

2017-01-21 22:55

Medlem

Plats: Söder
Registrerad: Jun 2008

●

Skrivet av TomKe:

Att Base64-d 'utelämnar' vissa tecken fick jag från ett par sidor som hävdar att varianten -D gör just detta. "-d places base64 into decode mode. It will read from standard input or the supplied file name, ignore all characters that are not part of the base64 alphabet, decode the ones that are, and output the decoded data on standard output." Men då är förstås frågan, om tecken utelämnas, hur faen kan backup-programmet i så fall återskapa 100% rätt filnamn i efterhand. Så det är nåt som inte stämmer med min förståelse där.

Gå till inlägget

Base64 -d innebär att du anropar programmet base64 och avkodar en textrad som redan är kodad i base64. Att den hoppar över tecken den inte känner igen som en del av base64 är inte så underligt då man inte skulle kunna avkoda andra tecken ändå. När du ska koda det krypterade filnamnet så använder man inte -d parametern och då tar man med samtliga tecken.

Rapportera Redigera

Citera flera Citera

2017-01-22 05:56

Medlem ★

Registrerad: Aug 2016

●

"base64 -d filnamn" dekrypterar base64-kodade strängen och det blir som filen innan base64-omkodningen - dvs. är det ursprungligen binärfil så får man tillbaka binärfilen där varje byte kan ha ett värde mellan 0-255.

Om man går till trådstartarens fundering med filnamnen så är proceduren troligen följande att klientprogrammet för webbhotellet hämtar den kodade filnamnet

n_yPTqrc01rbPOsZVarixjI ('_' ersätts med '/' för att kunna köras i standard base64 i tex. kommandopropten på en linux)

Kör bas64 baklänges med -d flaggan för att få den ursprungliga krypterade filnamnet som med största sannolikhet är i binär form

   n      /      y      P      T      q      r      c        0      1      r     b        P       O      s      Z      V     a      r      i       x      j     I
   27    3F     32      0F     13     2A     2B     1C      34     35      2B    1B       0F      0E    2C     19      15    1A     2B     22      31     23    08
100111|111111|110010|001111| 010011|101010|101011|011100| 110100|110101|101011|011011| 001111|001110|101100|011001| 010101|011010|101011|100010| 110001|100011|001000 

10011111|11111100|10001111|  01001110|10101010|11011100|  11010011|01011010|11011011|  00111100|11101011|00011001|  01010101|10101010|11100010|  11000110|00110010|00 
  9F,      FC,       8F,         4E,     AA,      DC,       D3,      5A,      DB,         3C,      EB,      19,        55,      AA,      E2,       C6,      32,    0

dvs det som kommer ur avkodningen är en binär sekvens på 18 byte som i hexadecimal notering lyder:

9FFC8F4EAADCD35ADB3CEB1955AAE2C6320

binärt

100111111111110010001111010011101010101011011100110100110101101011011011001111001110101100011001010101011010101011100010110001100011001000

Denna sträng körs därefter in i AES i dekrypteringsläge (med rätt nycklar och allt) och det som kommer ut efter dekryptering är filnamnet i klarspråk och visas för användaren i klientprogrammet.

Åtminstone så borde det fungera på det sättet

Det är AES som står för krypteringen - inte base64 - base64 är bara en 'kanalkodare' som ser till att binära utdatat vid kodningen hamnar med bytena med värde mellan 32 och 127 för att vara garanterat skrivbara som filnamn på ett filsystem - ja på bekostnaden att den växer 25% i namn-storlek.
.

Eftersom det är bara filnamn som förs över när man listar filer och inte hela filen när man gör 'dir' så är datamängderna bara inom kb-nivå även för en ganska stor antal filer och avkodingen av dessa går blixtsnabbt.

Idag med hårdvarekrypterare i moderna 64-bits processor och grafikkort så är inte krypteringen någon bekymmer när det gäller hastig - överföring via SATA och över nätverk begränsar innan det börja det börja bli bekymmer med krypteringhastighet.

När det gäller (köpe) NAS-däremot, speciellt de med ARM-plattform så kan kryptering vara tungt om det görs inne i NAS:en (tex dataöverföring via SSH) då det emuleras mjukvarumässigt i många tillämpningar. Även om somliga ARM-varianter har HW-stöd för AES så finns ofta inte stödet för detta i OS som kör NAS:en.

Senast redigerat 2017-01-22 06:08

Rapportera Redigera

Citera flera Citera