Symmetrische AES256 is op zich een veilige vorm van encryptie, maar het hangt vooral af van de implementatie of het werkelijk veilig is. Je kan wel wat versleutelen, maar daar is een wachtwoord voor nodig. Als dat wachtwoord op hetzelfde systeem staat of wordt gebruikt, en het systeem wordt gehackt/geroot is het mogelijk het wachtwoord te achterhalen.

Versleutelen kan asymmetrisch plaatsvinden. In dat geval is het niet nodig dat er een wachtwoord op het opslagsysteem staat.

Ik weet niet of je je zo druk moet maken om je BSN. Die slingert toch al rond bij werkgevers, uitkeringsinstanties, verzekeraars en medisch behandelaars. En de belastingdienst vond het nodig om ZZP-ers te verplichten een BTW nummer te gebruiken dat gebaseerd was op hun persoonlijke BSN.

BSN zou ik mij zeker druk om maken, vooral wat je ermee kan doen. AES256 is wel veilig, maar zoals eerder werd gezegd gaat het over de implementatie ervan.

BSN geven om DAC-7 wetgeving? Ik denk dat degene die het wil hebben niet snapt wat AVG betekent. BSN is niet nodig en mag helemaal niet worden gebruikt voor dit doel.

AES256 is veilig, maar het valt of staat met de implementatie. Er is geen enkele garantie dat die implementatie goed is. Pure marketing kreet.

Met AES versleuteld plaatje van penguin (credits: Fillipo Valsorda): https://filippo.io/images/Tux-ECB.png

als je er geen goed gevoel er bij heeft gewoon niet doen....de mensen zijn veel te makkelijk met de gegevens van daar bestaat
security.nl..om tips

als je zelf wat verkoopt waarom moet je je gegevens laten zien dat ga ze geen donder aan......je vraagt toch ook niet om zijn portemonnee??

Als antwoord op de originele vraag, ik denk dat encryptie hier niet zo relevant is.
Het gaat om of jij het platform vertrouwd met je BSN.
Doe je dat niet, dan moet je een platform zoeken dat je wel vertrouwd, of gewoon niet/offline verkopen.


lol, ik kan zelf een beter encryptie algoritme verzinnen denk ik... :-)

Zou dat trouwens een leuke challenge zijn voor de IT-nerds in het blog?
(Het maken van en breken van andermans zelfgemaakte cryptografie algoritmes.)

Tux-ECB plaatje toont aan dat de ECB werkwijze (elk blok dezelfde key) niet goed is; zegt weinig over AES.

@TS. Je moet je afvragen of de AES encryptie at rest of in transit is.

Als die at rest is dan kan een aanvaller er niet meer bij zodra de stroom van de harddisk af gaat, bijvoorbeeld bij fysieke diefstal. Dit lijkt veilig, maar de harddisk zal toch toegankelijk moeten zijn voor de software waar je BSN in opgeslagen is.

Het probleem met alle encryptie is dat het algoritme heel veilig kan zijn, maar dat er andere manieren zijn om bij de sleutel te komen. Bijvoorbeeld met een backdoor in het operating system. Of met een keylogger. Of een camera gericht op je toetsenbord.

Hoe minder data je opslaat en hoe minder accounts je gebruikt, hoe beter. Dat is mijn filosofie. Een account wat niet bestaat kan je ook niet hacken.

Waarom geef je niet een fake BSN nummer op?

AES-256 met een flink lange complexe sleutel is veilig om data tegen meekijkers te beschermen.
De vraag is hoe gaat de partij om met de sleutel die de data kan ontsleutelen? waar wordt die bewaard, hoe complex is deze en wat is de levensduur ervan?

Afgezien het BSN juist hiervoor bedoelt is.

https://www.rvig.nl/autorisatielijst-bsn-gerechtigden
https://goedestartbelastingdienst.nl/wiki/view/265a09bc-59f5-4320-8b02-905183b3ec2f/gegevensuitwisseling-digitale-platformen-dac7
https://www.autoriteitpersoonsgegevens.nl/themas/identificatie/burgerservicenummer-bsn/bsn-op-digitale-verkoopplatforms

Google is your friend, of gebruikt 1 of andere eend...... "DAC7 BSN"

Zie hoofdstuk 4:
https://www.ncsc.nl/wat-kun-je-zelf-doen/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1

AES-256-GCM is goed!
AES-256-CBC is voldoende.

Het plaatje in de eerdere verhalen is versleuteld met AES-256-ECB....

Dat denk ik niet.
AES is een prima algorithme. Maar wat dat plaatje laat zien is dat data (groter dan de 128 bit blocksize van AES) versleutel in 'ECB' mode - Electronic Code Book erg veel informatie laat lekken.

Laat je eigen gedachten eens gaan over het probleem hoe je tig megabytes aan data versleuteld wanneer je bouwsteen een block cipher is die brokjes van 128 bit input versleuteld naar 128 bit output.

De meest voor de hand liggende manier is ECB - en dat is Niet Zo Goed.


Waarschijnlijk niet. Een zee van amateur bouwers, met complexe voorstellen , en amper experts die dan ook zwakheden tot een decryptie kunnen uitbouwen.
Het moet wel heel erg amateur zijn wil een amateur het ook kunnen breken.

https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign

https://www.schneier.com/academic/archives/2000/01/self-study_course_in.html

Een gebruikelijke voldoende veilige wijze is het gebruik van CBC. Dat is code block cipher, en dat gebruikt de output van de vorige data in een XOR met het volgende blok. Een vorm van een veilig geachte block cipher is GCM, in dit geval AES256-GCM.

De topic starter kan vragen hoe de AES is geimplementeerd. Dan zal het misschien stilvallen aan de andere kant, in dat geval kan je de privacy officer deze vraag stellen. Als die de vraag niet kan beantwoorden heb je een inschatting van de security kennis bij de aanbieder.

-----

Overigens zijn er Nederlandse organisaties die op hun verzendende mail servers GCM niet aanbieden in TLS 1.2. Waarom niet? Ik vermoed dat een of andere buitenlandse compliancy officer zonder afdoende kennis CBC doordrukt als "strict" omdat ze denken dat NIST dat aangeeft (verouderde FIPS 140-2?). NIST heeft namelijk bezwaren geuit op GCM in het begin van de jaren 2000. Die zijn echter niet van toepassing op de huidige implementaties van TLS 1.2. In TLS 1.3 is GCM aanwezig in 2 van de 5 security suites, en CBC komt er niet in voor.

https://www.google.com/search?q=NIST+GCM+danger

AES is onveilig. nog niet eens vanwege collisions of implementatiefouten maar:

# is van 1998, dus te oud
#2 goedgekeurd door NSA, dus onveilig
#3 implementaties, zoals CBC zijn inherent onveilig, omdat het wiskunde is. ik kan wiskundig 1+1=3 maken, en we weten allemaal dat dit niet correct is.
#4 data heeft sleutels, waar zijn de sleutels? dan is het net als het beste slot en de sleutel onder de bloempot

Stel jij het op prijs als dat fake BSN per ongeluk jouw BSN is en jij onverwacht wordt aangeslagen voor verkopen die je helemaal niet hebt gedaan en gedonder krijgt omdat je ze niet in je eigen belastingaangiftes had verwerkt?

En zou het opgeven van een vals BSN misschien gelden als valsheid in geschrifte en strafbaar zijn?

Niet aan beginnen. De schade is altijd groter dan de winst.
AES256 mag dan (op het moment) nog veilig zijn. Maar hoe zit het met key management? Vertrouw je de site?
Beiden niet te controleren en dus gewoon niet aan beginnen.