[ASP] string encryptie & compressie

[avon]

Voor mijn stage ben ik lekker aan het werk met ASP, nu heb ik een
simpele encryptie routine bedacht,

ASP.NET Visual Basic:

Function encrypt(strcode,key)
strcodelengte = len(strcode) 

On Error Resume Next
FOR strloop = 1 to strcodelengte
     strcodechar = Mid(strcode, strloop,1)
       On Error Resume Next
       strint = (Asc(strcodechar)+key)*strcodelengte
        strint = strint + (strloop*key)

            FOR strloop2 = len(strint) to 5 
                        strint = "0" & strint
            NEXT

                     encryptstr = encryptstr& "" & strint
           NEXT
    encrypt = encryptstr
End Function

Dit levert vervolgens een string op, bv

012961014322015515016820018237019526020967022312

("tweakers" met key 1337) Nu is het al wel zo dat je echt de KEY moet hebben
om de string er correct uit te krijgen alleen is deze key natuurlijk vrij kort.

Kortom een behoorlijke overhead, dit kan natuurlijk veel beter alleen weet
ik niet exact hoe.

Nu kan ik met MOD wel een soort checksum berekenen maar hoe zou ik
dit het best kunnen gebruiken om een sterkere encryptie te krijgen met
minder overhead.

[ Voor 29% gewijzigd door avon op 06-05-2003 11:11 ]

[dominic]

Even een langs de lijn opmerking: Ik kan je ten zeerste aanraden tabs in je code te gebruiken voor de codeblokken, dit verbetert de leesbaarheid..

[Verwijderd]

Waarom wil je persé zelf het wiel opnieuw uitvinden? Ook al lijkt dit hartstikke handig en veilig, het is het absoluut niet!!
Ik raad je ten sterkste aan om ff naar een algoritme als Ryndael te kijken. Dat is heel makkelijk te implementeren en is bewezen veilig. Zeker bij encryptie mag je eigenlijk geen risico's lopen.

Hier zijn kant en klare voorbeeld implementaties te vinden in allerlei talen (ook VB). Wel zo veilig

[avon]

Verwijderd schreef op 06 May 2003 @ 11:11:
Waarom wil je persé zelf het wiel opnieuw uitvinden? Ook al lijkt dit hartstikke handig en veilig, het is het absoluut niet!!
Ik raad je ten sterkste aan om ff naar een algoritme als Ryndael te kijken. Dat is heel makkelijk te implementeren en is bewezen veilig. Zeker bij encryptie mag je eigenlijk geen risico's lopen.

Hier zijn kant en klare voorbeeld implementaties te vinden in allerlei talen (ook VB). Wel zo veilig

Het hoeft geen super encryptie te zijn, wat ik intressanter vind als er totaal
geen overhead is maar zelfs een beetje compressie op kleine strings (tot 30
tekens)

[ Voor 4% gewijzigd door avon op 06-05-2003 11:12 ]

[Verwijderd]

Volgens mij is een kenmerk van encryptie is juist dat je het daarna niet makkelijk meer kan comprimeren... maar goed, dan zou je na je simpele encriptie methode de string kunnen zip'pen. Maar hoe je het ook zal doen, je string zal nooit of te nimmer korter worden dan het origneel.

Tenzij je gaat hashen (MD5), maar dan kan je het origineel niet meer terug krijgen...

[avon]

je string zal nooit of te nimmer korter worden dan het origneel.

Nooit ?!

De AES encryptie heb ik even gecheckt, daarbij is de overhead idd minimaal.

Block Size=128, Key size=128
Plain
000102030405060708090A0B0C0D0E0F
Encrypt
5352E43763EEC1A8502433D6D520B1F0
Decrypt
000102030405060708090A0B0C0D0E0F

Block Size=128, Key size=192
Plain
000102030405060708090A0B0C0D0E0F
Encrypt
8046725C5FE415DC926CB08F54B1681A
Decrypt
000102030405060708090A0B0C0D0E0F

Block Size=128, Key size=256
Plain
000102030405060708090A0B0C0D0E0F
Encrypt
F2258E225D794572393A6484CFCED7CF
Decrypt
000102030405060708090A0B0C0D0E0F

[ Voor 75% gewijzigd door avon op 06-05-2003 11:20 ]

[Reptile209]

Verwijderd schreef op 06 May 2003 @ 11:14:
Maar hoe je het ook zal doen, je string zal nooit of te nimmer korter worden dan het origneel.

Tenzij je bijvoorbeeld een hele simpele encryptie over een string haalt, die eerst gecomprimeerd is. Je kan bijvoorbeeld al uitgaan van het feit dat ascii-tekens 7 bits zijn maar 8 bit worden opgeslagen -> als je je data zo schikt dat de voorloop 0 (hoogste bit) wegvalt, zodat je een bit van het volgende teken mee kan nemen in die byte (ja, het heeft een naam, weet ik ff niet ). Dan kom je al op max. 12,5% compressie en je zou het een vorm van encryptie kunnen noemen (iig niet direct leesbaar meer).
Maar voor de meeste encrypties kom je inderdaad op een overhead uit.

[lordsnow]

Tekst zou je eerst kunnen comprimeren volgens het BWT principe. BWT is lekker standaard en vrij makkelijk te implementeren.

Je kan een checksum (CRC32?) van het gebruikte password aan je gekodeerde data plakken.

En er zijn zat standaard encryptie methodes, bv Twofish, Blowfish, ...

[avon]

Reptile209 schreef op 06 May 2003 @ 11:25:
[...]

Tenzij je bijvoorbeeld een hele simpele encryptie over een string haalt, die eerst gecomprimeerd is. Je kan bijvoorbeeld al uitgaan van het feit dat ascii-tekens 7 bits zijn maar 8 bit worden opgeslagen -> als je je data zo schikt dat de voorloop 0 (hoogste bit) wegvalt, zodat je een bit van het volgende teken mee kan nemen in die byte (ja, het heeft een naam, weet ik ff niet ). Dan kom je al op max. 12,5% compressie en je zou het een vorm van encryptie kunnen noemen (iig niet direct leesbaar meer).
Maar voor de meeste encrypties kom je inderdaad op een overhead uit.

Je zou natuurlijk string posititie daarbij ook kunnen gebruiken als deel factor
in het geval de int waarde van de letter bijvoorbeeld even is. Aan zoiets zat
ik zelf te denken.

[Scharnout]

AvOn schreef op 06 May 2003 @ 11:30:
[...]


Je zou natuurlijk string posititie daarbij ook kunnen gebruiken als deel factor
in het geval de int waarde van de letter bijvoorbeeld even is. Aan zoiets zat
ik zelf te denken.

Delen? Hoe werk jij dan je afrondingen af

[avon]

Scharnout schreef op 06 May 2003 @ 11:41:
[...]


Delen? Hoe werk jij dan je afrondingen af

Dat is ook nog even mijn vraag, daarom ben ik benieuwd of mensen goede
ideeen hebben om dit simpel maar doeltreffend aan te pakken.

[ Voor 41% gewijzigd door avon op 06-05-2003 12:00 ]

[lordsnow]

zie ook: Encryption with ASP

[avon]

lordsnow schreef op 06 mei 2003 @ 11:59:
zie ook: Encryption with ASP

Lijkt sterk op hetgeen ik al heb, vraag me af hoelang iemand er over zou doen
om die string te decryten eigenlijk, zonder dat hij de key en de encryptie methode
weet.

[Reptile209]

Hangt er vanaf of die persoon "test strings" kan versturen (maw: de inhoud is al bekend en kan hij/zij dus proberen terug te rekenen), hoe lang de key is en of die ergens verstuurd/opgeslagen wordt, hoe graag de persoon de inhoud wil kraken (dus hoeveel moeite hij/zij wil doen), etc. Is dus moeilijk te zeggen.
Met de key-lengte die in de link van lordsnow wordt gebruikt, lijkt het dat je wel ff zoet bent, hoewel het weer makkelijk is dat de key steeds gelijk blijft en dat er alleen een xor op losgelaten wordt. Beetje brute-force rekenen met voorbeeld-data en je komt volgens mij een heel eind.

[avon]

Verwijderd schreef op 06 May 2003 @ 11:14:

Tenzij je gaat hashen (MD5), maar dan kan je het origineel niet meer terug krijgen...

Wat heeft MD5 voor nut als je het orgineel niet meer kan terug krijgen?

[jvdmeer]

Af en toe heb je geen origineel nodig. Bijv. bij wachtwoord-controle.
Neem als voorbeeld NT-authenticatie: Die werkt ongeveer zo:

code:

De server kent een hash van het gebruikerswachtwoord.

de gebruiker typt op de client het wachtwoord in. 
De server geeft als opdracht, doe enkele berekeningen
met de hash van het wachtwoord. En stuur het resul-
taat naar de server.

De server voert de zelfde bewerking uit met zijn hash.
Als de resultaten hetzelfde zijn, dan is het wachtwoord
(waarschijnlijk) ook hetzelfde.

Op deze manier kan een wachtwoord worden gecontroleerd, zonder dat het wachtwoord lokaal wordt opgeslagen of over de lijn gaat.

[ Voor 5% gewijzigd door jvdmeer op 06-05-2003 16:43 . Reden: afbreken voorbeeldzinnen ]

[avon]

dat was dus wat ik me vaag kon herinneren over dat suplement getal dan...

Bedankt voor de reacties, knutsel weer vrolijk verder
(het wordt waarschijnlijk een AES integratie)