Noha az base64 kódolásnak nincs szándéka a titkosításra, még nincs messze a gondolat, hogy a kódolási folyamatot valamilyen módon enyhíteni lehetne a létrehozáshoz egy titkosítást. Bizonyára nem én gondolok először ilyen titkosítási kísérletre, amely base64 kódolást használ. Ezért azt szeretném kérdezni, hogy milyen típusú base64 titkosítási stratégiák ismertek?
Megjegyzések
- Mint egy 6 bites adatfolyam-titkosítás?
- a titkosítás általában az adatoknak az Base64-en keresztüli futtatása előtt történik.
- Láttam már korábban használt base64-es titkosítási sémákat, de mindegyik triviálisan meghibásodott. Ennek a kérdésnek van értelme, mert az emberek esetleg keresnek ilyen algoritmusokat. A józan ész azonban valószínűleg azt jelenti, hogy jelezzük, hogy az base64-et nem titkosításként értjük, és a kódolás és a titkosítás összetévesztésének az eredménye. Ne feledje, hogy sokan feltételezzük, hogy ennek a kérdésnek az az előfeltevése téves: hogy egy kódolási séma használható a titkosításhoz. Ez visszhangot eredményezhet, még akkor is, ha a kérdés legalább érdekes sok kezdő kriptográfus számára.
- Talán érintőlegesen releváns: crypto.stackexchange.com/questions/62425/… , crypto.stackexchange.com/questions/5862/… és crypto.stackexchange. com / questions / 45215 / …
Válasz
Ez a Base64 Wiki bejegyzéséből származik:
Ha valóban a manipulálás hoz a Base64 kódolással a titkosítás biztosítása érdekében a fent kiemelt Index szinten lehet megtenni. Szüksége lesz egy titkos kulcsra, egy kulcs levezetési függvényére , amely egy nagy entrópia-mag létrehozásához igazodik, majd egy ál véletlenszám-generátorból indult. A generátor (6 bites) kimenete ekkor XOR-ra kerül az Index segítségével, hogy megváltoztassa az összes karakter kódolását. Ez a technika megfordítható a titkosított üzenet megfejtése érdekében.
Látja, hogy mindez kicsit zavar. Hagyományosan létre kell hozni a titkosító szöveget, majd kódolni. A tipikus 8 bites véletlenszerű szekvencia 6 bitre vágásán kívül a munkaterhelés megegyezik a hagyományos adatfolyam titkosítással . Valójában 33% extra számításokra van szükséged, de ez sem itt, sem ott.
Lehet, hogy elsőként gondoltál erre a Base64 variánsra, mivel úgy tűnik, senki sem tudott hasonló viselkedésről. Ennek mégis működnie kell.
Megjegyzések
- Köszönöm ezt az érdekes javaslatot! Tulajdonképpen az egyszerű dolgokra gondoltam, például a 6 bites levéltáblázat társítására. Vagy be kell vezetni egy kulcsot, és bitenként xor műveletet kell végezni minden betűnél, amellyel végiggörgethetjük a kulcsot, vagy hasonlót.
- @Kagaratsch Nos, szerintem ‘ gondolkodunk hasonlóakon vonalak. Az áteresztéshez ‘ PRNG funkcióra van szükséged, és egy kulcsot egy PRNG-hez kell kapcsolnod, ha ‘ ll valamilyen kulcsszármazási funkcióra van szükséged, különben ott ‘ A kulcsformátum és a PRNG működtetéséhez szükséges formátum / állapot közötti eltérés lehet. Ha egyszerűen kulcs nélkül permutál, vagy a kulcsfontosságú karakterét használja, a ‘ séma nem túl biztonságos, és ez végül is a crypto.SE 🙂
- @PaulUszak Ez a technikai név valójában elég nyilvánvaló, amint megismered … ‘ s egyszerűen ” XOR rejtjelezés “. 😉 Mégis, vegye figyelembe, hogy a frekvenciaelemzés triviálisan megtörni fogja. Ugyanez vonatkozik az ismert egyszerű szöveges támadásokra is. Ja, és hogy teljes legyek a technikai elnevezéssel kapcsolatban: amikor bedobsz egy prng-t, egy ilyen ” XOR rejtjel ” egy ” adatfolyam titkosítás “. De valószínűleg ezt már tudta, nem ‘ t?
- @PaulUszak Nem biztos benne, miért mondja azt, hogy ” nem “. Biztos lehet benne, hogy tudom, mit jelent a ” kerékpározás “. Egy XOR rejtjel ugyanabban a kulcsban újra és újra, ugyanabban a sorrendben jár, mint ahogy Ön leírja. Ellenőrizze a wiki-link ” példáját ” ; 100% -ban megegyezik a leírásokkal… id = “483708b171”>
XOR rejtjel “. Nincs tévedés vagy nyelvi szakadék.
Válasz
Ennek nincs értelme. Nincs titkos kulcs az base64-ben: az base64 kódolása és dekódolása olyan nyilvános funkció, amelyet bárki értékelhet.
Az Base64 egyetlen kapcsolata a rejtjelezéssel az, hogy kényelmes valamilyen kriptográfiai rendszerből kódolni a titkosított szöveget, ami 8 bites karakterláncokban egyenletesen elosztva, az USA-ASCII korlátozott készletében, amelyet nem lehet elutasítani vagy elutasítani olyan szövegkörnyezetben, amely egyszerű szövegre, például XML-re korlátozódik.
Megjegyzések
- +1 (… és az base64 rövidebb kimenetet produkál, mint a hexakódolás, ezért fejlesztették ki, és ezért gyakran használják az alkalmazásokban.)
- Tökéletesít értelem 🙂 A kérdést hipotetikusként tették fel, és az OP a megvalósítási lehetőségeket keresi. ‘ nincs olyan természetes törvény, amely előírná, hogy az összes titkosításnak szuper operatív hatékonyságúnak kell lennie. Csak titkosítani / visszafejteni kell. Tudja, hogy az emberek még mindig gőzgépeket építenek, és nagyon büszkék rájuk ..?
- @PaulUszak Ennek nincs értelme ‘, mint base64, nyilvános átalakítás két egyenértékű adatábrázolás között egy olyan típusú objektum különbözik a titkosítási sémától, amely titkokat tartalmaz, amelyeket az ellenfél nem ismer. Bármilyen módon módosíthatja a base64 interfészét és belső területeit, hogy valamilyen kulcsot és titkosítást tegyen bele, belekerülhet a szokásos base64 reprezentációs transzformációba és valamilyen mögöttes titkosításba, amelynek biztonsága lényegtelen az base64 rész számára. Ha gőzüzemű Enigma gépet készítene, azt mondaná, hogy a gőzenergia fogalmát titkosítási sémává módosította?
- @SqueamishOssifrage Igen.
Válasz
A rejtjelezés aranyszabályának a következőnek kell lennie: “Ez azért van titkosítva, mert nem tudja olvasni a szöveget”. Az Base64 nem célja a titkosított szöveg létrehozása, és nem is használható erre a célra.
A titkosítási módszerek mindig egy titokra vagy tárgyakra támaszkodnak, amelyek biztosítják, hogy csak a kommunikáció szereplői fordíthatják meg a rejtjelezett szöveg. Ha nem, mint az Base64 esetében, akkor ez nem titkosítás.
A Base64 célja a bináris szövegként történő kódolás, különféle előnyökkel a többi kódolási sémával szemben. Az adatvédelem nem tartozik ezek közé az előnyök közé.
Válasz
Igen, érdekelt az upstream base64 titkosítása: ez a gazdaság iterációkban. Amikor adatokat titkosítunk, majd kódolunk, akkor legalább két hurkot kell készítenünk: az egyiket az adatok titkosítására, a másikat a keletkezett adatok kódolására. Az upstream titkosításával redukálhatunk hurokká, és ezért jelentős teljesítmény elérése.
@ e-sushi: Valójában nincs sok példa, kivéve ezt, amely csak egy ciklust használ: php_base64encrypted
Valószínűleg vannak más módszerek is a jobb teljesítményre, de ez bizonyítja, hogy lehetséges …
Szerkesztés: sajnálom, nem ismerem nagyon ezt a weboldalt.
Megjegyzések
- Tudna adni egy példát (link papírra vagy valami másra), amely ilyen érdeklődéssel bír az upstream base64 titkosítása iránt? Próbáltam további információkat találni a kedvenc keresőmotorom segítségével , de valahogy kudarcot vallottam. Ezért egy mutató nagyjából helyes lenne le van kötve.
- Az Base64 kódolás streamelhető folyamat (azaz lehetővé teszi az adatfolyam inkrementális kódolását, amikor ‘ generálódik, anélkül, hogy először el kellene olvasnia az összeset). Így tökéletesen lehetséges lenne, ha egy hagyományos titkosítási séma táplálná a kimenetét egy növekményes base64 kódolóba anélkül, hogy ” legalább két hurkot kellene készítenie ” az adatok fölött. Az egyetlen ok, amiért ezt nem szokták ‘ t tenni, valószínűleg az a tény, hogy ahhoz, hogy az adatfolyamok elég hosszúak legyenek ahhoz, hogy ez hasznos legyen, ‘ általában sokkal hatékonyabban hagyja ki teljesen az base64 kódolást, és csak továbbítja és / vagy tárolja őket nyers bináris adatként.