Kryptering: Invalid length for a Base-64 char array

Har du husket også at URL-encode den krypterede streng før at du sender den?

Hvor lang bliver din URL-streng? Browsere og servere har forskelige grænser, men regn med at det kun virker under ca. 2000 tegn.

Et eksempel: mBm4qXVOFl1v/YzjEZg/qw==

Og vil på ingen måde tro jeg nogensinde når over 2K tegn

Det sjove af det hele er at kopiere jeg den streng der ligger krypteret i min URL og smider en manuelt igennem dekryptering med samme nørgle kan den pluselig godt ved dem som den ellers mælder fejl ved....

hmm... tyder på at det er hver gang der fremkommer et "+" i url'en...

Hvilket jo også er logisk nu... efter som den vil betragte det som et " "...

Men med en lille simpel Replace så virker det umiddelbart igen...

Og det er præcis det som første indlæg siger: URL-encode  - du har så måske kun eet tegn, der giver problemer, og kan nøjes med en replace.

erikjacobsen -> 10/04-2005 13:26:42

Jeg ønsker bare ikke at URL-encode først...
Jeg skal bare sende og bruge det RAW... så vidt muligt...

Du skal ikke url-encode først, men sidst, lige inden du lægger værdien i URL-en. En url-encode laver fx "+" om til noget, der forstås som "+" og ikke som blank.

Ja nu mente jeg altså før jeg smed dem på url'en... jeg ved godt hvad Url encode gør... Men jo mere man skal encode jo mere betyder det også for performance, og da jeg skulle have mine Querys krypteret, så kunne jeg ikke se noget grund til at skulle sætte både DES kryptering og URL encoding i spil...

Det bliver jo ikke anderledes end det du gør nu. URL-encode laver kun om på de "giftige" tegn, så man er sikker på alt kommer med over. Næsten alle dine tegn er fine, undtagen "+", og måske andre.... Og mon en url-encode er langsommere end en replace. I hvert fald ville du få dem alle med, nuværende og fremtidige.

Men det jeg ville sige var bare, at din løsning reelt var blevet foreslået tidligere.

Er jeg så uenig i... Efter som det kun har været et + der har bugget mig... og jeg har aldrig set den spytte andre giftige tegn ud...

Og det vil være en Faktor 10+ hvis jeg går over til URL-Encode istedet for...

md_craig> "en faktor 10+" - no way!

Arbejdsgangen er: Rå data -> DES -> URL-encode.

Da DES bruger base64 vil resultatet efter DES være bytes i den nedre halvdel af ASCII-tabellen. Disse vil normalt være fredelige når de indgår i query-strengen på et URL. Men nogle få exceptionelle undtagelser som f.eks. '+' vil give problemer. Ved URL-encoding er det kun de tegn som vil blive oversat til noget i stil med "%2B" (for '+'). Da der næppe vil være mere end et par stykker af dem i din streng, vil resultatet vel maks. blive 0-10 tegn længere.

Hvis du derimod URL-encoder *før* at du DES-kryptere (som du antyder i 10/04-2005 14:22:01) så kan jeg godt forstå din påstand, men denne fremgangsmåde ville også være den helt forkerte på mange forskellige måder!

Lad mig slå fast at du *bør* URL-encode. Lige nu har du kun oplevet problemet i forbindelse med '+', men hvad så når du en dag støder på tilfældene '$', '&', ',', '/', ':', ';', '=', '?' eller '@' for blot at nævne nogle. Ved at bruge URL-encoding så vil du være fremtidssikret:

http://www.blooberry.com/indexdot/html/topics/urlencoding.htm

- Niels

PS: Og så mener jeg i øvrigt at de 30 point burde være mine da det var den manglende URL-encoding som gav problemet!

nielle >>

** Hvis du derimod URL-encoder *før* at du DES-kryptere (som du antyder i 10/04-2005
** 14:22:01) så kan jeg godt forstå din påstand, men denne fremgangsmåde ville også
** være den helt forkerte på mange forskellige måder!

Nej, som jeg tidligere sagde betyd det får jeg kasteden den på min Url og ikke før den røg igennem min DES... Ellers ville jeg jo ikke løse problemet da jeg stadig ville få +'er ud... og når jeg snakker en faktor 10 er det ikke hvor meget det fylder... det er Ydelses messigt... dvs. det tager 10 gange så lang tid at URL-encode...

** Lad mig slå fast at du *bør* URL-encode. Lige nu har du kun oplevet problemet i
** forbindelse med '+', men hvad så når du en dag støder på
** tilfældene '$', '&', ',', '/', ':', ';', '=', '?' eller '@' for blot at nævne
** nogle. Ved at bruge URL-encoding så vil du være fremtidssikret:

Nej, for faktisk er alle de tegn du lige lister op der 100% urelevante her...
Igen af dem giver problemer selv om de evt. var med... så hvorfor skulle jeg gøre mit site 10 gange tungere på det område for at opnå ingen ting???

** PS: Og så mener jeg i øvrigt at de 30 point burde være mine da det var den
** manglende URL-encoding som gav problemet!

Du må da hjertens gerne få de 30 point... hvis du mener det... jeg er sådan set bedøvende... Nok var URL encode en løsning... men nu var det jo en forklaring jeg ledte efter...

Mit egentlige spm var:
** Og så er det lige at jeg ikke helt kan se hvorfor det er sådan... for efter som ** jeg Kryptere den og konvertere de krypterede bytes til Base-64 burde der da
** umiddelbart ikke være problemer med at vende tilbage igen?

Og der mener jeg ikke at et "du URL-Encoder ikke" rækker, for nej det ved jeg da godt jeg ikke gør efter som jeg har valgt ikke at gøre det???...

nielle >>

** md_craig> "en faktor 10+" - no way!

Øhhh og dit belæg for det er så???

250000 Runs, 5 Times:

Query: 2o9AKtgnH4s2Vg1TPobn/ZkiAXkc/F6e==
- Url Encode: 421,875 ms, 406,25 ms, 531,25 ms, 437,5 ms, 437,5 ms
- Replace  : 46,875 ms, 46,875 ms, 62,5 ms, 46,875 ms, 46,875 ms

Query: bzP3OOY/dIR==3qedU2B9mUost5yOF7znxDr+xgbRrQ=
- Url Encode: 609,375 ms, 546,875 ms, 578,125 ms, 671,875 ms, 640,625 ms
- Replace  : 46,875 ms, 46,875 ms, 62,5 ms, 62,5 ms, 78,125 ms

Query: Ou55MC0==/zL1K3CQBE1uF4Py7CWllNqBMu==
- Url Encode: 468,75 ms, 437,5 ms, 453,125 ms, 468,75 ms, 500 ms
- Replace  : 46,875 ms, 46,875 ms, 46,875 ms, 46,875 ms, 93,75 ms

Query: Ou55/=MC0zL1K3/CQBE1uF4P+kc+zclFWEQ
- Url Encode: 406,25 ms, 453,125 ms, 406,25 ms, 484,375 ms, 453,125 ms
- Replace  : 62,5 ms, 78,125 ms, 46,875 ms, 46,875 ms, 46,875 ms

Query: bzDuP/OOYdK/1UfKqrdIIPzHXv=TXPSr4zo97ik5WS4U=
- Url Encode: 515,625 ms, 578,125 ms, 546,875 ms, 609,375 ms, 562,5 ms
- Replace  : 62,5 ms, 46,875 ms, 62,5 ms, 93,75 ms, 62,5 ms

md_craig> Du specificerede ikke hvad det var som du mente "en faktor 10+" på, så jeg gik ud fra at det var længden - at du mente at din URL-encodede streng var 10+ gange længere end hvis du ikke URL-encode den. Og det er den jo bestemt ikke. My bad, jeg indså ikke lige at du mente eksekveringsmæssigt.

Ja, en URL-encode tager længere tid end en Replace - når du altså kun køre den på et enkelt tegn - '+'. En faktor 10 svare vel til at en URLencode implementeres som Replace på mindst 10 forskellige tegn og det er vel egentligt rimeligt nok når man ser hvor mange tegn det er som bør URL-encodes.

At du ikke har oplevet problemer med andre tegn, antager jeg nu mere er et held end en indikation af at det aldrig vil gå galt. Hvorfor skulle det kun være '+' som gik galt? Du forklare jo selv at '+' opfattes som et space ' ' og dette skyldes jo netop at dette tegn har en special-funktion i forbindelse med URLs. Nuvel, men det har '?', '&' og '=' altså også, så hvorfor går netop disse tegn godt mens at '+' fejler?

Hvad sker der f.eks. den dag hvor at du tilfældigvis får noget i stil med:

http://DinServer/DitScript.aspx?DinKrypteredeStreng=qwerty&asdfg=zxcvbn

- blot fordi at din data-streng DES-kryptere til "qwerty&asdfg=zxcvbn"?

Behold bare de 30 points, det betyder såmen ikke så meget. :^)

Tonen skyldes bare at jeg blev bare en smule fortørnet over at du på den ene side erkendte at det var URL-encodningen som var problemet (10/04-2005 10:20:05), men på den anden side ikke krediterede det: Ja, jeg mener faktisk at jeg forklarede hvad dit problem var. :^|

- Niels

** At du ikke har oplevet problemer med andre tegn, antager jeg nu mere er et held
** end en indikation af at det aldrig vil gå galt. Hvorfor skulle det kun være '+'
** som gik galt? Du forklare jo selv at '+' opfattes som et space ' ' og dette
** skyldes jo netop at dette tegn har en special-funktion i forbindelse med URLs.
** Nuvel, men det har '?', '&' og '=' altså også, så hvorfor går netop disse tegn
** godt mens at '+' fejler?
**
** Hvad sker der f.eks. den dag hvor at du tilfældigvis får noget i stil med:
** http://DinServer/DitScript.aspx?DinKrypteredeStreng=qwerty&asdfg=zxcvbn

Den dag kommer ikke ;)... alt og jeg mener alt i min Query bliver krypteret...

Som det var tænkt før (og da '+' gav problemer) ville de tegn rigtit nok være et problem... men nu har jeg faktisk slet ikke behov for alt det bras mere...

det med replace af ' ' til '+' har bare hængt ved. men har lige prøvet og det er slet ikke nødvendigt mere... så nu har jeg vist den helt rigtige løsning til det jeg skal bruge det til...
_____________________________________________________________________________________

et eksempel på et link:

default.aspx?page=messages&module=private&action=open&mode=relay

bliver fx til: (med en anden nøgle)

default.aspx?zk/cpza+v/2TLZBfVqh8XipvCgJkY2c7bOhRy32g6e/5wSzSNereZbKT1RAjMmszJxyK2SOu1VU=


der er altså ingen default.aspx?dinKrypteredeStreng=nogetbrass...
derfor får jeg altid kun en ren lang kryptering og derfor bliver de sedvanlige operatorer der er i forbindelse med ens Query ('=' og '&') helt overflødelige...

det jeg bruger er så "Request.Url.Query" og som det viser sig henter den din Query helt RAW, dvs at +'er heller ikke bliver reformateret ser det ud til...

Så faktisk er det den Rigtige løsning i mit tilfælde...
Og nu burde URL-Encode så falde helt uden for perspektiv...