[.Net] Encryptie

[mr_taipan]

Ik ben al de hele dag aan het proberen om een soort licentie generator te maken.

Het idee was om met een RSACryptoServiceProvider een config bestandje te encrypten en deze dan op te sturen samen met de public key.
De config kan dan altijd ingelezen worden maar nooit aangepast omdat ik had gedacht dat je voor het opnieuw encrypten van de config de private key nodig hebt.

Maar nu hebben ze bij microsoft bedacht dat je voor decrypten altijd de private key nodig hebt. Is er ook een manier om dit te omzeilen? Of zijn er anderen manieren om een config bestandje asymetrisch te encrypten zodat deze met een public key gedecrypt kan worden?

[mulder]

Zou dat niet 'defeating the purpose' zijn?

[mr_taipan]

Op zich hoeft de beveiliging niet heel er goed te zijn alleen moet de config file niet meer human readable zijn en ook niet makkelijk aan te passen.

[BasieP]

waarom heb je een config file bij een client staan wanneer de client hem niet mag aanpassen?
en helemaal wanneer je een server nodig hebt om de file dan te kunnen lezen, waarom gooi je dan niet de config file (of in jouw geval de licentie) op de server zelf?

[ Voor 194% gewijzigd door BasieP op 19-04-2007 16:30 ]

[CyBeR]

Het lijkt me sterk dat je de private key nodig hebt om te decrypten. Die is namelijk nutteloos als je de file al ge-encrypt hebt met die key. Encrypt de file met de private key, en geef de decrypt routine gewoon de public key. Waarschijnlijk gaat microsoft uit van een omgekeerd gebruik: encrypten met public key zodat de private key 'm kan decrypten.

[dotcode]

Misschien handig om eerst uit te zoeken hoe Public/Private key encryptie werkt en waarvoor je het nodig hebt.
Voor Encrypten:
Private key computer A + Public key Computer B
Voor Decrypten:
Private key computer B + Public key Computer A

Maar volgens mij ben je niet opzoek naar Public/Private key encryptie, want je wilt je configuratie encrypten. Als comunicatie wil beveiligen zou je eerder aan certificatie kunnen denken waarby je ook nog eens zeker weet dat je met de juiste persoon aan het babbelen bent.

[BasieP]

dotcode schreef op donderdag 19 april 2007 @ 16:39:
Voor Encrypten:
Private key computer A + Public key Computer B
Voor Decrypten:
Private key computer B + Public key Computer A

volgens mij leg je het verkeerd uit.


even een voorbeeld waarbij A de zender en B de ontvanger is.

wanneer de ontvanger een encrypt bericht krijgt (Missie opdracht van de CIA) moet hij dit bericht (wat ge-encrypt is met een public key van B decrypten met de private key van B

dit is een methode om te zorgen dat alleen B het bericht kan openen.


verder kan encryptie ook gebruikt worden voor authenticatie, waarbij het dus precies andersom is.

B wil weten of A wel echt de CIA is. Dan stuurt A een bericht naar B, geencrypt met hun eigen private key. Dit bericht kan dan alleen gedecrypt worden met de public key van A
Waarmee dus bewezen wordt dat A echt de CIA is

de public key is public dus die kan iedereen ophalen, bij de bekende key distributeurs (direct een zwak punt in het hele encryptie verhaal)

[ Voor 48% gewijzigd door BasieP op 19-04-2007 16:53 ]

[CyBeR]

Ehm. Om precies te zijn:

De CIA genereerd een private en een public key. De public key geven ze weg, de private key houden ze geheim. Vandaar de naamgeving. Nooit andersom.

Nu wil een agent een geheim bericht naar de CIA sturen. Dan neemt die agent dus de public key van de CIA en encrypt het bericht. Nu kan niemand het bericht lezen zonder te beschikken over de private key van de CIA. Als de CIA iets terug wil sturen moeten zij de public key van de agent zelf hebben en wordt bovenstaand proces gewoon hetzelfde uitgevoerd.

Signing werkt idd andersom: ik neem mijn private key en maak een signature. Vervolgens kan iedereen met mijn public key controleren of de signature bij mij vandaan kwam.

[ReverendBizarre]

Inderdaad, private keys worden nooit uitgedeeld op wat voor manier dan ook. Dus dat verhaal van BasieP klopt niet helemaal. Je encrypt altijd met de public key van de gene waar je iets naar toe gaat sturen. Dat kan dan vervolgens alleen met de private key van die persoon (die alleen hij heeft en *nooit* verstuurd wordt naar iemand anders) gedecrypt worden. Als hij wat terug wil sturen naar jou dan moet hij jouw public key gebruiken. En inderdaad voor authenticatie gaat het precies andersom en gebruik je je eigen private key om een signature te coderen die alleen met jouw public key gedecodeerd kan worden waardoor men dus zeker weet dat het van jou vandaan komt (want niemand anders hoort jouw private key te hebben).

Vandaar dus het concept van public key servers waar je de public keys van andere mensen kan opvragen. Dat is dus geen zwak punt maar een normaal onderdeel van asymmetrische encryptie.

[mr_taipan]

CyBeR schreef op donderdag 19 april 2007 @ 16:30:
Het lijkt me sterk dat je de private key nodig hebt om te decrypten. Die is namelijk nutteloos als je de file al ge-encrypt hebt met die key. Encrypt de file met de private key, en geef de decrypt routine gewoon de public key. Waarschijnlijk gaat microsoft uit van een omgekeerd gebruik: encrypten met public key zodat de private key 'm kan decrypten.

En daar zit het probleem met de met de rsanogwatprovider kun je alleen encrypten met de public key. Wat mij meteen op het idee brengt om die public key uit te keyfile te gaan halen en dan alleen de private key mee te geven.

Volgens mij maakt het niet zo veel uit hoe de key heet die je weggeeft als je maar zorgt dat de andere helft geheim blijft.

[bazzs2001]

mr_taipan schreef op vrijdag 20 april 2007 @ 08:49:
[...]


En daar zit het probleem met de met de rsanogwatprovider kun je alleen encrypten met de public key. Wat mij meteen op het idee brengt om die public key uit te keyfile te gaan halen en dan alleen de private key mee te geven.

Volgens mij maakt het niet zo veel uit hoe de key heet die je weggeeft als je maar zorgt dat de andere helft geheim blijft.

Als ik me niet heel erg vergis heeft CAIRAT gewoon gelijk en maakt het wel degelijk uit welke key je weggeeft. Jou oplossing gaat gewoon niet werken met RSA...

Dus afhankelijk van het probleem zal je met een andere oplossing moeten komen...

Als het niet human-readable mag zijn kan je dan niet beter gewoon een symetrisch algoritme gebruiken?

[BasieP]

CAIRATH schreef op donderdag 19 april 2007 @ 17:00:
Inderdaad, private keys worden nooit uitgedeeld op wat voor manier dan ook. Dus dat verhaal van BasieP klopt niet helemaal.

ik had idd een keer public en private omgedraait, maar dit had ik al gefixed voor jij poste.. ff refreshen volgende keer