Nån som har något bra tips?

Har kollat lite på blowfish, des och en mängd andra men skulle vilja hitta en kryptering som uppfyller följande 3 saker samtidigt:

*Behöver kryptera och avkryptera data i både vb6 och c# (vb6 kommer att finnas på klient och c# på server, både klienter och server kommer att både kryptera och dekryptera samma data.)

* Använda krypteringsnyckel

* Använda randomize så att krypteringsresultatet inte alltid ser exakt likadant ut.

Inte riktigt inne på om du vill ha ett krypterings-api eller om du ska skriva det själv.

Ska du skriva själv och använda både VB6 och C# så bör du nog oavsett vad du gör använda dig en separat slumptalsgenerator, risken finns att det är olika typer av generatorer, och att den ändras mellan versioner.

Sen får du nog förklara din slump-grej lite... hur har du tänkt att det ska fungera?
Om du har ett meddelande och en nyckel, ska det bli olika kryptering för olika tillfällen?

Kan inte påstå att jag kan mycket om kryptering, men den andra sidan måste ju veta hur den ska avkryptera informationen, och då måste du ju skicka med ett seed oavsett... Då blir det bara "encryption by obfuscation", inget som funkar i längden.

man kan slumpa in diverse tecken som man normalt inte använder i text i meddelandet före man använder nyckeln så det blir resultatet olika varje gång man krypterar.
Och mottagaren tar lätt bort dom konstiga tecknen efter nyckeln är använd.

Men vad är poängen?
Varför vill man alltid ha olika?

Slumpgrejen används på så sätt som, Herman förklarar.

Varför jag vill ha olika resultat:
För att ställa till lite extra problem för de kunder som försöker
komma på hur vi avkrypterar...för att komma åt informationen...

Jag skulle vilja hitta färdig kod som jag kan kopiera in ifall jag
skulle vilja ge mig på att ändra något.

Än så länge har jag hittat kryptering med blowfish (kod som jag både kan använda i vb6 och c# och som fungerar på samma data), men de saknar slumptalshanteringen.

lättast är väll att appenda en slumpad header på det data du krypterar.
säg att första 5 bytarna i datat ALLTID är slumpvärden.

så om ditt data är 10bytes från början så är det 15 bytes med slumpheadern.
och när du krypterar det så kommer det krypterade resultatet att bli annorlunda.

när du avkrypterat ditt data så skiter du bara i att läsa de första 5 bytarna.

//Roger

Lättast är inge bra ord när man krypterar ;)

Det är extra viktig att slumpa om texten är statisk.

Jag testade krypterade en topplista för ett tag sen. Och började med att försöka förändra tecknena på olika sätt. Men det var ändå ganska lätt att se samband för texten var så statisk. Så jag löst det med att slumpa in en massa olika tecken. Jag slumpade både antal och sorts tecken. Det gjorde jag mellan alla tecknena i texten. Då blev det helt klart mycket svårare och se något samband.

Vet inte hur avancerat det blev men det funkade bra för mig.

> Men vad är poängen?
> Varför vill man alltid ha olika?

Det man egentligen vill ha är olika nycklar. Om man studerar krypterade texter och gör vissa antaganden om att det kanske är en html-fil (som börjar med <!DOCTYPE) eller kanske ett word-dokument (som börjar med en särskild header), och lyckas träffa rätt så kan man få fram nyckeln. Har sen samma nyckel används till att kryptera fler meddelanden så är ju de också knäckta.

Japanerna gjorde det misstaget under andra världskriget. Alla meddelanden till deras ambassadör skickades krypterat. Amerikanerna la märke till att vissa meddelanden var lika långa som pressmeddelanden som samtidigt skickats ut och började fundera på om det krypterade meddelandet kanske kunde vara pressmeddelandet. Och mycket riktigt. De visste därmed vad den krypterade texten stod för i klartext och kunde få fram nyckeln...

Men varför inte lösa problemet med RSA? Använd RSA för att kryptera din privata nycklar, då kan du ju byta nyckeln godtyckligt ofta. Byter man tillräckligt ofta blir det ju svårt att få tillräckligt material för att köra någon statistisk analys på datan. Då kan du t ex använda Blowfish med en färsk nyckel var 30:e minut eller liknande. Hur ofta nyckeln behöver bytas beror ju på hur mycket data som skickas per tidsenhet.

Jenny, jag hoppas du är medveten om att du med kryptering skyddar överföringen mellan klient och server. Det skyddar inte mot den som har tillgång till ditt program.

I vårt system kan våra kunder skicka sms till sina kunder. (SMS är inte
huvudfunktionaliteten i systemet, utan det är ett dentalprogram med diverse
funktionalitet såsom kundregister, journalhantering, tidbok och en mängd annat)
Vi vill inte skydda datan för sms med kryptering för att den är hemlig, det är den inte,
utan tabellerna i databasen är öppet för läsning (både med och utan vårt program)
så länge de har behörighet i databasen/programmet.

Det är inte hela världen om de kommer på krypteringsalgoritmen, vi vill bara
försvåra så att det inte är, allt för enkelt, att använda sig av externa sms program.

I huvudtabellen för SMS har vi ett enda fält som innehåller en krypterad
checksum på vissa fält för den aktuella raden i tabellen. Så länge denna
checksum stämmer "vet vi/att det är stor chans" att de inte själva har
manipulerat med datan med eventuella externa program. Så länge checksummen
stämmer så förutsätter vi att de använt vårt program och därmed har de också
tillgång till mycket mer funktionalitet i dentalprogrammet. Vi visar status för sms:
om det ligger i kö, är ivägskickat mm. Vi hanterar smssvar från deras kunder
etc, etc så länge vi anser att de använt sms i vårt program.

Visst kan vi hålla på att byta nycklar osv, det kan vi också göra i tillägg till
de tre saker jag tidigare nämnt i mina tidigare inlägg. Men vi skulle gärna (inte ett
måste) vilja hitta kryptering med slumptal. Just för att försvåra att det inte är lika
lätt att hitta mönster om resultatet blir olika varje gång man krypterar.

Vi är nöjda med den kryptering vi har i nuläget, men vi ville gärna se om någon här hade
något tips på slumptalshantering som vi skulle kunna ta oss en titt på.

Jag tackar för alla tips, men håller tråden öppen ett tag till för att se
om någon har ett bra tips om just slumphanteringen.