Wat zijn gebruikelijke coderingsstrategieën voor base64?

Dit is afkomstig uit het Wiki-item voor Base64:

Als je echt bedoeld om Base64-codering te saboteren om codering te bieden, zou dit kunnen worden gedaan op het hierboven aangegeven indexniveau. U zou een geheime sleutel nodig hebben, een sleutelafleidingsfunctie die is aangepast om een zaad met hoge entropie te creëren dat vervolgens een pseudo-willekeurige nummergenerator startte. De output van de generator (6 bit) zou dan XORed worden met de Index om de codering voor elk karakter te veranderen. En deze techniek kan worden omgekeerd om het gecodeerde bericht te ontcijferen.

Je ziet dat het allemaal is een beetje lastig. Traditioneel “creëerde u de versleutelde tekst en codeerde deze vervolgens. Behalve het bijsnijden van een typische 8-bits willekeurige reeks tot 6 bits, is de werkbelasting echter identiek aan de traditionele stroomcijfer . Eigenlijk heb je 33% extra berekeningen nodig, maar dat is hier noch daar.

Je zou de eerste kunnen zijn die aan deze Base64-variant heeft gedacht, aangezien niemand zich bewust lijkt te zijn van soortgelijk gedrag. Dit zou echter moeten werken.

Reacties

• Bedankt voor deze interessante suggestie! Eigenlijk had ik simpele dingen in gedachten, zoals het veranderen van de 6bit lettertabelassociatie. Of een sleutel introduceren en een bitsgewijze xor-bewerking uitvoeren op elke letter die door de sleutel loopt, of iets dergelijks.
• @Kagaratsch Nou, ik denk dat we ‘ over soortgelijke lijnen. Om je ‘ ll heb PRNG-functionaliteit nodig te hebben en om een sleutel aan een PRNG te koppelen, heb je ‘ een soort van sleutelafleidingsfunctie nodig, anders daar ‘ Er is een discrepantie tussen het sleutelformaat en het formaat / de status die vereist is om de PRNG te bedienen. Als je simpelweg permuteert zonder een sleutel, of je key character cycling gebruikt, is het schema ‘ niet erg veilig en dit is tenslotte crypto.SE 🙂
• @PaulUszak Die technische naam is eigenlijk vrij duidelijk zodra je hem kent … hij ‘ heet gewoon ” XOR-codering “. 😉 Merk echter op dat frequentieanalyse het triviaal zal breken. Hetzelfde geldt voor bekende aanvallen in platte tekst. Oh, en om de technische naamgeving compleet te maken: als je een prng invoert, verandert zon ” XOR-cijfer ” in een ” stroomcijfer “. Maar dat wist je waarschijnlijk al, ‘ jij niet?
• @PaulUszak Weet niet zeker waarom je ” nee zegt “. U kunt er ook zeker van zijn dat ik weet wat ” cycling ” betekent. Een XOR-cijfer doorloopt dezelfde sleutel keer op keer en in dezelfde volgorde, net zoals je beschrijft. Controleer het ” voorbeeld ” van die wikilink; het komt 100% overeen met uw beschrijvingen … a bitwise xor operation on each letter cycling through the key en Cycling round through the key means that the plain text will be XORed with the same sequence over and over, and in the same order. – dat ‘ heet ” XOR-codering “. Geen fout of taalkloof daar.
• Elke manier waarop je base64 op deze manier aanpast, kan worden verwerkt in (a) het definiëren van een cijfer op byte-reeksen en vervolgens (b) het toepassen van standaard base64 op zijn uitvoer, waarbij de cijfertekstbyte-strings worden toegewezen aan platte tekst. Er ‘ heeft geen zin om (a) en (b) samen te voegen – het voegt geen beveiliging toe en maakt de beschrijving van zowel het onderliggende cijfer als de impliciete standaard base64 onnodig ingewikkeld.

Dit slaat nergens op. Er is geen geheime sleutel in base64: base64-codering en decodering zijn openbare functies die iedereen kan evalueren.

De enige manier waarop base64 verband houdt met cryptografie, is dat het handig is om cijfertekst van een cryptosysteem te coderen, namelijk uniform verdeeld in 8-bit strings, in een beperkte set van US-ASCII die niet zal worden munged of afgewezen in contexten die beperkt zijn tot platte tekst, zoals XML.

Opmerkingen

• +1 (… en base64 produceert kortere uitvoer dan hex-codering, daarom is het ontwikkeld en wordt het vaak gebruikt in applicaties.)
• Het is perfect sense 🙂 De vraag werd gesteld als een hypothetische vraag en het OP zoekt naar implementatiemogelijkheden. Er ‘ is geen natuurwet die vereist dat alle versleuteling super efficiënt moet zijn. Het hoeft alleen maar te versleutelen / ontsleutelen. Weet je dat mensen nog steeds stoommachines bouwen en er erg trots op zijn ..?
• @PaulUszak Het heeft geen ‘ zin als base64, een openbare transformatie tussen twee equivalente weergaven van gegevens, is een ander type object dan een coderingsschema dat geheimen bevat die niet bekend zijn bij een tegenstander. Elke manier waarop u de interface en de interne onderdelen van base64 wijzigt om er een soort sleutel en cijfer in te plaatsen, kan worden verwerkt in de standaard base64-representatietransformatie en een onderliggend cijfer waarvan de beveiliging niet relevant is voor het base64-gedeelte. Als je een door stoom aangedreven Enigma-machine zou maken, zou je dan zeggen dat je het concept van stoomkracht hebt gewijzigd in een versleutelingsschema?
• @SqueamishOssifrage Ja.

De gouden regel van cryptografie zou moeten zijn: “Het is niet omdat jij de tekst niet kan lezen dat deze gecodeerd is”. Base64 is niet bedoeld om te worden gebruikt om cijfertekst te maken en het mag ook niet voor dat doel worden gebruikt.

Versleutelingsmethoden zijn altijd afhankelijk van een geheim of artefacten die ervoor zorgen dat alleen de actoren van de communicatie de cijfertekst. Als dat niet het geval is, zoals bij Base64, dan is het geen codering.

Base64 is bedoeld om binair als tekst te coderen met verschillende voordelen ten opzichte van andere coderingsschemas. Privacy behoort niet tot deze voordelen.

Ja, er is interesse in het versleutelen van upstream base64: het is de economie in iteraties. Wanneer we gegevens versleutelen en vervolgens coderen, moeten we ten minste twee lussen maken: één over de codering van de gegevens en de andere over de codering van de gegenereerde gegevens. Door stroomopwaarts te coderen, kunnen we terugbrengen tot een lus en daarom aanzienlijke prestaties behalen.

@ e-sushi: Inderdaad, er zijn niet veel voorbeelden behalve deze die slechts één lus gebruikt: php_base64encrypted

Er zijn waarschijnlijk andere manieren om het beter te doen, maar het bewijst dat het mogelijk is …

Bewerken: sorry, ik ben niet erg bekend met deze site.

Opmerkingen

• Kunt u een voorbeeld geven (link naar paper of zoiets) van zon `interesse in het versleutelen van upstream base64`? Ik heb geprobeerd meer informatie te vinden met behulp van mijn favoriete zoekmachine , maar op de een of andere manier faalde ik, een wijzer zou daarom veel zijn eciated.
• Base64-codering is een proces dat kan worden gestreamd (d.w.z. het maakt het mogelijk dat een gegevensstroom incrementeel wordt gecodeerd terwijl deze ‘ s wordt gegenereerd, zonder eerst alles te hoeven lezen). Het zou dus perfect mogelijk zijn om een conventioneel versleutelingsschema de uitvoer naar een incrementele base64-encoder te laten sturen, zonder ” ten minste twee lussen te maken ” over de gegevens. De enige reden waarom dit niet ‘ t vaker wordt gedaan, is waarschijnlijk het feit dat voor datastromen die lang genoeg zijn om dit nuttig te maken, het ‘ is meestal een stuk efficiënter om base64-codering volledig over te slaan en ze gewoon te verzenden en / of op te slaan als onbewerkte binaire gegevens.