Bifid Cipher Krypteringsalgoritme

[brgr]

Hei.

 

Satt og leste litt om kryptering og slikt og kom over en veldig enkel krypterings algoritme.

Har satt opp noen klasser for bruk av dette.

 

http://en.wikipedia.org/wiki/Cipher

http://en.wikipedia.org/wiki/Bifid_cipher

 

Nå er det bare lagt inn for Bifid Cipher, men vurdere å skrive en klasse for Trifid Cipher

Har lagt inn æøå, og tall.

 

Kom gjerne med tips til hvordan jeg kan forbedre koden min. Ettersom det er den første skikkelige krypterings algoritmen jeg har satt sammen.

 

- BrGr

Bifid.rar

Endret 27. november 2009 av brgr

[MailMan13]

Ser nesten helt fint ut det der. En design ting og en sak som ikke gjør det du tror den gjør:

 

1. Strings er immutable: Dvs at tilstanden ikke kan endres etter instansieres. Når du sier Row1.Trim() så returnerer den en ny "trimmet streng", men den kan ikke endre den eksisterende. "Row1 = Row1.Trim()" vil oppnå det du prøver å gjøre.

 

2. Strings er immutable, pkt 2: '&' operatoren kan ikke appende til eksisterende strenger, den må allokere minne til en ny streng og kopiere innoldet av operandene inn i denne hver gang du kjører loopen. Om inputstrengen din er stor her vil du bruke mye minne og mange malloc() kall under panseret som vil gjøre koden din eksponensielt tregere og minne-intensiv i forhold til input størrelse. Bruk en StringBuilder til å lage strengen og assign denne til _Bfid til slutt. Siden du vet størrelsen på strengen kan du instansiere en builder av riktig størrelse med en gang, og slippe unna men en eneste allokering.

 

Feil bruk av '&' operatoren er en vanlig kilde til ytelsesproblemer i mange "Classic ASP" baserte systemer. Da hadde man ikke ordentlig StringBuilder tilgjengelig og mange utviklere fra den tiden tok desverre med seg uvanen over på .NET senere. Vi sliter nesten daglig med "Out of String space"-krasj i et gammelt system hos en kunde fordi IIS fyller opp minnet på serveren med strings fortere enn garbage kollektoren klarer å rydde dem unna, ikke får vi gjort noe med det heller da den grunnleggende arkitekturen i systemet er bygget på å konkatenere sammen html-kode.

 

3. _Bifid = "Feil!!" + Exit Sub : Ikke bruk returverdien til å si ifra om at det gikk feil. Unngå å bruke exit sub også, man vil helst ha kun ett exit punkt i en funksjon. Måten å gjøre det på er "Throw New Exception("Feil...")". Lag gjerne din egen Exception klasse med et godt navn for denne feilen. Siden klassen din også blir immutable er det ikke noen grunn til at man skal kunne instansiere et objekt av den i en feiltilstand, da unngår du også å måtte skrive defensiv kode alle steder klassen brukes.

Endret 30. november 2009 av MailMan13

[brgr]

Takker for svar =) Skal sette meg ned og jobbe litt mer med dette.

 

Det er også en annen feil med koden min som du kanskje ikke la merke til. Men det er att tabellen ikke er kvadratisk, og det MÅ den være for å alltid kunne gi oss gyldige posisjoner på bokstaver.

 

Skal se om jeg legger inn en scramble metode med en nøkkel input. Eller noe i den duren.

 

Skal fikse opp disse strings feilene, og se om jeg får laget en Exception klasse. (noe jeg dog aldri har gjort før). Men lærer ikke av å ikke prøve ihvertfall!

 

Takk for svar =)

[GeirGrusom]

3. _Bifid = "Feil!!" + Exit Sub : Ikke bruk returverdien til å si ifra om at det gikk feil. Unngå å bruke exit sub også, man vil helst ha kun ett exit punkt i en funksjon. Måten å gjøre det på er "Throw New Exception("Feil...")". Lag gjerne din egen Exception klasse med et godt navn for denne feilen. Siden klassen din også blir immutable er det ikke noen grunn til at man skal kunne instansiere et objekt av den i en feiltilstand, da unngår du også å måtte skrive defensiv kode alle steder klassen brukes.

Dersom funksjonen ofte vil feile, er det ikke bra ytelsesmessig å gi exceptions (exceptions gir eksepsjonelt dårlig ytelse )

 

Bruk dem for kritiske feil som ikke burde behandles direkte av programmet, for eksempel filer som mangler, forbindelsen til serveren er lukket, formateringsfeil i data etc. Men feil som potensielt kan ofte dukke opp, objekt eksisterer ikke i en samling, ingen objekter treffer søket, listen er tom etc. bør gjengis med en returverdi, da dette er tilnærmet gratis i ytelsessammenheng.

[MailMan13]

Dersom funksjonen ofte vil feile, er det ikke bra ytelsesmessig å gi exceptions (exceptions gir eksepsjonelt dårlig ytelse )

Nja, ytelsestapet er i størrelsesorden noen hundre nanosekunder, så man kan ikke gjøre for mange tusen av dem i sekundet før det blir merkbart, det er riktig. Koden som kan feile her er i konstruktor, så om den kalles så ofte er man allerede ute å kjøre. Nå er det svært få real-life systemer utenom spillmotorer hvor CPU tid er en flaskehals.

 

Problemet med å kode et feilresultat inn i outputen er at du tilfører implisitt logikk som alle som koder i systemet må vite om, og hvis det er mer enn 1 blir det problematisk, er det mer enn 2 er det sannsynligvis ikke mulig.

 

Primærårsaken til å bruke et Exception her er at vi her er i konstruktor, og kan garantere at alle instansierte objekter av denne klassen vil være i en gyldig tilstand. En resultat-kodet feil snur ansvaret for validering av objektet til den kallende koden, det blir også feil i forhold til objektorientert design da en del av oppførselen faller utenfor klassen. Det er ikke bra da det øker sannsynligheten for at denne koden må lages flere steder (eller verre; at man glemmer å skrive den slik at det ikke validerer i det heletatt).

 

Skjønner hvor du kommer fra dog. Satt selv i timesvis og inlinet funksjoner i Java for å spare noen ms mellom hver frame i whatever spill jeg prøvde å lage remake av

 

Nå er verdien av dette litt redusert i .NET siden man ikke eksplisitt deklarerer "Throws" for å tvinge brukeren til å håndtere det, slik man gjør i Java.

 

Men feil som potensielt kan ofte dukke opp, objekt eksisterer ikke i en samling, ingen objekter treffer søket, listen er tom etc. bør gjengis med en returverdi, da dette er tilnærmet gratis i ytelsessammenheng.

Ingenting av dette høres ut som feilsituasjoner... At en funksjon returnerer null eller en tom collection er normalt helt problemfritt og sjelden noe en vil kalle en feilsituasjon.

 

Det som ikke alltid er OK er om den returner et objekt som er implisitt kodet i en eller annen feiltilstand, da er det lett å havne ut på glattisen senere.

Endret 30. november 2009 av MailMan13

[GeirGrusom]

Jeg synes ikke exceptions er noe som skal foregå i et program som kjører normalt. Exceptions kommer heller når noe uventet skjer.

 

I en constructor må en jo gi en exception, alt annet ville vært kriminelt.

 

Jeg vet også at jeg har en tendens til å fokusere for mye på ytelse, men dersom det foregår hundrevis i en kodebit, vil det være merkbar ytelsesbedring for programmet å fjerne dem.

 

Det er heller ikke veldig god skikk (som du sier) å forme kompliserte enumerations eller lignende for å gi tilbake feil. Nå er enums i C# en helt gratis returverdi, men det er ikke noe særlig å sitte å teste for feil på denne måten.

 

Så jeg er ikke egentlig uenig i det du sier, men dersom en kan slippe exceptions på en enkel og grei måte (som TryParse vs. Parse) så ser jeg ihvertfall en fordel ved det.

Endret 30. november 2009 av GeirGrusom