Privacy - Wat niemand over je mag weten

crypto bewijs: dezelfde anoniem

17-10-2019, 22:28 door Erik van Straten, 87 reacties
Laatst bijgewerkt: 17-10-2019, 22:45
Af en toe, zo ook in [1], is er op security.nl onduidelijkheid of een anonieme bijdrage van de hand van dezelfde persoon is als een eerdere anonieme bijdrage.

In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken, maar kennelijk wil niet iedereen dat en bovendien is zelfs dan nog verwarring mogelijk... (als ik me goed herinner was er op deze site ooit een account genaamd karrna4 of iets dergelijks, waar ik aanvankelijk intrapte).

Maar laten we het bij security houden: het kan ook anders, namelijk m.b.v. (eenvoudige) cryptografie! Nb. deze bijdrage is bedoeld om te laten zien wat er zoal mogelijk is. Ik verwacht niet dat alle anoniemen hierop duiken en lezers voortdurend met cryptografische hashes in de weer zijn - het is meer een gedachtenspinsel, een soort "blockchain" zeg maar (om eens iets hyperigs te noemen ;-)

Het gaat als volgt. Genereer een random getal en sla dat, hexadecimaal, op bovenin een tekstbestand. Herhaal, bijv. 3 keer: bereken een cryptografische hash van het onderste getal in dat bestand en sla het resultaat daaronder op. Zie bijvoorbeeld het onderstaande lijstje.

b041077eab986619c65a0957b4d76e72fa76afbfce683ec9d70d25bef243256b
d962565d8101e23de61a4db0a3373a2ad74577411d51cd211832dcde90f941ef
d60606f7d0d4aa5dfb9b1b4514fb1bcf9c6ef79807aeb5abc36198af297b8cec
e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178

Voor alle duidelijkheid: de vierde regel bevat de sha256 hash van de derde regel, die derde regel bevat de sha256 hash van de tweede regel enzovoorts. Nb. Ik heb hier steeds sha256 gebruikt over de tekstuele representatie van de hexadecimale getallen (en eerlijk gezegd is het bovenste getal niet het random getal zelf, maar de sha256 hash van de tekstuele representatie van het decimale getal 867363300 dat ik door [2] heb laten genereren).

In jouw eerste anonieme bijdrage zet je onderaan jouw nickname, gevolgd door de onderste hash (e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178 dus), die je meteen daarna verwijdert uit het tekstbestand. Schrijf in jouw bijdragen ook welk algoritme je gebruikt, zodat eenieder kan vaststellen dat jouw volgende bijdrage ook daadwerkelijk van jouw hand is.

In jouw eerstvolgende bijdrage neem je opnieuw de onderste regel uit het tekstbestand op, waarna je ook die regel weer verwijdert (uit dat tekstbestand). Omdat iedereen kan controleren dat sha256(d60606f7d0d4aa5dfb9b1b4514fb1bcf9c6ef79807aeb5abc36198af297b8cec) de waarde e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178 oplevert (je kunt dit bijv. online checken in [3]), kan iedereen vaststellen dat het om dezelfde auteur (al dan niet anoniem) moet gaan als de auteur van de vorige bijdrage.

Immers, voor een cryptografische hashfunctie geldt dat een computer razendsnel kan uitrekenen wat het resultaat is van sha256(d60606f7d0d4aa5dfb9b1b4514fb1bcf9c6ef79807aeb5abc36198af297b8cec), maar dat de soorten computers die we nu kennen (en hoogstwaarschijnlijk quantumcomputers) ongeveer oneindig lang moeten rekenen om op basis van het resultaat van zo'n sha256 berekening, uit te rekenen wat de input moet zijn geweest. Voor sha256 geldt tevens dat het bijna net zo lang duurt om een andere inputwaarde te vinden die toevallig hetzelfde resultaat oplevert (een collision noemen we dat; een identiteitsfraudeur kan, met het hier voorgestelde algoritme, natuurlijk ook met een collision "bewijzen" dat hij jij is - maar dan moet hij wel eerst zo'n collision zien te vinden).

Vier bijdragen is wellicht niet zoveel, maar niets belet je om meteen 1000 "opeenvolgende" hashes te berekenen. Ook kun je, zodra een reeks bijna op is, deze laten "overnemen" met een nieuwe reeks, d.w.z. door in één bijdrage zowel het laatste getal uit de oude reeks als het onderste getal uit het nieuwe bestand (met de nieuwe reeks) te noemen.

Met dit algoritme kun je, met flinke zekerheid, bewijzen dat jij nog steeds dezelfde jij bent (tenzij iemand anders zo'n tekstfile in handen krijgt, jouw eerste random getal voorspelbaar bleek te zijn [*], of de moderator c.q. een hacker van security.nl jouw hashes -of juist de tekst in jouw bijdragen- wijzigt). En dit algoritme is -hoogstwaarschijnlijk- nog quantum-proof ook!

[1] https://www.security.nl/posting/626870/Sudo+rechten+geven+en+schade+beperken#posting628025
[2] https://www.random.org/integers/?num=1&min=1&max=1000000000&col=1&base=10&format=html&rnd=new
[3] https://xorbin.com/tools/sha256-hash-calculator
[*] Als je echt zoiets wilt doen, zou ik een echte CSPRNG gebruiken i.p.v. random getallen gegenereerd door een website.
Reacties (87)
17-10-2019, 23:14 door Anoniem
Door Erik van Straten: Af en toe, zo ook in [1], is er op security.nl onduidelijkheid of een anonieme bijdrage van de hand van dezelfde persoon is als een eerdere anonieme bijdrage.

Nou ik was het niet in elk geval @ "07:50 door donderslag - Bijgewerkt: Vandaag, 08:11 " in het inlichtingen - Volkskrant topic wat gelukkig gesloten is. Deze reageren uit onvrede. Die periode heb ik ook doorgeleefd. Zo'n topic wordt snel politiek en men gaat op de persoon spelen hier op de site en gelukkig komt er dan een slotje op. Gelukkig ben ik steeds minder frequent op internet te vinden. Of lees ik alleen nog zonder te reageren.

Inloggen met een wachtwoordmanager is sneller dan een tekstbestand wijzigen. Ik denk dat de mensen die even snel iets plaatsen geen " crypto " backlog gaan aanleggen.



In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken, maar kennelijk wil niet iedereen dat en bovendien is zelfs dan nog verwarring mogelijk... (als ik me goed herinner was er op deze site ooit een account genaamd karrna4 of iets dergelijks, waar ik aanvankelijk intrapte).


Ik raad een account aan. Ik heb al meegemaakt dat mensen (weet nu ook wie) mij gedoxt hadden en mijn quote misbruikten. Ik heb me daar nadien en daardoor ook schuldig aan gemaakt op een nieuwssite maar ben daar mee gestopt. Dat was onderdeel van een proces waar ik nu uit ben.

Het is natuurlijk handig om anoniem te posten maar ik ben door schande en schaamte of beter gezegd ervaring wijzer en minder rebels op privacybeleid en daardoor ook voorstander van verplichtte registratie. Dat de moderatie hier accountloos toelaat is heel nobel. Zolang het een eigen security.NL database is en geen "inlog met Facebook, Disqus of Google".

Soms zijn minder woorden beter, dan springt de useful stuff er tussen uit. De techniek, daarvoor zijn we hier. Jouw posts zijn daar altijd een voorbeeld van. Dus daar ga ik ook persoonlijk een voorbeeld aan nemen. Verfrissend en professioneel, iets wat me doet denken aan vroeger. Meer op de techniek toegesneden in plaats van op reacties van andere personen met ieder zijn eigen onderbuik aan het woord.

Het kaf van het koren scheiden wordt met de tijd steeds een eenvoudigere zaak als je ziet wat voor topics hier worden aangemaakt met vragen ("Wat is een daemon process?". Dingen die je maar hoeft te googelen. In elk beginnersboek staat dit uitgelegd. Het is opmerkelijk dat dit nog door de moderatie komt.
17-10-2019, 23:16 door Anoniem
Je kunt ook gewoon een account aanmaken.
18-10-2019, 10:27 door Erik van Straten - Bijgewerkt: 18-10-2019, 10:41
Door Anoniem: [...] Inloggen met een wachtwoordmanager is sneller dan een tekstbestand wijzigen. Ik denk dat de mensen die even snel iets plaatsen geen " crypto " backlog gaan aanleggen. [...]
Zoals ik schreef, ik verwacht niet dat dit opgevolgd gaat worden (in elk geval niet massaal). Maar wie weet heeft iemand er een slimme toepassing voor. Zoals een dissident die met een journalist communiceert en anoniem wil blijven, maar waarbij er bij de journalist geen twijfel mag bestaan dat het steeds om dezelfde dissident gaat.

Ik realiseer me dat dissidenten in sommige landen terrroristen worden genoemd; je kunt dit soort technieken goedschiks en kwaadschiks gebruiken. Maar ook dit is een voorbeeld van dat je cryptografie niet moet willen backdooren om "boeven te kunnen vangen", want die boeven maken dan hun eigen protocollen wel (dat is doodsimpel zoals je hierboven lezen), terwijl brave burgers het -enorme- risico lopen dat de sleutel van de backdoor in de door hen gebruikte software/hardware in verkeerde handen valt.

Door Anoniem: [...] Ik raad een account aan. [...]
Waarom post je dan anoniem?

Door Anoniem: Je kunt ook gewoon een account aanmaken.
Gegeven een TS-bijdrage waarin staat: "In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken". Dan kun je die tekst natuurlijk niet lezen en toch menen iets zinvols aan de discussie bij te dragen met jouw post. Om niet te worden uitgelachen door mensen die weten wie jij echt bent, kun je zoeits inderdaad maar beter anoniem doen. De kans dat jouw bijdrage gelezen wordt is dan trouwens ook groter (van trollen met een account weten serieuze bezoekers van security.nl meteen welke bijdragen ze kunnen overslaan).

Uit https://www.security.nl/posting/626870/Sudo+rechten+geven+en+schade+beperken#posting628127:
18-10-2019, 08:32 door Superuser: [...] Voor security.nl zou het een kleine moeite zijn om met de on-line fingerprint v.e. gebruiker (ip-adres, browser id, os, patronen in muis- en toetsenbordgebruik, etc.) een uniek token te genereren en die bij elk bericht van een als anoniem postende gebruiker te plaatsen. Ja maar dat is privacygevoelige informatie? Mwah... (in principe niet herleidbaar naar gebruiker want die is immers al anoniem. [...]
In theorie kan dat, en security.nl zou zelfs een cryptografische hash van die browser-fingerprint kunnen maken om die informatie "echt" te anonimiseren. En laten we ervan uitgaan dat de beheerders van security.nl te vertrouwen zijn.

Maar wat als je een willekeurige andere site bezoekt die wel browser-fingerprints van bezoekers verkoopt of publiceert, inclusief jouw IP-adres? Dan heeft die hash geen zin meer, want die kan iedereen dan opnieuw uitrekenen en vergelijken. Security.nl zou natuurlijk, via security by obscurity, een geheim aantal keren het hash-resultaat kunnen hashen (zoals ik hierboven ook doe), maar vroeger of later lekken de details van zo'n methode uit. Dat kan bijv. doordat een bezoeker van security.nl zelf gaat experimenteren met allerlei hash-combinaties, net zo lang tot zijn browser-fingerprint tot de door security.nl getoonde hash leidt.

Dit is precies het probleem bij het proberen te anonimiseren middels hashes: als je een specifieke input kunt voorspellen, of als je alle mogelijke inputs kent of kunt beredeneren, en het daarbij niet om gigantisch veel mogelijkheden gaat (geen hoge entropie dus), biedt het publiceren van slechts het resultaat van een cryptografische hashfunctie geen enkele privacybescherming (vandaar dat de randomness, lees onvoorspelbaarheid, van het uitgangsgetal in mijn TS-bijdrage zo belangrijk is - en je dus niet random.org moet gebruiken).

Zo is het hashen van telefoonnummers, IPv4-adressen en MAC-adressen "om de anonimiteit van de eigenaar te waarborgen" complete snake oil, want je kunt redelijk snel een tabel (bekend als rainbow table) maken van alle mogelijke waarden en de bijbehorende hash. En vervolgens kun je, gegeven een hash, heel snel de bijbehorende input opzoeken - weg anonimiteit.

Het enige, doch matige, wapen hiertegen zijn functies als Argon2, maar ook daarmee "gehashte" informatie wordt, na verloop van tijd, steeds makkelijker te "kraken". Desgewenst wil ik daar wel wat over schrijven.

Aanvulling: het stuk helemaal bovenin deze bijdrage was weggevallen, dat heb ik herschreven.
18-10-2019, 12:10 door fvandillen
Wordt een soortgelijk principe niet toegepast door sites als 4chan?
18-10-2019, 12:17 door Anoniem
Leuk bedacht. Als toevoeging zou ik willen suggereren de naam van het algoritme aan elke regel toe te voegen:

sha256:b041077eab986619c65a0957b4d76e72fa76afbfce683ec9d70d25bef243256b
sha256:d962565d8101e23de61a4db0a3373a2ad74577411d51cd211832dcde90f941ef
sha256:d60606f7d0d4aa5dfb9b1b4514fb1bcf9c6ef79807aeb5abc36198af297b8cec
sha256:e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178

Hieronder een implementatie in Python, waarvan (als je het onder de naam hashseq bewaart en uitvoerbaar maakt) het volgende commando bovenstaande uitvoer (maar dan met andere hashes) oplevert:

$ hashseq sha256:4
Als iemand de laatste regel in een eerdere post heeft gebruikt en nu de op een na laatste gebruikt, dan controleer je het zo:

$ hashseq sha256:d60606f7d0d4aa5dfb9b1b4514fb1bcf9c6ef79807aeb5abc36198af297b8ce
sha256:3d8330d919a81e4e3e55e34e38c08c8d60b535eb08e3692d3b67214458b34b5c

Hieronder de Python-code, die helaas NIET goed zal worden weergegeven omdat security.nl binnen de code-tag voorloopspaties platdrukt, en die zijn belangrijk in Python.

@REDACTIE: dit is doodeenvoudig te verbeteren, door in core.css, regel 1790, aan div.markup-config dit toe te voegen:
white-space: pre
Een monospace font is niet voldoende voor code.


Voor wie met de developer tools in browsers uit de voeten kan: je kan het daar voor de duur van de weergave van de pagina zelf toevoegen, zodat het goed wordt getoond.

#!/usr/bin/env python3
import sys
import os
import hashlib

CMD = os.path.split(sys.argv[0])[-1]
ALGOS = ', '.join(sorted(hashlib.algorithms_guaranteed))
DFLT = 'sha256'
HELP = f"""\
Genereert een reeks hashes, waarvan elke een hash van de vorige is, of
controleert een hash door op dezelfde manier de eerstvolgende te berekenen.

Aanroep:
{CMD} <aantal>
{CMD} <hash>
{CMD} <algo>:<aantal>
{CMD} <algo>:<hash>

Waarbij:
<algo> = het te gebruiken hashalgoritme
<aantal> = het aantal hashes dat moet worden gegenereerd
<hash> = een te controleren hash

De hashes worden in de vorm <algo>:<hash> naar stdout geschreven.

Beschikbare algoritmes: {ALGOS}

Defaultalgoritme: {DFLT}
"""

def parse(args):
if len(args) != 1:
sys.exit(HELP)
items = args[0].split(':', maxsplit=1)
algo = DFLT
if items[0] in hashlib.algorithms_guaranteed:
algo = items[0]
items = items[1:]
if items and items[0].isdecimal():
count= int(items[0])
start = hashlib.new(algo, os.urandom(512)).hexdigest()
elif items[0]:
start = items[0]
count = 1
else:
start = hashlib.new(algo, os.urandom(512)).hexdigest()
count = 50
return algo, start, count

def get_hashes(algo, start, count):
hsh = start
for i in range(count):
hsh = hashlib.new(algo, hsh.encode()).hexdigest()
yield hsh

def main():
algo, start, count = parse(sys.argv[1:])
for hsh in get_hashes(algo, start, count):
print(f'{algo}:{hsh}')

if __name__ == '__main__':
main()
En natuurlijk even ondertekenen:
sha256:b88bf8144c60616ae29de39e0deba5279c10ee32edf797f108b0bb1aa1c26cae

Ik beloof niet dat ik dit vol ga houden, maar het is leuk om er even mee te spelen ;-)
18-10-2019, 12:43 door Anoniem
TL;DR

Al mijn bijdrages zijn al uniek. ;)
18-10-2019, 13:01 door Anoniem
Door Erik van Straten:
Door Anoniem: [...] Inloggen met een wachtwoordmanager is sneller dan een tekstbestand wijzigen. Ik denk dat de mensen die even snel iets plaatsen geen " crypto " backlog gaan aanleggen. [...]
Zoals ik schreef, ik verwacht niet dat dit opgevolgd gaat worden (in elk geval niet massaal). Maar wie weet heeft iemand er een slimme toepassing voor. Zoals een dissident die met een journalist communiceert en anoniem wil blijven, maar waarbij er bij de journalist geen twijfel mag bestaan dat het steeds om dezelfde dissident gaat.

Dan is meteen bekend dat die dissident op security.nl zit ;) Ergens anders ben ik deze truuk nog niet tegengekomen.



Ik realiseer me dat dissidenten in sommige landen terrroristen worden genoemd; je kunt dit soort technieken goedschiks en kwaadschiks gebruiken. Maar ook dit is een voorbeeld van dat je cryptografie niet moet willen backdooren om "boeven te kunnen vangen", want die boeven maken dan hun eigen protocollen wel (dat is doodsimpel zoals je hierboven lezen), terwijl brave burgers het -enorme- risico lopen dat de sleutel van de backdoor in de door hen gebruikte software/hardware in verkeerde handen valt.

Het valt aan te bevelen om dit soort methodes altijd te gebruiken, ook voor mensen die paranoide zijn en wat gemoedsrust willen, voor ICT'ers die met mensen communiceren over niet betrouwbare platformen (smartphone) of platformen die suspectible zijn aan MiTM attacks bijv. door staten die zich bedienen van Entrapment (dichter bij als je denkt) bijv SMTP wat gewoon plaintext is. Als je de originele email weet tegen te houden met een client-site error aan deze of de andere kant dan kun je een gemodificeerde mail op de originele tekst (of variant ervan) spoofen. De mogelijkheden zijn eindeloos. Zo'n checksum verificatie systeem zou eigenlijk iedereen moeten gebruiken.

Door Anoniem: [...] Ik raad een account aan. [...]
Waarom post je dan anoniem?
[/quote]
Makkelijk toch? Ik ben niet zo bezig met wie wat schrijft hier op de site maar ik kan mij voorstellen dat het zeer vervelend is voor vaste gebruikers. Alle disinfo en kinderlijke reacties daar weet ik inmiddels wel doorheen te prikken.

Bovendien is een accountje zo gemaakt ook door spammers. Iemand die zijn integriteit hoog in het vaandel heeft zal inderdaad zo'n hashfunctie gebruiken in posts eventueel in combinatie met account.

Er zullen zeker enkele mensen op security.nl wakker zijn nu en een hashfunctie gaan toepassen in de posts. Dit idee werd al toegepast op moderne BBSen waar de gebruiker bij het posten een wachtwoord opgeeft via een HTML form input functie. De php van de site genereerde dan de hash. Deze hashes en tripcodes kunnen wel gekraakt worden, zeker door inlichtingendiensten met rekencapaciteit. Het beste blijft daarom een combinatie van methodes.

Niet alleen voor dissisenden maar ook de mensen die ongeterecht worden getarget door de groeiende private (minder met regeltjes en wetten) surveillanceindustrie. Dat wordt alleen maar meer in de toekomst. Ik val in die laatste categorie. Misschien moet ik zelf maar een bedrijfje opzetten in de surveillance, de truuks ken ik inmiddels al en ik kan gaan oefenen op wie mij target, zeg maar de concurrent van mijn nog niet bestaande eigen toko. Volgens mij valt hier goed in te verdienen.

Door Anoniem: Je kunt ook gewoon een account aanmaken.
Gegeven een TS-bijdrage waarin staat: "In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken". Dan kun je die tekst natuurlijk niet lezen en toch menen iets zinvols aan de discussie bij te dragen met jouw post. Om niet te worden uitgelachen door mensen die weten wie jij echt bent, kun je zoeits inderdaad maar beter anoniem doen. De kans dat jouw bijdrage gelezen wordt is dan trouwens ook groter (van trollen met een account weten serieuze bezoekers van security.nl meteen welke bijdragen ze kunnen overslaan).
[/quote]
Er is nog een reden om het niet te doen voor sommige mensen: Aan de hand van de hashfuncties in posts kun je een volledig profiel van de historie van iemand opbouwen. Die tekst kun je laten analyseren en met ML learning laten fingerprinten. Er ontstaat dan een digitale vingerafdruk van jouw grammatica en vocabulair waarmee je dus een deel van je privacy verliest.


In theorie kan dat, en security.nl zou zelfs een cryptografische hash van die browser-fingerprint kunnen maken om die informatie "echt" te anonimiseren. En laten we ervan uitgaan dat de beheerders van security.nl te vertrouwen zijn.

Dat is leuk, dan kan de site bezoekers meteen vertellen wanneer ze een onveilige browser hebben met tips op een doorklikpagina.


Zo is het hashen van telefoonnummers, IPv4-adressen en MAC-adressen "om de anonimiteit van de eigenaar te waarborgen" complete snake oil, want je kunt redelijk snel een tabel (bekend als rainbow table) maken van alle mogelijke waarden en de bijbehorende hash. En vervolgens kun je, gegeven een hash, heel snel de bijbehorende input opzoeken - weg anonimiteit.

Een hacker kan zich ook toegang verschaffen tot jouw systeem of router of smartphone (waarschijnlijk het makkelijkst) en vanaf de shell een python scriptje draaien om ergens iets te posten of een site te pingen en voila jij bent het geweest.


Het enige, doch matige, wapen hiertegen zijn functies als Argon2, maar ook daarmee "gehashte" informatie wordt, na verloop van tijd, steeds makkelijker te "kraken". Desgewenst wil ik daar wel wat over schrijven.

Ik was met rainbow tables bezig toen ik een tiener was, toen bestonden rainbow tables nog niet. Ik bedacht het voor een functie waarvoor alleen maar CPU-kraakprogramma's waren maar met de processoren van toen (286 386) duurde het uren of dagen. Zo'n hash betrouwbaar genoeg voor het opslaan van wachtwoorden (ja gehashte wachtwoorden opslagen gebeurde toen al).

Aanvulling: het stuk helemaal bovenin deze bijdrage was weggevallen, dat heb ik herschreven.

Dan ga ik dat nog eens opnieuw lezen. En dat is meteen het voordeel van een account.

Nog een nadeel van zo'n hashfunctie in posts op deze site of elke ander forum is dat het zinloos is als de beheerder of een moderator onbetrouwbaar heeft of als iemand toegang heeft tot de database. In dit geval kan de content van jouw bijdragen worden gewijzigd maar met jouw hash eronder. Het werkt dan averechts want iedereen zal zeggen dat jij die ene post hebt geschreven omdat jouw hash eronder staat. Jij kunt die post niet meer aanpassen. Met een account zit je toch altijd beter, je kunt altijd nog oude posts editen en corrigeren.
18-10-2019, 13:24 door Anoniem
Door fvandillen: Wordt een soortgelijk principe niet toegepast door sites als 4chan?

Ja. Zij werken met tripcodes. De worden om de haverklap gehacked. Alleen de eerste 6 of 8 karakters zijn gehashed. Het komt op hetzelfde neer als de hier voorgestelde sha,md5 hashes. Voor deze heb je alleen zware rekenkracht nodig en dan heb je alleen de volgende opstakels:

- inlichtingendiensten met een dedicated hash crack service/server rack voor hun personeel

- zware hackers met teveel geld die een station hebben met honderden terabytes aan rainbowtables (een mini versie van voorgenoemde)

- het risico dat een moderator of hacker toegang heeft tot databases of posts en deze kan editen (op elk board of forum zoals phpbb en vbulletin kan een moderator de INHOUD van posts veranderen) dus dan zegt zo'n hash niets over de consistentie van de posts

Zelf neem ik niemand serieus die geen PGP gebruikt. Eventueel in combinatie met AES-Twofish of een andere cipher in cascade. Het probleem bij die laatste is dan wel de leesbaarheid van je geposte data want die moet je ontsleutelen. Dan moet je een Javascript ECB/CBC implementatie gebruiken zoals in [1]. PGP kun je in signfunctie gebruiken, dan hoeft de overheid niet te zeggen "wij kunnen je niet lezen" maar dan kun jij wel zeggen "de integriteit van mijn mails zijn redelijk betrouwbaar", moet je je private key natuurlijk niet opslaan op een PC met internet toegang of bij je provider. Zo kunnen ze de terrorisme / pedo kaart niet spelen en kun jij nog vertrouwen op de infrastructuur. Het is jammer dat zo weinig mensen gebruik maken van PGP. In de jaren 90 was dit heel populair op Usenet. In een HTML omgeving vind men dit blijkbaar niet schoon meer, wat een estetische kwestie is maar juist in HTML kun je board software ontwerpen waarbij de PGP headers van een "reaguurder met kennis van zaken" standaard worden weggepoetst totdat je op een HTML knopje drukt om de volledige tekst (met headers) te downloaden voor offline verificatie door jezelf - of nog een balkje op de forum software die aangeeft [deze post bevat pgp: signatuur oke/niet okee]. Als ik een forum zou ontwerpen zou ik voor dit laatste kiezen. Het is een kwestie van de bestaande php van een forum aan te passen, met een sed functie de PGP headers te identificeren en strippen voor het leesmgemak en als deze er zijn even lokaal op de server te verifieren met een groen/rood indicator bij elke post en eventueel de optie om de volledige source te downloaden. Een paar uurtjes sleutelen en je bouwt een forum om tot PGP grade integrity. Een aparte upload.php voor de keys (eenmalig) is binnen minuten gecodeerd.


[1] https://github.com/wouldgo/twofish
18-10-2019, 13:48 door Anoniem
Oke, even in het kort. Ik denk dat dit voor security.nl een primeur kan zijn als zij dit willen coden. Maar je kunt zelf ook vbulletin aanpassen.

PGP op een forum? Waarom niet. Dit moet je doen:


1. PGP sleutels uploadbaar via security.nl/uploadkey.php en die via system() of passthru() laten importeren in de serverside PGP database. 20 regels php code of minder met alle validaties en checks


2. In de php van /posting of waar die rewrite rule voor staat elke post nalopen op PGP content (boolean aan) en de "rommel" strippen (-----BEGIN PGP MESSAGE----- de header en footer). Ik heb al 100 jaar geen php gecode maar dit zullen een paar regeltjes zijn.


3. De inhoud van de user post sanitizen en wegschrijven naar een bestand, en via passthru(pgp..) laten checken. Output in verify-boolean.


4. Aan de HTML in /posting/<postid> naast "Vandaag, Door Anoniem, 12:00" in tekst of kleurtje de output van de if-pgp en pgp-verifiy boleans verwerken. bijv. "Vandaag, Door Anoniem, 12:00 met PGP-VERIFIED".


5. Dit is in een uurtje in elkaar geklopt maar je wilt waarschijnlijk punt 3 voor snelheid bij het posten al doen en niet bij het opvragen / elke HTML request of F5 hoewel dat laatste veiliger is maar dat hangt af van hoe low traffic je forum is.


Dit is beter dan md5 of sha hashes. De user blijft anoniem. De key upload je 1x. De in weergave gestripte headers kun je in de HTML gewoon <!-- wegcommenten --> zodat zelfs de paranoide eindgebruiker nog manueel kan verifieren. Je bent niet afhankelijk van de integriteit van databases of moderators (want dan krijg je "Vandaag, Door Anoniem, 12:00 met PGP-FAILDED") en je forum krijgt bling bling... er is nog geen forum die dit doet terwijl het een simpel concept is.

Hashtags, tripcodes is uit lang vervlogen tijden. Daar moet je geen waarde aan hechten.

Misschien denkt de moderator hier wel, wat een cool projectje voor een winteravond. Een primeur voor deze site als toonbeeld van professionaliteit en security op forumgebied, als voorbeeld voor andere fora.

Zoals ik al zei was het op Usenet heel gebruikelijk maar op HTML forums worden de signatures niet op prijs gesteld want rommel. Heel stom want juist in HTML kun je makkelijk filteren met een "show/noshow" knop.

Het is maar een idee.

[1] https://www.quora.com/What-is-a-PGP-signature?share=1
18-10-2019, 14:09 door Anoniem
Door Erik van Straten: Af en toe, zo ook in [1], is er op security.nl onduidelijkheid of een anonieme bijdrage van de hand van dezelfde persoon is als een eerdere anonieme bijdrage.

Met dit algoritme kun je, met flinke zekerheid, bewijzen dat jij nog steeds dezelfde jij bent (tenzij iemand anders zo'n tekstfile in handen krijgt, jouw eerste random getal voorspelbaar bleek te zijn [*], of de moderator c.q. een hacker van security.nl jouw hashes -of juist de tekst in jouw bijdragen- wijzigt). En dit algoritme is -hoogstwaarschijnlijk- nog quantum-proof ook!

Ik vraag mij af of dit een verkapte vorm is van "tracking-opties" verkopen (promoten) op deze site. Dan vraag ik mij af met wel doel in zicht.

Iemand die anoniem wenst te blijven zal echt geen hash aan zijn posts toevoegen want dan is het niet meer anoniem. Iemand die Tor gebruikt of een VPN zal door te gebruik te maken van zo'n hash juist minder anoniem zijn omdat je verifieerbare (=indirect herleidbare) informatie plaatst op internet.

Daarbij is ook deze methode niet bestand tegen manipulatie, zeker door mensen met toegang tot krachtige computers.

Dit zou alleen iets zijn voor die 4 individuen (JO, luntrus, #sockpuppet, Jodocus Oyevaar) die geen account hebben maar wel impersonatie willen tegengaan als alternatief voor een inlog. Het lijkt me een leuke gimmick (tevens trackingtool) voor alternatieve denkers.

Dan sluit je gewoon zo af:

Maar het was wel een creatief voorstel!


Gr. Piet md5 6046ed57b742d0dca8504cecd0c0b03b
18-10-2019, 14:11 door Erik van Straten
Door fvandillen: Wordt een soortgelijk principe niet toegepast door sites als 4chan?
Ik doe niks met 4chan, maar als ik https://www.4chan.org/faq#trip en "secure tripcode" daaronder goed begrijp, werken beide mechanismes anders. Maar dank voor de tip, het zou me niets verbazen als zoiets allang wordt toegepast!
18-10-2019, 14:36 door Anoniem
Af en toe, zo ook in [1], is er op security.nl onduidelijkheid of een anonieme bijdrage van de hand van dezelfde persoon is als een eerdere anonieme bijdrage.

In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken, maar kennelijk wil niet iedereen dat en bovendien is zelfs dan nog verwarring mogelijk... (als ik me goed herinner was er op deze site ooit een account genaamd karrna4 of iets dergelijks, waar ik aanvankelijk intrapte).

Je kunt ook gewoon de keuzes van andere mensen respecteren. In plaats van dit soort gezeur.
18-10-2019, 14:47 door Anoniem
Door fvandillen: Wordt een soortgelijk principe niet toegepast door sites als 4chan?

Binnen 5 uur te kraken door mensen met een degelijke GPU.

https://www.betterbuys.com/estimating-password-cracking-times/assets/images/password_time_and_length.jpg

Leuk om te weten:

https://www.betterbuys.com/estimating-password-cracking-times/

De zwakheid in md5 hashes bijvoorbeeld is dat je in tegenstelling tot een wachtwoord (website login met a-z, A-Z en leestekens) beperkt bent tot 0-9 en a-f dus 16 combinaties maar wel 16^31 en dat is nog best veel.

Collusions zijn een zeer klein risico omdat een collusion achteruit in de tijd gaat en dus stopt (er worden forward hashes gegenereert in dit voorstel). En de kans dat een collusion ook net een md5 sum (hexdec 31 chars) is zeer klein.

Dan weet ik niet of je iets kunt met cryptonanalysis van iteraties van forward md5 sums die steeds op elkaar gebaseerd zijn, als je er veel van kunt verzamelen.

Misschien kan een cryptoloog hier wat meer over vertellen?

Ik zou het idee in elk geval niet gebruiken voor internet sites.
18-10-2019, 15:03 door Anoniem
Beste Erik,

Ik vind het niet een heel gek idee, al is wel wat gedoe.
Maar het is misschien ook niet verkeerd om vooral voor anonieme posters een iets hoger drempeltje te leggen?
Wat dat betreft is het net als met email: hoe gemakkelijker en goedkoper het is, des te meer wordt er mee gespamd.

Dus elke anoniem die anoniem wil blijven maar wel wil aantonen dat zijn/haar eventuele vervolgposts (in dezelfde thread)
werkelijk van hem/haar zijn, zou van www.security.nl een zootje opeenvolgende SHA256-hashes moeten krijgen
(van een rij random bytes van voldoende lengte die door www.security.nl wordt gegenereerd)
om er mee te kunnen posten zoals jij voorstelt? (waarbij security.nl dus de SHA256-hash gaat vragen i.p.v. capcha)

Het blijft dan overigens wel mogelijk om na iedere post meteen weer een nieuw zootje hashes aan te vragen, zodat deze relatie tussen posts niet kan worden gelegd. Echter deze zijn gemiddeld genomen minder betrouwbaar,
want voor de wat serieuzere posters lijkt mij dat er niet echt reden is om bezwaar te hebben dat bepaalde posts in een thread aantoonbaar van dezelfde anoniem zijn.

In dit geval is de capcha dus alleen nog nodig voor de aanvraag van een nieuw rijtje SHA256 -hashes,
omdat zonder ingave van een ongebruikte uitgegeven SHA256-hash (die bovendien onderaan het bericht voor iedereen leesbaar en controleerbaar zal verschijnen), een bericht bijv. automatisch door www.security.nl genegeerd.
18-10-2019, 15:40 door Anoniem
Ik zal hier, speciaal voor de kleine Fabeltjeskrant kijkbuiskinderen onder ons, iets uit de vroege begintijd van het Wilde westen op internet willen laten zien. Want zie hier, opgediept uit stoffige archieven van de Wikipedia:

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1

Vroeger zetten de echte Geeks op sommige USENET groepen hun digitale handtekening met een zogeheten PGP-signature, om de leesbare postings van een verifieerbaar ID te voorzien, maar die goede gewoonte in op webbased fora helaas uit de gratie geraakt.

De groeten,

Nick

GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N+++ o+ K+++ w---
O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++
G+++++ e++ h r-- y++**
------END GEEK CODE BLOCK------

https://en.wikipedia.org/wiki/Geek_Code

De bovenstaande GEEK-code block is hier getoond als een parodie op het wat meer bekende PGP-code block, dat in dit voorbeeld een leesbaar en "ondertekend" bericht bevat. De oplettende lezer hier zal hebben opgemerkt dat ik Robert A. Hayden's oorspronkelijke GEEK-code block voor dit doel opzettelijk heb verminkt, om het hele punt te illusteren.

De voorgestelde nick hashes hebben namelijk geen omvattend code block voor de tekst die er tussen staat. De echtheid van de uiting van de schrijver van het bericht valt dan, zeker bij gebrek aan een aan een account te koppelen public key, niet met zekerheid te verifieren. Maar goed, dat beseft Van Straten ook wel :-) Nu nog een goede uitwerking van het idee.
18-10-2019, 15:46 door Anoniem
Het vervelende is dat je zo'n tekstbestand wel PER TOPIC moet bijhouden en dan nog gaat het de mist in als een
moderator besluit je bijdrage niet te accepteren.
18-10-2019, 16:04 door Anoniem
Door Erik van Straten: In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken, maar kennelijk wil niet iedereen [...]

Sommige van mijn collega's zouden hier best onder hun eigen naam of pseudoniem willen schrijven, alleen kunnen ze van hun inkomen helaas geen advocaat, kogelwerend vest en een 24/7 lijfwacht betalen. Bovendien, hun werkgever of detacheerder ziet het liever niet dat de hele buitenwereld weet waar ze in hun vrije tijd vertoeven.

Tot die tijd is het gebruik van een pseudoniem, met daarachter een ProtonMail.com account, alleen via Tor, misschien verstandiger om mee te beginnen. Ik houd het daarom voorlopig bij "Anoniem", zonder een opeenvolgende reeks hashes. Dat neemt niet weg dat ik het wel een goed idee vind.
18-10-2019, 16:39 door Erik van Straten
Dank voor alle reacties, het wordt weer leuk en leerzaam op security.nl!

Ik probeer dit weekend op e.e.a. inhoudelijk te reageren, maar alvast een tip voor o.a. de Python coders: ik wist al dat je met Alt-255 (Alt ingedrukt houden en 255 tikken op je numerieke toetsenbord) een non-breaking space kon maken (zie onderaan http://ascii-table.com/ascii-extended-pc-list.php).

Omdat ik op dit moment bezig ben met een project waarvoor ik in andere charsets dan ASCII moest duiken, heb ik het e.e.a gelezen over UTF-8. Via-via kwam ik op het idee om eens in Wordpad.exe (W10) te kijken wat er gebeurt als je daar Alt-255 gebruuikt: dat gaat prima! Je kunt de ASCII sourcecode eenvoudig copy-pasten in Wordpad (en desgewenst regelafstand en lettertype aanpassen), en dan alle reeksen van (bijvoorbeeld) 4 spaties zoeken en vervangen door 4 maal Alt-255 (dan hoef je die combinatie maar 4 x in te tikken ;-).

Alsvoorbeeld een kopie van een stukje python hierboven, nu indented (maar ik weet niet zeker of alle regels, zoals 09, de juiste indent hebben):
01 def parse(args):
02     if len(args) != 1:
03         sys.exit(HELP)
04     items = args[0].split(':', maxsplit=1)05
06     algo = DFLT
07     if items[0] in hashlib.algorithms_guaranteed:
08         algo = items[0]
09     items = items[1:]
10     if items and items[0].isdecimal():
11         count= int(items[0])
12         start = hashlib.new(algo, os.urandom(512)).hexdigest()
13     elif items[0]:
14         start = items[0]
15         count = 1
16     else:
17         start = hashlib.new(algo, os.urandom(512)).hexdigest()
18         count = 50
19     return algo, start, count

Ik weet niet of bijv. Notepad++ ook met dit soort codes kan werken, zelf gebruik ik een eenvoudiger teksteditor en die kan het niet (Wordpad is -tot nu toe- echter op elk Windows systeem aanwezig).
18-10-2019, 16:49 door Anoniem
Door Superuser: 18-10-2019, 08:32 Voor security.nl zou het een kleine moeite zijn om met de on-line fingerprint v.e. gebruiker (ip-adres, browser id, os, patronen in muis- en toetsenbordgebruik, etc.) een uniek token te genereren en die bij elk bericht van een als anoniem postende gebruiker te plaatsen.

Afkomstig van een ander ontspoort topic:

https://www.security.nl/posting/628127/Re%3A+Sudo+rechten+geven+en+schade+beperken


Het openbaar loggen van IP-adressen, zeker met bijbehorende webbrowser fingerprinting, is een bijzonder heet hangijzer. Dat hoef ik jou als superuser niet uit te leggen. Dat gaat hier echter niet werken, omdat veel van de anonieme bezoekers op Security>NL, zo vermoed ik, vanaf wisselende fysieke locaties werken of vaak Tor-exits, of zelfs I2P-routers met verborgen web-gateways, gebruiken. Hoe denk je die postings te traceren?

Zo'n opzet zou dan een grote brij van praktisch niet te traceren hash-IDs opleveren, waar voor de forum lezer geen enkel touw aan vast te knopen is. Dat temidden van een kritisch en technisch onderlegd forum publiek, dat toch al tot het gebruik van te veel afkortingen neigt. Vergeet het. Zo'n chaotische indruk schrikt zeker een breder publiek van geinteresseerden af.
18-10-2019, 17:08 door Anoniem
Door Erik van Straten: Ik probeer dit weekend op e.e.a. inhoudelijk te reageren, maar alvast een tip voor o.a. de Python coders: ik wist al dat je met Alt-255 (Alt ingedrukt houden en 255 tikken op je numerieke toetsenbord) een non-breaking space kon maken (zie onderaan http://ascii-table.com/ascii-extended-pc-list.php).
Maar dan is het weer geen geldige Python-syntax.

Alsvoorbeeld een kopie van een stukje python hierboven, nu indented (maar ik weet niet zeker of alle regels, zoals 09, de juiste indent hebben):.
Nee, dat klopt niet. Je kan de juiste indentatie oppakken door "Reageer met quote" te kiezen en vanuit de quote in het teksveld te kopiëren en te plakken. De spaties staan er op zich in, het is alleen dat ene ontbrekende regeltje in de stylesheet van security.nl dat het verknalt.

sha256:74bdc57548187b0a183620f50fec8ff7c6e51f2796f56b19298ba8bf8f2cadbd ;-)
18-10-2019, 18:25 door Anoniem
Zeer handig en overal inzetbaar systeem met dank aan TS.

Handig ook voor emails, als je geen zin hebt om elke mail te signeren.

Handig voor ticketsystemen, om de consistentie en volgorde van berichten te toetsen.

Dit systeem kun je ook in gewone correspondentie toepassen. Het is maar 1 regel. Brieven op papier kun je niet signeren met PGP. Deze code kun je zelfs inkorten door de juiste hashfunctie te nemen en als Intern Kenmerk gebruiken bij correspondentie.
18-10-2019, 18:27 door Anoniem
Een van de betere bijdragen op deze community in tijden.
18-10-2019, 19:19 door Anoniem
Men zou in het Python script de reeks van gegenereerde hashes optioneel van een nickname, volgnummer en het gebruikte checksum algoritme kunnen voorzien, bijvoorbeeld in het volgende formaat:

nick:seed:sha256:b041077eab986619c65a0957b4d76e72fa76afbfce683ec9d70d25bef243256b
---------------------------------------------------------------------------------
nick:0003:sha256:d962565d8101e23de61a4db0a3373a2ad74577411d51cd211832dcde90f941ef
nick:0002:sha256:d60606f7d0d4aa5dfb9b1b4514fb1bcf9c6ef79807aeb5abc36198af297b8cec
nick:0001:sha256:e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178

Met een volgnummer kan bepaald worden dat een opeenvolgende anonieme posting, van dezelfde persoon of entiteit, uit de gegenereerde reeks van hashes mist, bijvoorbeeld vanwege een storing, een weigering van plaatsing of verwijdering door de redactie. Wat een logische verklaring kan zijn voor het falen van een checksum.

Dat past allemaal nog net op 1 regel in de venster breedte onder de Tor Browser. Een vast datum stempel er bij zetten wordt wel erg krap. Het seed moet natuurlijk wel geheim blijven, maar ik kan mij niet voorstellen dat iemand in zijn eentje op Security.NL meer dan 9999 opeenvolgende gehaste postings in één en hetzelfde topic wil gaan plaatsen. Hoewel?
18-10-2019, 23:54 door Anoniem
Ik ben ook anoniem hoor.
18-10-2019, 23:58 door Anoniem
Mijn eerste post op deze website.


@b88bf8144c60616ae29de39e0deba5279c10ee32edf797f108b0bb1aa1c26cae

Ik krijg de error:


root@kali:~# python3 test.py
File "test.py", line 32
if len(args) != 1:
^
IndentationError: expected an indented block


Ik ben geen programmeur dus los ik anders op voor hetzelfde resultaat.
In 1 regeltje in bash:


txt=wachtwoord; aantal=20; c=0; while [ $c -le $aantal ]; do txt="`echo \"$txt\"|sha256sum --tag|cut -d \" \" -f4`" ; echo $txt >> output.txt; c=$(($c+1)); done

dit genereert een output.txt met 20 opeenvolgende sha256 hashes gebaseerd op "wachtwoord"
en nog een regeltje voor een leesbaar format:


for i in `cat output.txt`; do echo "Alias - sha256:$i">>output2.txt; done

Wie mijn wachtwoord kraakt mag me een baan aanbieden ;)

Ik genereer er bijvoorbeeld 1000 offline en dan room ik af, die zet ik op de pc met internet toegang. Bij een hack heb je zo nog altijd de eerste sleutels.


Koos - sha256:ac6010ad37f676a8ec185fb48e8a5cbc77408f96dbaf81388f11f0d734495b75
19-10-2019, 06:13 door [Account Verwijderd] - Bijgewerkt: 19-10-2019, 06:29
Door Anoniem:
Door Superuser: 18-10-2019, 08:32

Het openbaar loggen van IP-adressen, zeker met bijbehorende webbrowser fingerprinting, is een bijzonder heet hangijzer. Dat hoef ik jou als superuser niet uit te leggen. Dat gaat hier echter niet werken, omdat veel van de anonieme bezoekers op Security>NL, zo vermoed ik, vanaf wisselende fysieke locaties werken of vaak Tor-exits, of zelfs I2P-routers met verborgen web-gateways, gebruiken. Hoe denk je die postings te traceren?

Als je mijn volledige bijdrage had gepost dan had iedereen kunnen zien dat dit er zelfs al - relativerend - bij staat.

https://www.security.nl/posting/626870#posting628127
19-10-2019, 06:23 door [Account Verwijderd] - Bijgewerkt: 19-10-2019, 06:25
Door Erik van Straten: Uit https://www.security.nl/posting/626870/Sudo+rechten+geven+en+schade+beperken#posting628127:
18-10-2019, 08:32 door Superuser: [...] Voor security.nl zou het een kleine moeite zijn om met de on-line fingerprint v.e. gebruiker (ip-adres, browser id, os, patronen in muis- en toetsenbordgebruik, etc.) een uniek token te genereren en die bij elk bericht van een als anoniem postende gebruiker te plaatsen. Ja maar dat is privacygevoelige informatie? Mwah... (in principe niet herleidbaar naar gebruiker want die is immers al anoniem. [...]
In theorie kan dat, en security.nl zou zelfs een cryptografische hash van die browser-fingerprint kunnen maken om die informatie "echt" te anonimiseren. En laten we ervan uitgaan dat de beheerders van security.nl te vertrouwen zijn.

Maar wat als je een willekeurige andere site bezoekt die wel browser-fingerprints van bezoekers verkoopt of publiceert, inclusief jouw IP-adres? Dan heeft die hash geen zin meer, want die kan iedereen dan opnieuw uitrekenen en vergelijken. Security.nl zou natuurlijk, via security by obscurity, een geheim aantal keren het hash-resultaat kunnen hashen (zoals ik hierboven ook doe), maar vroeger of later lekken de details van zo'n methode uit. Dat kan bijv. doordat een bezoeker van security.nl zelf gaat experimenteren met allerlei hash-combinaties, net zo lang tot zijn browser-fingerprint tot de door security.nl getoonde hash leidt.

Dit is precies het probleem bij het proberen te anonimiseren middels hashes: als je een specifieke input kunt voorspellen, of als je alle mogelijke inputs kent of kunt beredeneren, en het daarbij niet om gigantisch veel mogelijkheden gaat (geen hoge entropie dus), biedt het publiceren van slechts het resultaat van een cryptografische hashfunctie geen enkele privacybescherming (vandaar dat de randomness, lees onvoorspelbaarheid, van het uitgangsgetal in mijn TS-bijdrage zo belangrijk is - en je dus niet random.org moet gebruiken).

Zo is het hashen van telefoonnummers, IPv4-adressen en MAC-adressen "om de anonimiteit van de eigenaar te waarborgen" complete snake oil, want je kunt redelijk snel een tabel (bekend als rainbow table) maken van alle mogelijke waarden en de bijbehorende hash. En vervolgens kun je, gegeven een hash, heel snel de bijbehorende input opzoeken - weg anonimiteit.

Het enige, doch matige, wapen hiertegen zijn functies als Argon2, maar ook daarmee "gehashte" informatie wordt, na verloop van tijd, steeds makkelijker te "kraken". Desgewenst wil ik daar wel wat over schrijven.

Een andere site weet natuurlijk niet welke inputs security.nl zou gebruiken en hoe die gecombineerd zouden worden. Desondanks blijft het inderdaad security by obscurity en - inderdaad - als de geanonimiseerde gegevens ooit op straat zouden komen te liggen, dan heb je de privacypoppen aan het dansen.
19-10-2019, 13:39 door Anoniem
Door Superuser: Als je mijn volledige bijdrage had gepost dan had iedereen kunnen zien dat dit er zelfs al - relativerend - bij staat.

Voor een slechtziende of blinde, die werkt met een braille regel, valt een lopende discussie een stuk eenvoudiger te bevatten als je je in het vervolg bij het "quoten" beperkt, tot alleen de voor je betoog relevante tekst passages.Voor de wel goed zienden onder ons is dat te aanschouwen beeld dan vast ook een veel prettiger aanblik. Hartelijk dank :-))
19-10-2019, 18:00 door Anoniem
1984 on steroids leuke tijden zijn het

Zijn er nog van die plaatsen waar dat je anoniem mag reageren Is het nog steeds niet goed

Moeten we echt overal gevolgd worden ?
19-10-2019, 19:02 door Anoniem
Door Anoniem: 1984 on steroids leuke tijden zijn het

Zijn er nog van die plaatsen waar dat je anoniem mag reageren Is het nog steeds niet goed

Moeten we echt overal gevolgd worden ?

Privacy en security concepten a.u.b. niet verwarren. Je houdt zo inderdaad een tracklog bij (misschien ook handig voor je eigen administratie). Het idee achter deze hash signature is dat je kunt bewijzen dat een post van jou is. Het maakt impersonatie alweer wat moeilijker, afhankelijk van wie je adversary is :)

Koos - sha256:4abd67d0d660ca3609122e04147423d3dbfa8987951550bff4045713e36d2cd5
19-10-2019, 19:15 door Anoniem
Wel een punt. Met dit systeem moet je integriteit van berichten op fora met een korrel zout nemen. Bij elk forumpakket wat ik tot nu toe gezien heb kunnen moderatoren de inhoud van berichten (achteraf) aanpassen. Je moet dus maar op vertrouwen dat een moderator of systeembeheerder nooit corrupt zal worden. Het is natuurlijk geen PGP sig over je post.

Koos - sha256:804f969651a8e9ef78acc0b2d9bb5b92f26c81c33562bb5c444ff859516e4096
19-10-2019, 22:34 door Anoniem
Volgens mij kan het een stuk eenvoudiger, zonder hash-gereken en minder werk:

Bijv. elke anoniem die wil reageren zou van security een unieke willekeurige string kunnen krijgen, die de anoniem lokaal onthoudt (bijv. opslaat met copy-paste). Deze string is een beperkte periode geldig (bijv. 3 maanden) voor alle topics,
en verschijnt voor security.nl-lezers niet in beeld, zodat alleen de betreffende anoniem en de server van security.nl de string kennen. Security.nl slaat deze string dus op, zodat legitieme uitgegeven strings kunnen worden terugherkend.

Is de geldigheidsperiode van een string verstreken, dan worden ze van de server gewist, en moet de anonieme poster gewoon weer even een nieuwe string opvragen en onthouden door deze lokaal op te slaan.
De oude string kan dan worden vergeten.
(Het doel van een geldigheidsduur is dat het aantal uitgegeven strings die de database vult op den duur niet uit de klauwen gaat lopen)

Het proces gaat dan verder als volgt:
1. een anoniem wil reageren, flanst zijn post in elkaar, vult de capcha in, en klikt op "reageren"
2. het systeem van security.nl herkent dat het geen geregistreerde gebruiker is (dus anoniem) en vraagt zijn unieke string.
3. de anoniem vult zijn unieke string in (copy-paste) en klikt ter bevestinging op een nieuwe knop "zend string" o.i.d.

4a. Vervolgens test nog te schrijven software op security.nl of het om een legitieme string gaat.
Zo niet, dan krijgt de gebruiker max. 3 kansen om de string opnieuw in te geven.
Na de derde keer wordt de post geweigerd en gewist en gaat men terug naar af.
4b. Blijkt de opgegeven string geldig, dan gaat de programmatuur op security.nl eerst na of deze anoniem al eerder had gereageerd in deze zelfde thread/topic. Het is hier de bedoeling dat op de security.nl server door de te ontwikkelen software per topic wordt bijgehouden welke anonieme "strings" er hebben gereageerd, door per topic hun unieke strings op te slaan samen met het aan hen toegekende anoniemvolgnummer. Aan elk topic/thread kleeft dus een databeesje van strings van anoniemen er hadden gereageerd, samen met het hun toegekende Anoniemvolgnummer in die topic/thread.

Per topic wordt de eerste anoniem die reageert automatisch "anoniem_"1 , de tweede (andere) anoniem_2, etc.
Er verschijnt dan bijv. in de grijze balk (die niet door gebruikers is te vervalsen): " Vandaag, 19:15 door Anoniem_3".
wanneer het gaat om de derde nieuwe anoniem die in dit topic had gereageerd.
Reageer deze anoniem later nog eens in hetzelfde topic, dan herkent de software die moet worden geschreven
dat je in deze thread al eens eerder had gereageerd, en dus "Anoniem_3" bent in deze topic/thread.

In dezelfde topic/thread blijf je dan dus steeds Anoniem_3 voor alle berichten die je in die thread post.
Maar reageer je in een andere thread, dan kan je daar bijv. best Anoniem_1 zijn, of Anoniem_12 of whatever.
Het hangt er maar vanaf de hoeveelste anoniem je daar bent.
En waarom zou je ook een anonieme auteur van een nieuw topic niet m.b.v. zijn string altijd "Anoniem_1" noemen,
zodat men ook zeker weet dat het echt "de maestro himself" is, die in een reactie het woord weer heeft.

Zo is er dus geen relatie te leggen tussen anoniemen in verschillende topics/threads, maar wél in 1 en dezelfde topic/thread! Dit komt de leesbaarheid ten goede, terwijl men trolgedrag van een bepaald hinderlijk type voorkomt,
omdat je je op deze manier niet in dezelfde thread voor een andere anoniem kunt uitgeven of die schijn kan wekken.

En wordt een post gelockt of verwijderd, dan kunnen alle anonieme strings die aan die post "kleven" automatisch worden gewist, en ook als de geldigheidsduur van een string voorbij is, kan deze string bij alle threads automatisch worden gewist. Wat blijft is ..... door Anoniem_1, ....... door Anoniem_2 etc., in de grijze balk boven resp. elke post.


Het is maar een alternatieve voorzet, variaties zijn natuurlijk mogelijk als dat wenselijker mocht zijn.
20-10-2019, 07:24 door [Account Verwijderd]
Door Anoniem:
Door Superuser: Als je mijn volledige bijdrage had gepost dan had iedereen kunnen zien dat dit er zelfs al - relativerend - bij staat.

Voor een slechtziende of blinde, die werkt met een braille regel, valt een lopende discussie een stuk eenvoudiger te bevatten als je je in het vervolg bij het "quoten" beperkt, tot alleen de voor je betoog relevante tekst passages.Voor de wel goed zienden onder ons is dat te aanschouwen beeld dan vast ook een veel prettiger aanblik. Hartelijk dank :-))

Je moet allereerst begrijpend leren lezen. Dan had je begrepen dat het juist om weglating van relevante delen uit een quote ging. Volledig quoten is een ander uiterste maar delen weglaten en dan gaan uitwijden over juist dat wat weggelaten is, dat is erger.
20-10-2019, 07:48 door [Account Verwijderd]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Door Anoniem: Wel een punt. Met dit systeem moet je integriteit van berichten op fora met een korrel zout nemen. Bij elk forumpakket wat ik tot nu toe gezien heb kunnen moderatoren de inhoud van berichten (achteraf) aanpassen. Je moet dus maar op vertrouwen dat een moderator of systeembeheerder nooit corrupt zal worden. Het is natuurlijk geen PGP sig over je post.

Koos - sha256:804f969651a8e9ef78acc0b2d9bb5b92f26c81c33562bb5c444ff859516e4096

Dat zou je ook nog kunnen doen. Een bericht aanmaken met een externe tool en dat signeren.
-----BEGIN PGP SIGNATURE-----

iQGtBAEBCgAXEBxTdXBlcnVzZXIgPG4vYT4FAl2r9QEACgkQqb1Q9bov/F1afAwA
oNt0ed3cwtfey+iM90SdJ5B85N8KaWEUJqrmx/XkRoyuP4kjXTg0P+WP0fbwEpRH
TjgXp4ufBGm3fQAXa6/c1IRp1XqYX1rF3MHUiroiMgAR8uLpajytBht/CU6lI+2/
oLwq7yF+FLhHoZovUhCkeRVDo+Y/rp/Gfp8c/ZWJlMszcuyJHO6rE5G5F8DIaxI7
et/mf2Vbt/zj+vN7KS1dvXjye41N7GcXYuP71miNCw80JrxV7rrFXPNeMtGxwwlr
U9IbXz1LkOMxJmGIfpNt2/+NDsaETFixwIWhst+3Yfa5YfDqzOv731k4S4aXfHmo
tnlRAjKg/Y+ej13oTzriJKU7ROeBWScsN6fzCS2/Lu2QrbX6m/8GLoX1MvhwD0Ci
CBznvgXixmMEW8tv66l3cmfTb1nsq0mC0W/38YiSgDL1qCEgd6w68jGbuj0lyOaX
f8bnoDJUUABGQqdvA8NpgJlWKk/JkF9rywFbqgEIpGNzGH5WmPjKadDnniPBRQJb
=JU+5
-----END PGP SIGNATURE-----
20-10-2019, 07:51 door [Account Verwijderd] - Bijgewerkt: 20-10-2019, 07:52
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Deze werkt prima onder Android:

https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain
-----BEGIN PGP SIGNATURE-----

iQGtBAEBCgAXEBxTdXBlcnVzZXIgPG4vYT4FAl2r9f4ACgkQqb1Q9bov/F0efAwA
pIYtokp2vhcdkhayANV++mRy3lAuSmnbv0JiyawVeeyY4tL22JrpnJAhpyMM6dDq
bJbXlBtJ1zOiBsO6GbumoCatxLYNwKzXd6cMKqGK0I8CixZwRQWe6VJJxUszX1Lk
yAtjt1EjXqUG/yhZSyO/qTStLk81zQzxUORZt0rHvSQNAmEl0VZ0CyFJEzU7cBJP
K//J/590o5oXSvrJOpE1Ie3Abv7Lnct81OZLU3s90t8efTj8P5B7NHVciHFPQ2Eu
cU/gQTi5ew+HNWZSbv1qBi7ynRXDfyqGxi9K9P8bbH8lJLZ3PL2k9OJztnTdKgvA
HDbKHGfe4a95MrTMLEDqdQCZCtCqPp+8pU4AZJ12QSOqB4VrnANM27LWbTKJCPmw
Vj9rwmbT7vn4TjEh6fGvscH+T1At2lPv7wdtxZNjUhcWgWVPh7vQzaQxkmnN9lFK
2nIstwi3Ex7XOjEXOz45NX/Is93GwLk3rzPSvlK47ymC85bzQZZn7ucorXBYN2RM
=ibNi
-----END PGP SIGNATURE-----
20-10-2019, 20:17 door Overcome
Leuke vorm van toegepaste cryptografie. De methode is bijna identiek aan de methode zoals beschreven door Philip Karn en Neil Haller op https://tucops.info/tucops3/hack/password/live/aoh_skey.htm en draagt de naam S/KEY. Zie https://en.wikipedia.org/wiki/S/KEY voor meer informatie.
20-10-2019, 22:43 door Erik van Straten
Mijn excuses dat ik niet op alle reacties en/of volledig kan ingaan. Ik hoop op jullie begrip!

18-10-2019, 12:17 door Anoniem (sha256:b88bf8144c60616ae29de39e0deba5279c10ee32edf797f108b0bb1aa1c26cae): [...]@REDACTIE: dit is doodeenvoudig te verbeteren, door in core.css, regel 1790, aan div.markup-config dit toe te voegen:
white-space: pre
Een monospace font is niet voldoende voor code.
[...]
De redactie heeft, zo te zien, jouw verzoek opgevolgd, door toe te voegen: "white-space: pre-wrap;". Als gewrapte regels niet onwenselijk zijn, dan previewen en er rekening mee houden dat sommige webbrowsers iets grotere lettertypes kunnen gebruiken. Hartstikke fijn, dank ook aan de redactie!

18-10-2019, 13:01 door Anoniem: [...] Aan de hand van de hashfuncties in posts kun je een volledig profiel van de historie van iemand opbouwen. Die tekst kun je laten analyseren en met ML learning laten fingerprinten. Er ontstaat dan een digitale vingerafdruk van jouw grammatica en vocabulair waarmee je dus een deel van je privacy verliest. [...]
Als je per thread een nieuwe sequence gebruikt (effectief hetzelfde als onderaan de lijst een waarde weggooien en met de waarde daarboven verder gaan, breaking the chain dus), lijkt mij de kans daarop klein. Veel eerder verwacht ik dat ML in toenemende mate schrijfstijl en meningen zal kunnen herkennen en aan een specifiek individu koppelen. Je hebt dan maar één of enkele versprekingen nodig om jouw volledige identiteit te kunnen vaststellen.

M.b.t. identiteit en opinie: gisteren las ik in https://www.nu.nl/weekend/6005078/waarom-laten-we-ons-niet-door-feiten-overtuigen-dat-ligt-aan-ons-brein.html een aardig artikel hierover. Voordat ik dat las was ik er 100% van overtuigd dat ik volledig opensta voor argumenten die mijn ongelijk bewijzen. Maar klopte die 100% wel? ;-)
20-10-2019, 22:44 door Erik van Straten
18-10-2019, 13:01 door Anoniem: [...]
18-10-2019, 10:27 door Erik van Straten: Zo is het hashen van telefoonnummers, IPv4-adressen en MAC-adressen "om de anonimiteit van de eigenaar te waarborgen" complete snake oil, want je kunt redelijk snel een tabel (bekend als rainbow table) maken van alle mogelijke waarden en de bijbehorende hash. En vervolgens kun je, gegeven een hash, heel snel de bijbehorende input opzoeken - weg anonimiteit.

Een hacker kan zich ook toegang verschaffen tot jouw systeem of router of smartphone (waarschijnlijk het makkelijkst) en vanaf de shell een python scriptje draaien om ergens iets te posten of een site te pingen en voila jij bent het geweest.
Wat ik schreef was in dit kader enigszins off-topic, ik doelde hiermee vooral op de privacy-risico's die wij lopen doordat (vooral commerciële) partijen de AVG denken te kunnen omzeilen door bijv. MAC-adressen van getrackte smartphones (bijv. op de Wallen) te hashen. De beveiliging van mijn eigen router en smartphone heb ik grotendeels zelf in de hand.

18-10-2019, 13:01 door Anoniem: [...] Met een account zit je toch altijd beter, je kunt altijd nog oude posts editen en corrigeren. [...]
Door een recente wijziging kan dat (helaas wat mij betreft) nog maar een half uurtje na de laatste wijziging. Als ik onzin uitkraam (dat gebeurt regelmatig) en iemand corrigeert mij (gelukkig gebeurt ook dat regelmatig) dan kan ik mijn oorspronkelijke bijdrage niet meer aanvullen met een correctie.

Een ander nadeel van anoniem posten is dat je jouw bijdragen nooit zelf kunt verwijderen, wat wel kon (ik weet niet of dat nog zo is) door je account op te heffen - als je dat hebt natuurlijk.
20-10-2019, 22:44 door Erik van Straten
18-10-2019, 14:09 door Anoniem, Piet md5 6046ed57b742d0dca8504cecd0c0b03b: [...] Daarbij is ook deze methode niet bestand tegen manipulatie, zeker door mensen met toegang tot krachtige computers. [...]
Krachtige computers helpen niet, want in principe moet je gemiddeld 2^255 (de helft van 2^256) berekeningen uitvoeren om, op basis van een SHA256 hashwaarde, de input te kunnen uitrekenen. In de praktijk is het altijd wat gunstiger voor aanvallers, dus laten we uitgaan van 2^240. Dat is ruim 10^72. Even een "losse pols" berekening, correct me if I'm wrong.

Stel dat die krachtige computer een picoseconde (10^-12 seconde) doet over een berekening. En laten we 1.000.000 van die computers parallel schakelen (geen geldgebrek dus). Dan duurt het 10^56 seconden om één input uit te rekenen. Als je rekent met 365 dagen in een jaar, zitten in zo'n jaar 31.536.000 seconden. Dan duurt die berekening ruim meer dan 10^48 jaar. Helaas gaan die computers niet zo lang mee, maar hoogstwaarschijnlijk hebben we, ruim voor die tijd verstreken is, veel snellere computers. Wanneer we computers zullen hebben die dit aankunnen weet ik niet - maar niemand verwacht ze de komende jaren. En mochten ze wel snel verschijnen, dan hebben we grotere problemen dan gekraakte hashes in berichten op security.nl.

18-10-2019, 14:09 door Anoniem, Piet md5 6046ed57b742d0dca8504cecd0c0b03b: [...] Dit zou alleen iets zijn voor die 4 individuen (JO, luntrus, #sockpuppet, Jodocus Oyevaar) die geen account hebben maar wel impersonatie willen tegengaan als alternatief voor een inlog. [....]
Eens, daar ging ik ook van uit. Een leesbare nickname zodat anderen weten of meerdere posts, in elk geval binnen één thread, door dezelfde persoon geschreven zijn, en die hash om bedrog aan te kunnen tonen mocht iemand anders met jouw nickname "ondertekenen".

18-10-2019, 14:09 door Anoniem, Piet md5 6046ed57b742d0dca8504cecd0c0b03b: [...] Maar het was wel een creatief voorstel! [...]
Dank je wel!
20-10-2019, 22:44 door Erik van Straten
18-10-2019, 15:03 door Anoniem: [...]Dus elke anoniem die anoniem wil blijven maar wel wil aantonen dat zijn/haar eventuele vervolgposts (in dezelfde thread) werkelijk van hem/haar zijn, zou van www.security.nl een zootje opeenvolgende SHA256-hashes moeten krijgen [...]
Als ik anoniem zou posten (dat heb ik wel eens gedaan), en hier gebruik van zou maken, zou ik dit volledige in eigen hand willen houden en niet aan security.nl willen overlaten.

Een van de redenen daarvoor is dat ik weinig vertrouwen heb ik CSPRNG's (Cryptographically Secure Random Number Generators). Te vaak bleken die dingen in het verleden niet goed te zijn ontworpen, verkeerd te zijn geïmplementeerd/gewijzigd, niet goed te werken (bijv. als gevolg van virtualisatie), een ingebouwde "predictability" backdoor te hebben, extern beïnvloedbaar te zijn of informatie te lekken (bijv. via side-channels).

Een andere reden is dat, als security.nl iets fout zou doen, mogelijk van alle bijdragen met hashes op deze site de (nog niet uitgegeven) parent-hashes uitgerekend kunnen worden. Wellicht ook geen enorme ramp, maar wel gezichtsverlies (het is ten slotte een security site :-)
20-10-2019, 22:45 door Erik van Straten
18-10-2019, 15:46 door Anoniem: Het vervelende is dat je zo'n tekstbestand wel PER TOPIC moet bijhouden
Is dat echt zo'n probleem, d.w.z. als je je zorgen maakt over "anonieme identiteitsfraude"?

18-10-2019, 15:46 door Anoniem: en dan nog gaat het de mist in als een moderator besluit je bijdrage niet te accepteren.
Daar heb je wel een goed punt. Als je een hash-regel niet weggooit uit het bestand, maar er "used" voor zet o.i.d., kun je die hergebruiken als een bijdrage niet wordt geplaatst. Echter, het valt me op dat sommige anonieme bijdragen later verschijnen (na moderatie te hebben doorstaan) dan andere, later geposte, bijdragen. Met andere woorden, je weet niet precies of en wanneer jouw bijdrage zal verschijnen, en kunt tot die tijd geen nieuwe bijdrage posten.

Kent iemand een oplossing voor dit probleem?
20-10-2019, 22:45 door Erik van Straten
19-10-2019, 22:34 door Anoniem: Volgens mij kan het een stuk eenvoudiger, zonder hash-gereken en minder werk:

Bijv. elke anoniem die wil reageren zou van security een unieke willekeurige string kunnen krijgen, die de anoniem lokaal onthoudt (bijv. opslaat met copy-paste). Deze string is een beperkte periode geldig (bijv. 3 maanden) voor alle topics, en verschijnt voor security.nl-lezers niet in beeld, zodat alleen de betreffende anoniem en de server van security.nl de string kennen. Security.nl slaat deze string dus op, zodat legitieme uitgegeven strings kunnen worden terugherkend. [...]
Dat klinkt meer als een soort tijdelijk account; ik vermoed dat de meeste anoniemen nou juist niet willen dat security.nl iets van hen onthoudt (anders dan reeds geposte bijdragen natuurlijk).
20-10-2019, 22:46 door Erik van Straten - Bijgewerkt: 20-10-2019, 22:54
@Superuser en andere PGP-ers: PGP kan maar geeft een hoop "troep" onderin je posts. Het volgende kan ook:
(1) Gebruik de hashfile zoals ik bovenaan deze pagina beschrijf;
(2) Schrijf de bijdrage met onderaan: nickname sha256:hashvalue en leg uit dat de VOLGENDE hash niet moet worden meegenomen in de HMAC-berekening die ik hieronder beschrijf;
(3) Druk "Preview";
(4) Kopieer naar klembord;
(5) Plak in een (nog te maken) tool die alle white space verwijdert en m.b.v. een HMAC functie, met als secret de parent-hash, een "message authentication code" van jouw bijdrage berekent;
(6) Druk "Aanpassen";
(7) Plak het resultaat van de HMAC functie achter nickname sha256:hashvalue of zet deze op een nieuwe regel.

Nadat je de parent-hash publiceert, zou een security.nl beheerder jouw eerdere bijdrage kunnen wijzigen en de MAC aanpassen. Maar dat is wat ver gezocht denk ik. Voor de zekerheid kun je de pagina natuurlijk door archive.org en/of archive.is laten archiveren (voordat je de parent-hash publiceert), zodat je aan de hand van die sites kunt bewijzen dat jouw bijdrage is gewijzigd.
20-10-2019, 22:47 door Erik van Straten - Bijgewerkt: 20-10-2019, 22:55
20-10-2019, 20:17 door Overcome: [...] De methode is bijna identiek aan de methode zoals beschreven door Philip Karn en Neil Haller op https://tucops.info/tucops3/hack/password/live/aoh_skey.htm en draagt de naam S/KEY. Zie https://en.wikipedia.org/wiki/S/KEY voor meer informatie.
Ah, dat lijkt inderdaad als twee druppels water! Ik had al een voorgevoel dat ik hier geen miljonair mee zou worden en heb het algoritme daarom maar niet voor mezelf gehouden... ;-)
Ik wist niet dat deze methode ergens beschreven was - maar credits where credits are due!
21-10-2019, 07:10 door Anoniem
Wel eens van PGP gehoord?
21-10-2019, 09:51 door Erik van Straten - Bijgewerkt: 21-10-2019, 09:56
Door Anoniem: Wel eens van PGP gehoord?
Ja (zie o.a. https://security.nl/posting/39614/).

Wedervraag: waarom lees je niet eerst alle reacties (zoek anders op z'n minst even naar PGP in deze pagina) voordat je wat roept?

(Overigens slim om dit niet-niet-anoniem te doen, anders weten we wie we niet meer serieus hoeven te nemen).
21-10-2019, 12:50 door Anoniem
Door Erik van Straten: Een ander nadeel van anoniem posten is dat je jouw bijdragen nooit zelf kunt verwijderen, wat wel kon (ik weet niet of dat nog zo is) door je account op te heffen - als je dat hebt natuurlijk.

Privacy Policy >> Gegevens inzien, correctie en verwijdering

https://www.security.nl/privacy?version=2018

Security.NL behoudt zich het recht voor deze privacy policy aan te passen. Wijzigingen zullen op deze website worden gepubliceerd.
21-10-2019, 13:06 door Anoniem
Door Erik van Straten: De redactie heeft, zo te zien, jouw verzoek opgevolgd, door toe te voegen: "white-space: pre-wrap;".
Ah! Jouw reactie zag ik eerder dan het resultaat ervan omdat ik van onder naar boven keek of er nog iets interessants was gemeld ;-)

@REDACTIE: Hartelijk dank!

Als gewrapte regels niet onwenselijk zijn, dan previewen en er rekening mee houden dat sommige webbrowsers iets grotere lettertypes kunnen gebruiken.
Voor kopiëren en plakken zou dat geen probleem moeten zijn. Previewen is trouwens sowieso aan te bevelen, het is namelijk maar al te makkelijk om typfoutjes te maken in bbcodes.

Ik vind het hoe dan ook wel een goede gewoonte om regels niet te lang te laten worden in code. Ik heb 79 tekens ingesteld staan in mijn editor. Dat is vermoedelijk een waarde die niet snel tot problemen zal leiden bij het uitwisselen van code. Voor mijzelf is het een goede waarde om met een voor mij prettige fontgrootte op een doorsnee beeldscherm twee sources naast elkaar te kunnen zetten.

Maar over dit soort voorkeuren worden loopgravenoorlogen gevoerd, ik benadruk dus dat het niet meer dan mijn voorkeur is en geen voorschrift (en voor wie nu met PEP-8 aan komt zetten: ook dat is geen voorschrijft, het is een richtlijn ;-) ).

sha256:972f39f1b1282954adb0607d310c77cbb37669d368a07c51bf9f23057a552554
21-10-2019, 14:01 door Anoniem
Wel eens van PGP gehoord?

Wat een nuttige bijdrage. Voor inhoudelijke reacties m.b.t. PGP, waar mensen wat aan hebben, zie boven.
21-10-2019, 15:33 door Anoniem
Door Erik van Straten:
18-10-2019, 15:46 door Anoniem: Het vervelende is dat je zo'n tekstbestand wel PER TOPIC moet bijhouden
Is dat echt zo'n probleem, d.w.z. als je je zorgen maakt over "anonieme identiteitsfraude"?

18-10-2019, 15:46 door Anoniem: en dan nog gaat het de mist in als een moderator besluit je bijdrage niet te accepteren.
Daar heb je wel een goed punt. Als je een hash-regel niet weggooit uit het bestand, maar er "used" voor zet o.i.d., kun je die hergebruiken als een bijdrage niet wordt geplaatst. Echter, het valt me op dat sommige anonieme bijdragen later verschijnen (na moderatie te hebben doorstaan) dan andere, later geposte, bijdragen. Met andere woorden, je weet niet precies of en wanneer jouw bijdrage zal verschijnen, en kunt tot die tijd geen nieuwe bijdrage posten.

Kent iemand een oplossing voor dit probleem?

Hm. Het is _heel_ glad ijs om uit de losse pols een crypto protocol aanpassing te suggereren, maar laat ik een gooi doen.
(als anoniem, dus ik heb geen reputatie hoog te houden ...)

Je zou een sequence nummer (van postings) bij je hash kunnen plaatsen, en hangende het moderatie tijdswindow gewoon een paar voorgaande hashes van postings die je al ingediend had maar nog niet doorgekomen zijn erbij kunnen zetten.

Dan is ook zichtbaar dat je claimt meerdere bijdragen gepost te hebben - als moderatie er een dropt uit de serie is dat te zien - (nee, helpt niet tegen malicious moderator die je hash lijst inlkort en de volgorde opeenvolgend houdt. ).
21-10-2019, 17:12 door Anoniem
Misschien is CRC32 makkelijker. Dat zijn maar 8 karakters. Met die lange hashes wordt het een rommeltje.
21-10-2019, 17:34 door Erik van Straten
Door Anoniem: Misschien is CRC32 makkelijker. Dat zijn maar 8 karakters. Met die lange hashes wordt het een rommeltje.
Minder rommelig zeker, makkelijker weet ik niet. Maar totaal zinloos, want CRC32 kraak je binnen no time. CRC32 is dan ook geen cryptografische hash, maar prima voor het met behoorlijke zekerheid detecteren van onopzettelijke wijzigingen.
Nb. die betrouwbaarheid is alleen redelijk als dergelijke onopzettelijke wijzigingen zelden voorkomen.
21-10-2019, 18:35 door Anoniem
22:45 Door Erik van Straten:
19-10-2019, 22:34 door Anoniem: Volgens mij kan het een stuk eenvoudiger, zonder hash-gereken en minder werk:....................
Dat klinkt meer als een soort tijdelijk account; ik vermoed dat de meeste anoniemen nou juist niet willen dat security.nl iets van hen onthoudt (anders dan reeds geposte bijdragen natuurlijk).

???
Aangezien met jouw methode iedereen kan zien welke berichten van dezelfde anoniem zijn, kan security.nl dit ook zien,
en het eveneens misbruiken als ze dat zouden willen.
(sha256 hashes hangen aan posts, die weer in de database staan bij security.nl....)
Maakt dus weinig uit.

Verder zie ik security.nl er niet voor aan dat ze zich voor iemand anders zullen uitgeven door met de string van een ander aan de haal te gaan. Dan zouden ze zichzelf ongeloofwaardig maken.
Een laatste mogelijkheid is dat er eens strings van de site worden gestolen met een hack, of op de site wordt geklooid.
Maar hoe vaak komt dat voor, en hoe erg is dit dan eigenlijk? Waarschijnlijk niet meer dan vervelend.
De bedoeling is immers dat strings na bijv. 3 maanden automatisch worden gewist,
dus strings ouder dan 3 maanden staan niet meer op de site.

Overigens staat het in mijn voorstel anoniemen vrij om op elk moment een nieuwe string aan te vragen.
De anoniem bepaalt dus zelf wanneer hij relatie met zijn eerdere post(s) wil leggen en wanneer niet.
Misschien is het handig dat de anonieme poster zelf kan aangeven wat voor string hij wil:
- geen, gewoon ouderwets posten zoals het nu is. (geen relatie tussen posts)
- voor 1 topic (om kenbaar te maken welke posts van dezelfde anoniem zijn in één thread)
- voor een bepaalde tijd, bijv. max. 3 maanden (een soort tijdelijk account, maar dan anoniem (= zonder email-adres) )

(ik denk dat opgeven van emailadres meestal de reden is dat anoniemen geen account nemen...)


vr.gr.,
Anoniem 19-10-2019, 22:34
21-10-2019, 19:19 door Anoniem
Door Anoniem: Wel eens van PGP gehoord?

PGP sigs geven veel overhead. Een serverside implementatie (filter en verificatie check) is dan de oplossing. Dit is de ideale situatie.

De sha256 sig vertrouwt op de integriteit van de moderator (die immers achteraf content kan wijzigen) en het beschermt ook niet tegen een hack van server/client. Deze sig geeft enkel de mogelijkheid om je bijdragen te tracken en biedt slechts een basisbescherming tegen online impersonatie. Het is een leuk experiment.

1 regeltje tekst is niet zo erg als een rommelige PGP sig. Je kunt ook refereren aan een @hash als je op een bericht reageert in plaats van een naam en/of tijdstip als je niet wilt quoten.

Koos - sha256:f096ef9a939eb1eefc77363383e19d8906f10d47f1f26e98d7d10246b2367a41
21-10-2019, 19:25 door Anoniem
Door Anoniem: Hm. Het is _heel_ glad ijs om uit de losse pols een crypto protocol aanpassing te suggereren, maar laat ik een gooi doen. (als anoniem, dus ik heb geen reputatie hoog te houden ...)

Dit is inderdaad glad ijs, maar de zaak achter dit forum, de firma The Security Council B.V, gaat niet over één nacht ijs.

Je zou een sequence nummer (van postings) bij je hash kunnen plaatsen, en hangende het moderatie tijdswindow gewoon een paar voorgaande hashes van postings die je al ingediend had maar nog niet doorgekomen zijn erbij kunnen zetten.

Anoniem op 18-10-2019, 19:19 stelde een eenduidige eenregelige nickname formatering voor, met daarin een serie dubbele punten als field delimiters, en volgnummers voor de postings. Zoiets als dit:

nick:0001:sha256:e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178

Zonder een eenduidig formaat wordt het nog een heel gedoe om de opeenvolgende hashes terug vinden, zeker als die ook nog verspreid staan over meerdere topics. De moderatie tijdsduur en eventuele afwijzingen zijn ook problematisch. Het zou betekenen dat hashes nog niet van de lijst kunnen worden geschrapt, terwijl die al uit handen zijn gegeven.

De hash in dit voorstel omvat de inhoud van het bericht niet, waardoor er met de inhoud kan worden geknoeid. Dat lijkt mij geen zuivere koffie. Kortom, zo'n losse hash bewijst weinig tot niets, terwijl de anonimiteit van de auteurs er mee te grabbel wordt gegooid. Men moet dus iets beters bedenken om de gemoederen op dit forum in toom te houden.
21-10-2019, 23:01 door Erik van Straten - Bijgewerkt: 21-10-2019, 23:04
21-10-2019, 18:35 door Anoniem: [...](ik denk dat opgeven van emailadres meestal de reden is dat anoniemen geen account nemen...)
Daar heb je gelijk in. Ik heb jouw vorige (19-10-2019, 22:34) en de laatste bijdrage nog eens goed gelezen, en inderdaad kan denk ik wat je voorstelt. Er moet echter wel flink voor geprogrammeerd worden om te onthouden welke reeksen unieke karakterreeksen aan de vele anoniemen zijn uitgegeven, en welke na 3 maanden kunnen vervallen.

Ik denk ook niet dat de methode die ik bovenaan deze pagina beschreef aan zal slaan, laat staan een lang leven beschoren is. Maar het ging dan ook meer om het idee.

Over ideeën gesproken: mijn "signing" idee uit https://security.nl/posting/628112#posting628387 breng ik, iets aangepast, in de praktijk. Je kunt controleren of dit bericht niet is gewijzigd (inclusief opmaak) sinds ik het plaatste, als volgt:
(1) Download "rehash.exe" uit https://sourceforge.net/projects/rehash-2/files/win32/ (dit programma is geschreven door Dominik Reichl, de auteur van KeePass);
(2) Controleer dat het om hetzelfde bestand gaat als in https://www.virustotal.com/gui/file/cbf8ad544adfcf1f66123331bcb44a5132ddfefdfdceef11ff3ba41a315151e5/detection;
(3) Klik op "Reageer met quote" voor dit bericht;
(4) Selecteer alle tekst (inclusief bbcodes dus) TOT de onderste regel die begint met "HMAC";
(5) Kopieer en plak de tekst in Windows Notepad/Kladblok en sla op in een bestand genaamd test.txt (de tekst moet eindigen op 1178 en NIET op een lege regel, en het bestand moet precies 2770 bytes lang zijn);
(6) Voer uit (het commando met parameters in de volgende vette tekst moet op 1 regel staan):

rehash -hmac:d60606f7d0d4aa5dfb9b1b4514fb1bcf -n -sha256 -out:nospaces -out:lowhex test.txt

Nb. De secret key "d60606f7d0d4aa5dfb9b1b4514fb1bcf" bevat de eerste 16 bytes van de derde SHA256 karakterreeks bovenaan deze pagina, waarbij we even doen alsof ik die nog niet heb gepubliceerd; en de 4e karakterreeks zet ik in deze bijdrage.

Het resultaat van bovenstaande opdracht moet identiek zijn aan de HMAC-waarde onderaan dit bericht (zo niet, dan is er iets in het bericht gewijzigd sinds ik het plaatste). Indien je zelf constateert dat de redactie (of een hacker) iets aan jouw bericht gewijzigd heeft, dan post je de eerstvolgende hash (in dit voorbeeld de derde regel) gewoon niet. Lezers van security.nl kunnen dan wel zien (aan de hash achter de dubbele punt) dat het jouw laatste reactie was in een reeks, maar ook zij kunnen niet vaststellen dat die laatste reactie volledig van jouw hand is.

Erik:0001:e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178
HMAC: df2e9eaf1aca94f7ef558f7722817af11ab593eaa666f8c6b9dddf4659c281d1
21-10-2019, 23:20 door Erik van Straten - Bijgewerkt: 21-10-2019, 23:33
Aanvulling: ik moest de HMAC-waarde onderaan bovenstaand bericht nog even editten omdat ik vergeten was dat, als je op "Reageer met quote" klikt, het bericht wordt aangepast. Als je een bericht van mij quote, wordt natuurlijk vooraan gezet:

[ quote ][ i ]Door Erik van Straten:[ /i ]_

(zonder de Alt-0255 spaties tussen de bakhaken die ik moest toevoegen om uitvoering van de bbcodes te voorkomen, en _ wordt een spatie).

In de HMAC berekening hierboven (en grootte van de file test.txt, zijnde 2770 bytes), heb ik er rekening mee gehouden dat genoemde karakterreeks ervoor wordt geplaatst (wat achteraan geplakt wordt boeit niet, omdat de onderste regel niet wordt meegenomen in de HMAC-berekening).

P.S. mocht de Redactie of een hacker mijn "signed" bericht wijzigen en de key en/of HMAC aanpassen, dan kun je in https://web.archive.org/web/20191021212527/https://www.security.nl/posting/628112/crypto+bewijs%3A+dezelfde+anoniem zien wat deze zojuist waren... ;-)
22-10-2019, 12:25 door Q1
Door Erik van Straten:
[...]
Stel dat die krachtige computer een picoseconde (10^-12 seconde) doet over een berekening. En laten we 1.000.000 van die computers parallel schakelen (geen geldgebrek dus). Dan duurt het 10^56 seconden om één input uit te rekenen. Als je rekent met 365 dagen in een jaar, zitten in zo'n jaar 31.536.000 seconden. Dan duurt die berekening ruim meer dan 10^48 jaar. Helaas gaan die computers niet zo lang mee, maar hoogstwaarschijnlijk hebben we, ruim voor die tijd verstreken is, veel snellere computers. Wanneer we computers zullen hebben die dit aankunnen weet ik niet - maar niemand verwacht ze de komende jaren. En mochten ze wel snel verschijnen, dan hebben we grotere problemen dan gekraakte hashes in berichten op security.nl.
[...]

Een nog mooiere berekening is van de hand van Bruce Schneier, zie https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html, vanaf "Or read what I wrote about symmetric..."
Heel in het kort: hij maakt een berekening hoeveel energie er nodig is om de eenvoudigste teller te laten tellen van 1 tot 2^192, dat6 is 32 jaar alle energie van de zon. En dan gaan we uit van een teller met de kleinst mogelijke energieverbruik, gebaseerd op natuurkundige wetten.

En 2^192 klinkt al heel wat, maar het betekent dat je nog 2^63 zonnen (!!!) nodig hebt om tot halverwege 2^256 te komen. Bij een schatting van 400 miljard sterren (ongeveer 2^39) in ons melkwegstelsel heb je dan 2^22 melkwegstelsels nodig. Kortom, encryptie met een 256bit sleutel is niet met alleen brute force te kraken

Q
22-10-2019, 13:03 door Q1
Door Erik van Straten: Af en toe, zo ook in [1], is er op security.nl onduidelijkheid of een anonieme bijdrage van de hand van dezelfde persoon is als een eerdere anonieme bijdrage.

In principe [...]

Je hebt me aan het denken gezet. De belangrijkste reden om anoniem te posten was het gemak.

Ik zie alleen steeds vaker anonieme posts "zonder inhoud", dat wil zeggen dat er of zonder onderbouwing "ik vind xyz" verkondigd wordt, of dat er zaken herhaald worden (in deze threat: "doe maar PGP"), of posts waarbij duidelijk is dat de poster alleen maar meningen van anderen na-papagaait. Terwijl er wel zinnige en interessante posts zijn die ik niet wil missen.

Dus de vraag die ik mezelf stelde was: wat zou ik graag zien?
Het antwoord was simpel: dat ik zie WIE de post gemaakt heeft zodat ik (anonieme) trollen kan negeren. Maar dan moet ikzelf ook "herkenbaar" zijn. De door jou voorgestelde oplossing is mogelijk maar vind ik te lastig, dus vanaf nu dan maar met een geregistreerd account :-)

Q
22-10-2019, 13:50 door Erik van Straten
@Q1: dank voor de link naar het artikel van Bruce Scneier, en nogmaals/meer welkom op deze site!
22-10-2019, 18:51 door Anoniem
Door Erik van Straten:
21-10-2019, 18:35 door Anoniem: [...](ik denk dat opgeven van emailadres meestal de reden is dat anoniemen geen account nemen...)
Daar heb je gelijk in. Ik heb jouw vorige (19-10-2019, 22:34) en de laatste bijdrage nog eens goed gelezen, en inderdaad kan denk ik wat je voorstelt. Er moet echter wel flink voor geprogrammeerd worden om te onthouden welke reeksen unieke karakterreeksen aan de vele anoniemen zijn uitgegeven, en welke na 3 maanden kunnen vervallen.

Ik denk ook niet dat de methode die ik bovenaan deze pagina beschreef aan zal slaan, laat staan een lang leven beschoren is. Maar het ging dan ook meer om het idee.

Over ideeën gesproken: mijn "signing" idee uit https://security.nl/posting/628112#posting628387 breng ik, iets aangepast, in de praktijk. Je kunt controleren of dit bericht niet is gewijzigd (inclusief opmaak) sinds ik het plaatste, als volgt:
(1) Download "rehash.exe" uit https://sourceforge.net/projects/rehash-2/files/win32/ (dit programma is geschreven door Dominik Reichl, de auteur van KeePass);
(2) Controleer dat het om hetzelfde bestand gaat als in https://www.virustotal.com/gui/file/cbf8ad544adfcf1f66123331bcb44a5132ddfefdfdceef11ff3ba41a315151e5/detection;
(3) Klik op "Reageer met quote" voor dit bericht;
(4) Selecteer alle tekst (inclusief bbcodes dus) TOT de onderste regel die begint met "HMAC";
(5) Kopieer en plak de tekst in Windows Notepad/Kladblok en sla op in een bestand genaamd test.txt (de tekst moet eindigen op 1178 en NIET op een lege regel, en het bestand moet precies 2770 bytes lang zijn);
(6) Voer uit (het commando met parameters in de volgende vette tekst moet op 1 regel staan):

rehash -hmac:d60606f7d0d4aa5dfb9b1b4514fb1bcf -n -sha256 -out:nospaces -out:lowhex test.txt

Nb. De secret key "d60606f7d0d4aa5dfb9b1b4514fb1bcf" bevat de eerste 16 bytes van de derde SHA256 karakterreeks bovenaan deze pagina, waarbij we even doen alsof ik die nog niet heb gepubliceerd; en de 4e karakterreeks zet ik in deze bijdrage.

Het resultaat van bovenstaande opdracht moet identiek zijn aan de HMAC-waarde onderaan dit bericht (zo niet, dan is er iets in het bericht gewijzigd sinds ik het plaatste). Indien je zelf constateert dat de redactie (of een hacker) iets aan jouw bericht gewijzigd heeft, dan post je de eerstvolgende hash (in dit voorbeeld de derde regel) gewoon niet. Lezers van security.nl kunnen dan wel zien (aan de hash achter de dubbele punt) dat het jouw laatste reactie was in een reeks, maar ook zij kunnen niet vaststellen dat die laatste reactie volledig van jouw hand is.

Erik:0001:e3648d293c8f6b266750efa43e02c01d5d5d91d062c2fb4e8dfcc57b61fa1178
HMAC: df2e9eaf1aca94f7ef558f7722817af11ab593eaa666f8c6b9dddf4659c281d1

Die software is alleen voor Windows. Klopt het dat je een andere HMAC-uitkomst krijgt bij gebruik van deze site: https://www.freeformatter.com/hmac-generator.html, of doe ik iets fout?
22-10-2019, 22:38 door Erik van Straten - Bijgewerkt: 22-10-2019, 22:46
Door Anoniem:
Door Erik van Straten:
(5) Kopieer en plak de tekst in Windows Notepad/Kladblok en sla op in een bestand genaamd test.txt (de tekst moet eindigen op 1178 en NIET op een lege regel, en het bestand moet precies 2770 bytes lang zijn);
Die software is alleen voor Windows. Klopt het dat je een andere HMAC-uitkomst krijgt bij gebruik van deze site: https://www.freeformatter.com/hmac-generator.html, of doe ik iets fout?
Nee, je doet niets fout. Op die site krijg ik echter weer andere resultaten dan op https://www.liavaag.org/English/SHA-Generator/HMAC/, geen idee waarom.

Opmerkelijk: de SHA256-HMAC van de tekst "test" met key "test" (alles zonder die aanhalingstekens) uitreken levert op beide sites 88cd2108b5347d973cf39cdf9053d7dd42704876d8c9a9bd8e2d168259d3ddf7 als resultaat op, en als ik "test" in een bestandje test.txt zet (zonder "regeleinde", het bestandje is dus 4 bytes lang), en uitvoer:
>rehash -hmac:test -n -sha256 -out:nospaces -out:lowhex test.txt
<test.txt>
HMAC hashes using key: test
SHA256 : 88cd2108b5347d973cf39cdf9053d7dd42704876d8c9a9bd8e2d168259d3ddf7
Hetzelfde resultaat dus. Ik vermoed dat er in de invoervelden van eerdergenoemde sites iets misgaat bij het kopiëren van wat "ingewikkelde" tekst (op de tweede site heb ik ook nog hex geprobeerd, na de tekst met een hexeditor in hex-bytes te hebben omgezet, maar dat werkte niet goed; ik kreeg als resultaat "String of HEX type must be in byte increments" terwijl het echt een reeks bytes is, maar wellicht een te lange).

Een aloud probleem is dat Windows (na MS-DOS) als regeleinde <CR><LF> (Carriage Return, Line Feed, de ASCII waardes 13 en 10) gebruikt, waar Linux standaard alleen <LF> gebruikt. Ik heb voor <CR><LF> gekozen omdat ik meestal Windows gebruik. Als je de tekst onder Linux opslaat, wordt het bestand daardoor 2751 bytes lang (i.p.v. 2770).

In principe zou je onder Linux de tekst met een "unix2dos"-achtig tooltje (https://linux.die.net/man/1/unix2dos) moeten kunnen omzetten, en zou een Linux versie van "rehash" dezelfde HMAC waarde moeten opleveren. Nb. rehash zou ook onder Linux zou moeten compileren en werken, de source staat ook op SourceForge en voor meer info zie https://www.dominik-reichl.de/software.html#rehash (het HMAC algoritme en de waarde van de gebruikte padding bytes worden o.a. beschreven in https://en.wikipedia.org/wiki/HMAC).

De reden om zelf geen online tool te gebruiken, is dat het -in de basis- niet verstandig is om secret keys op vreemde sites "te lekken" (ook de initieële random waarde en de hashes kun je natuurlijk het beste op een vertrouwd systeem genereren).

Om CRLF-, alleen LF- (Linux) en alleen CR- (MacOS) problemen te voorkomen, specificeert https://tools.ietf.org/html/rfc4880 voor OpenPGP overigens ook dat <CR><LF> moet worden gebruikt. Of die keuze, en die van mij hierboven, "de juiste" is, is natuurlijk discutabel. In elk geval kan ik zelf vaststellen of mijn tekst gewijzigd is, en iemand met identieke tools (of die wat extra moeite doet) zou dat ook moeten kunnen.

Anyway, signeren heeft wat meer voeten in de aarde dan slechts hashes van hashes berekenen, dus ook dit zie ik in de praktijk niet worden toegepast op deze site...
22-10-2019, 22:51 door Anoniem
Beste Erik van Straten,

Maar de bank doet het wel met een ten naam stelling en het bijbehorende IBANnummer.
Jje krijgt als het goed is een groene tag te zien.
Handig ter controle, maar wordt dit ook opgeslagen en is zulke info daarna veilig tegen lekken?

Neen er volgt bij mijn naam geen QR code of Blockchain code, te link.
Men maakt toch niets over naar mij ;)

Jodocus Oyevaer (uniek individu)
23-10-2019, 08:51 door Q1
Door Erik van Straten:
[...]
Om CRLF-, alleen LF- (Linux) en alleen CR- (MacOS) problemen te voorkomen, specificeert https://tools.ietf.org/html/rfc4880 voor OpenPGP overigens ook dat <CR><LF> moet worden gebruikt. Of die keuze, en die van mij hierboven, "de juiste" is, is natuurlijk discutabel. In elk geval kan ik zelf vaststellen of mijn tekst gewijzigd is, en iemand met identieke tools (of die wat extra moeite doet) zou dat ook moeten kunnen.

Anyway, signeren heeft wat meer voeten in de aarde dan slechts hashes van hashes berekenen, dus ook dit zie ik in de praktijk niet worden toegepast op deze site...

Nu heb je het alleen nog maar over "gewoon Nederlandse ASCII". Ik ben betrokken geweest bij het signen van berichtenverkeer, waarbij zowel ASCII en EBCDIC, met verschillende code pages, en UTF-8 waren betrokken. En dat op Windows, Linux, Tandem en IBM systemen.
De enige eginsinds betrouwbare manier is om voor het berekenen van de hash de tekst consequent naar UTF-8 te zetten en te versturen (en bij ontvangst eerst de hash te berekenen voordat je de UTF-8 terug vertaalt naar de native karakterset op het ontvangende systeem.
Maar ook daar ontstaan problemen, bv. als een karakter uit de bron niet in het doelsysteem kan worden weergegeven. Denk aan dingen als "Jürgen" wat in simpele systemen omgezet wordt naar "Juergen". Een bericht van systeem A met daarin "Jürgen" komt op systeem B aan als "Juergen". Het bericht terug naar A bevat dan misschien wel de juiste hash, maar op systeem A lijkt het om twee verschillende personen te gaan. Er is nl. geen eenduidige manier om dat terug te zetten (van "Juergen" naar "Jürgen"), terwijl je dat als mens wel kan....

Crypto: het lijkt zo simpel, maar de pret begint pas in de praktijk :-)

Q
23-10-2019, 13:09 door Anoniem
Een aloud probleem is dat Windows (na MS-DOS) als regeleinde <CR><LF> (Carriage Return, Line Feed, de ASCII waardes 13 en 10) gebruikt, waar Linux standaard alleen <LF> gebruikt. Ik heb voor <CR><LF> gekozen omdat ik meestal Windows gebruik. Als je de tekst onder Linux opslaat, wordt het bestand daardoor 2751 bytes lang (i.p.v. 2770).
Daar ergens zal vermoedelijk het verschil wel zitten.
Overigens is mijn text-file 2753 bytes lang (2754 bytes als ik ook nog de LF tussen de 2 laatste 2 regels meeneem)

Je bent dus afhankelijk van welke format je texteditor gebruikt,
en ook nog zoals Q1 aangaf van de gebruikte karakterset.
Zo wordt het toch nog complex.

vr.gr.
23-10-2019, 13:34 door Erik van Straten - Bijgewerkt: 23-10-2019, 13:37
Door Anoniem (naar verluidt "Jodocus Oyevaer (uniek individu)": [...] Maar de bank doet het wel met een ten naam stelling en het bijbehorende IBANnummer.
Jje krijgt als het goed is een groene tag te zien.
Handig ter controle,
Ik weet niet precies wat je bedoelt (bij mijn bank heb ik dat nog niet gezien), maar als ik je goed begrijp bedoel je dat jouw bank kennelijk een database heeft waarin de relatie tussen naam en rekeningnummer is opgenomen (die kant op, de andere kant op, of beide kanten op), waarvan gebruik gemaakt wordt om je te waarschuwen als je denkt geld over te maken naar Bob, maar Mallory jou op de mouw heeft gespeld dat Bob net een nieuw bankrekeningnummer heeft (dat van Mallory zelf of van een geldezel).

Door Anoniem (naar verluidt "Jodocus Oyevaer (uniek individu)": maar wordt dit ook opgeslagen en is zulke info daarna veilig tegen lekken? [...]
Informatie die gebruikt moet kunnen worden, is nooit 100% veilig tegen lekken. Echter, elk nadeel heb z'n voordeel.

Jouw bank kan het "verkrijgers" van data uit een onverhoopt lek wel moeilijker maken door niet de (privacygevoelige) informatie zelf, maar afgeleiden daarvan op te slaan (zoals zowel de hash van de naam als de hash van het bijbehorende bankrekeningnummer). Het probleem daarbij is dat bankrekeningnummers en korte achternamen weinig entropie hebben, waardoor brute force attacks en zoektabellen mogelijk zijn, en voor achternamen ook nog eens dictionary attacks voor de hand liggen.

Het beste (voor zover ik weet) wat je daartegen kunt doen is het creeëren van een soort "inbraakvertraging" door een protocol als Argon2 toe te passen (zoals ik eerder in https://security.nl/posting/628112#posting628142 schreef). Een nadeel daarvan is dat, hoe groter de inbraakvertraging, hoe meer geld (tijd, geheugen, CPU-cycles en energie) het de bank kost.

Je kunt vervolgens stellen dat, afhankelijk van hoeveel (tijd en/of geld) een aanvaller er voor over heeft, die "versleuteling" kraakbaar is of niet.

@Q1 (AKA Q): uit de grafiek rechtsboven in https://en.wikipedia.org/wiki/UTF-8, met hoe vaak bepaalde encodings werden gebruikt in de afgelopen jaren, blijkt dat jij niet meer de enige bent met een voorkeur voor UTF-8 ;-)
23-10-2019, 13:42 door Anoniem
Wederom een vraag, kan aan de hand van de anonieme posting in combinatie met de ingevoerde verificatiecode

=8385c705-e043-490a-99d4-4d0e8f6b7f45:16)
at <anonymous>:2:494
at eval (userscript.html?id=8385c705-e043-490a-99d4-4d0e8f6b7f45:4)
at eval (userscript.html?id=8385c705-e043-490a-99d4-4d0e8f6b7f45:5)
at Object.eval (userscript.html?id=8385c705-e043-490a-99d4-4d0e8f6b7f45:165)
at <anonymous>:2:494
at Object.E_c (<anonymous>:3:306)
at ja (eval at exec_fn (crypto+bewijs%3A+dezelfde+anoniem:1), <anonymous>:63:82)
at Object.create (eval at exec_fn (crypto+bewijs%3A+dezelfde+anoniem:1), <anonymous>:74:419)
at c (eval at exec_fn (crypto+bewijs%3A+dezelfde+anoniem:1), <anonymous>:15:354)
loaded.js:18 [TracePage] Page loaded
content.js:1 Feedback rendered
shaaaaaaaaaaaaa.com/api/check/security.nl:1 Failed to load resource: the server responded with a status of 404 ()
crypto+bewijs%3A+dezelfde+anoniem:1 Uncaught SyntaxError: Unexpected token < in JSON at position 0
at JSON.parse (<anonymous>)
at XMLHttpRequest.xhr.onreadystatechange (app.js:21)
antiphishing.js:1 Sending APH request...
userscript.html?id=2e3eadc0-39e9-4512-bab0-1e350c99d118:264 Starting AdRemover 8.5 on https://www.security.nl/posting/628112/crypto+bewijs%3A+dezelfde+anoniem 4 seconds after page load ...

achterhaald worden wie de anoniem is die post aan de hand van IP van poster samen met de ingevulde code?
at content.js:21
page.js:1626 [Tr]->[CF] Disabled Canvas Tracking.
page.js:1229 [Tr]->[HW] Modified hardware information.
page.js:887 [Tr]->[WR] WebRTC Device Enumeration.
page.js:724 [Tr]->[NP] Disabled Plugin Tracking.
page.js:525 [Tr]->[SB] Disabled Ping Tracking.

M.i. moet de moderatie dat kunnen zien, of de overheid dit kunnen opvragen bij de provider.

Vraag is in hoeverre is men nog anoniem op Interwebz, uitzonderingen dan daargelaten,

luntrus
24-10-2019, 08:41 door Anoniem
Door Erik van Straten: Een aloud probleem is dat Windows (na MS-DOS) als regeleinde <CR><LF> (Carriage Return, Line Feed, de ASCII waardes 13 en 10) gebruikt, waar Linux standaard alleen <LF> gebruikt. Ik heb voor <CR><LF> gekozen omdat ik meestal Windows gebruik. Als je de tekst onder Linux opslaat, wordt het bestand daardoor 2751 bytes lang (i.p.v. 2770).
Het is niet het enige verschil. Volgens de DOS-conventie is CR+LF een regelscheiding en volgens de *nix-conventie is LF een regeleinde. De consequentie is dat een DOS-tekstbestand niet eindigt in CR+LF en een *nix-tekstbestand wel in LF, ook de laatste regel heeft daar een expliciet einde. De *nix-conventie is bewust zo gekozen omdat dan met het cat-commando (en soortgelijke verwerkingen) tekstbestanden aan elkaar kunnen worden geplakt zonder dat de laatste regel van het ene bestand en de eerste van het volgende op dezelfde regel worden samengevoegd.

En er speelt nog een verschil: in de Microsoft-wereld is het gangbaar (voor teksteditors etc.) om een tekstbestand te laten beginnen met een byte order mark of BOM. Dat was oorspronkelijk het unicode-teken voor ZERO WIDTH NON-BREAKING SPACE, een teken dat visueel geen verschil maakt dus. De gebruikte unicode-codering (UTF8, 16-bit little of big endian etc.) is eraan te herkennen, dus is het geschikt als "magic number" voor unicode-tekstbestanden. Het geeft regelmatig problemen bij bijvoorbeeld CSV- en JSON-bestanden, waar het niet in thuishoort maar waar het wel door allerlei software aan wordt toegevoegd. Je suggereerde het gebruik van notepad, en dat voegt een BOM toe.

Beide verschillen beïnvloeden de hash-waarde. Lang niet elke tekst-editor ondersteunt en respecteert de verschillende conventies, en het is een behoorlijk geneuzel om het goed te krijgen als je editor het ondersteunt. Het is voorspelbaar dat daar heel wat fouten mee gemaakt zouden gaan worden. Om jouw idee goed werkend te krijgen heb je vermoedelijk een programma nodig dat het hele bericht qua regeleinden en BOM standaardiseert en op het resultaat daarvan de hash- en hmac-berekeningen uitvoert. Een interface die via het clipboard werkt zou in een GUI-context dan toegevoegde waarde hebben, zodat editors en tijdelijike bestanden overgeslagen kunnen worden.
24-10-2019, 10:52 door [Account Verwijderd]
Door Q1:Crypto: het lijkt zo simpel, maar de pret begint pas in de praktijk :-)

Q

Ja want het is ondanks de ondertekening van Koos niemand opgevallen dat ik in mijn laatste antwoord zijn tekst in de quote had veranderd. Of het is wel opgevallen maar omdat het topic ondertussen gelockt is kwam er geen antwoord?

https://www.security.nl/posting/627962#posting628557
24-10-2019, 12:52 door Erik van Straten
@Anoniem 23-10-2019, 13:42 (naar verluidt luntrus): je bent nooit anoniem op Internet (afhankelijk van de trucs die je gebruikt, kun je het mensen, die jouw echte identiteit proberen te achterhalen, wel meer of minder moeilijk maken).

24-10-2019, door Anoniem: En er speelt nog een verschil: in de Microsoft-wereld is het gangbaar (voor teksteditors etc.) om een tekstbestand te laten beginnen met een byte order mark of BOM. [...]
Je hebt gelijk dat de gebruikte codering o.a. afhankelijk is van de gebruikte teksteditor. en die BOM heb ik vaak eerder gezien. Tot mijn verbazing kreeg ik die BOM niet meer gegenereerd met Notepad onder W10 v1903, deze lijkt nu UTF-8 of zo te gebruiken (ik heb dit niet precies vastgesteld).

Die versie van notepad genereert voor de karakters á en à nu DE ENE KEER elk 1 byte (resp. 0xE1 en 0xE0) en DE ANDERE KEER 2 bytes (resp. 0xC3A1 en 0xC3A0). Ik begrijp nog niet wat de criteria zijn voor deze keuze, maar in elk geval maken dat soort verschillen digitale handtekeningen natuurlijk kansloos (niet alleen ik liep er tegenaan bij 0xC3A1 vs. 0xE1 voor á, zie https://stackoverflow.com/questions/26390313/get-non-ascii-character-from-single-character-code).

Fix: uitsluitend ASCII 32 t/m 126 gebruiken? Of in BASE64 posten? Beide worden geen succes wordt vermoed ik...

@Daemon: het was me wel opgevallen dat je jouw nickname hebt veranderd ;-)
24-10-2019, 13:00 door [Account Verwijderd] - Bijgewerkt: 24-10-2019, 13:03
Door Erik van Straten: @Daemon: het was me wel opgevallen dat je jouw nickname hebt veranderd ;-)

Aaai, heb ik meerdere wijzigingen tegelijkertijd doorgevoerd? Dat is altijd een risico.
24-10-2019, 17:43 door Q1
Door Erik van Straten: [...]

24-10-2019, door Anoniem: En er speelt nog een verschil: in de Microsoft-wereld is het gangbaar (voor teksteditors etc.) om een tekstbestand te laten beginnen met een byte order mark of BOM. [...]
Je hebt gelijk dat de gebruikte codering o.a. afhankelijk is van de gebruikte teksteditor. en die BOM heb ik vaak eerder gezien. Tot mijn verbazing kreeg ik die BOM niet meer gegenereerd met Notepad onder W10 v1903, deze lijkt nu UTF-8 of zo te gebruiken (ik heb dit niet precies vastgesteld).

Die versie van notepad genereert voor de karakters á en à nu DE ENE KEER elk 1 byte (resp. 0xE1 en 0xE0) en DE ANDERE KEER 2 bytes (resp. 0xC3A1 en 0xC3A0). Ik begrijp nog niet wat de criteria zijn voor deze keuze, maar in elk geval maken dat soort verschillen digitale handtekeningen natuurlijk kansloos (niet alleen ik liep er tegenaan bij 0xC3A1 vs. 0xE1 voor á, zie https://stackoverflow.com/questions/26390313/get-non-ascii-character-from-single-character-code).

Zie wikipedia: https://en.wikipedia.org/wiki/UTF-8


Many Windows programs (including Windows Notepad) add the bytes 0xEF, 0xBB, 0xBF at the start of any document saved as UTF-8. This is the UTF-8 encoding of the Unicode byte order mark (BOM), and is commonly referred to as a UTF-8 BOM, even though byte order is irrelevant to UTF-8. While ASCII text encoded using UTF-8 normally is backwards compatible with ASCII, this is not true when Unicode Standard recommendations are ignored and a BOM is added. Non-UTF-8 software may show the BOM as three garbage characters, e.g. "" in software interpreting the document as ISO 8859-1 or Windows-1252, and "???" if interpreted as code page 437.
Ofwel: afhankelijk van de UTF-8 BOM interpreteert notepad de tekst en gebruikt de betreffende codering. Zet het maar in een tekstfiletje, en voeg daarna met een HEX editor de UTF-8 BOM als eerste karakters toe. Ineens een heel andere letterset :-)

Dat was waar ik ondermeer in een eerdere post naar verwees: een tekst met de letter "á" gecodeerd met "0xE1" en dezelfde tekst met "0xC3A1" ziet er voor een gebruiker echt identiek uit maar de hash is echt verschillend.

(en ja, hier heb ik me eens volledig suf op gestaard: een text compare gaf aan identiek, de hash was verschillend, en ja, een binary compare was verschillend. Je ziet het pas in een binary/hex editor)

Fix: uitsluitend ASCII 32 t/m 126 gebruiken? Of in BASE64 posten? Beide worden geen succes wordt vermoed ik...
:-)


Q
02-11-2019, 08:57 door Anoniem
allemaal leuk een aardig, maar als ik een hash kan aflezen van iemand; dan heb ik de volgende hash die hij/zij gaat gebruiken eenvoudig gevonden door slechts te hashen en dat stelt mij in staat als die persoon te posten. die hash bewijst mij dus helemaal niets op die manier.
02-11-2019, 20:46 door Anoniem
Door Anoniem: allemaal leuk een aardig, maar als ik een hash kan aflezen van iemand; dan heb ik de volgende hash die hij/zij gaat gebruiken eenvoudig gevonden door slechts te hashen en dat stelt mij in staat als die persoon te posten. die hash bewijst mij dus helemaal niets op die manier.
Goh ik krijg opeens een idee....Als je nu eens laten we zeggen 10 hashes genereert (hash van hash van hash enz.)
en bij de eerste post vermeld je de tiende hash, bij een volgende post de negende hash. (iemand kan zien dat de hash van de negende hash als resultaat de tiende has oplevert, dus het is van dezelfde persoon) enzovoorts.
Want een hash van een hash berekenen kan iedereen,
maar een hash terugrekenen niet. Want dat is nu net het kenmerk van een hash.

(ho wacht... wat zei die Erik ook alweer?)
02-11-2019, 21:22 door Erik van Straten
Door Anoniem: allemaal leuk een aardig, maar als ik een hash kan aflezen van iemand; dan heb ik de volgende hash die hij/zij gaat gebruiken eenvoudig gevonden door slechts te hashen ...
Klopt, daarom is het de bedoeling is dat je steeds de vorige (i.p.v. de volgende) hash post.
03-11-2019, 15:37 door Anoniem
Inderdaad.. question everything...(Russia Today)
03-11-2019, 15:42 door Anoniem
Door Anoniem: allemaal leuk een aardig, maar als ik een hash kan aflezen van iemand; dan heb ik de volgende hash die hij/zij gaat gebruiken eenvoudig gevonden door slechts te hashen en dat stelt mij in staat als die persoon te posten. die hash bewijst mij dus helemaal niets op die manier.

Goed lezen wat Erik schrijft. Het gaat niet om de volgende maar vorige hashes..

Dat systeem is goed genoeg tenzij je de NSA of Moscow als tegenstander hebt die met supercomputers terugwaartse hashes kunnen berekenen. Die kans is klein want je moet de precieze hash vinden en geen collision in een ander stringformat.

"Question Everything"
04-11-2019, 12:15 door Anoniem
Ik blijf liever anoniem, anders had ik dit wel onder een account gepost.
04-11-2019, 13:33 door Erik van Straten
Door Anoniem: Ik blijf liever anoniem, anders had ik dit wel onder een account gepost.
Verstandige keuze, want nu weten we niet wie we uit moeten lachen voor het intrappen van deze open deur.
04-11-2019, 15:09 door Anoniem
Door Anoniem: Ik blijf liever anoniem, anders had ik dit wel onder een account gepost.

#metoo
04-12-2019, 12:15 door Q1
Even een idee:
In je voorstel propageer je een methode om bij anonieme posts wel te kunnen zien of posts bij elkaar horen (van dezelfde poster zijn). Ik postte ook veelal anoniem omdat dat zo makkelijk is, terwijl ik wel de meerwaarde zie van posts waar ik de auteur van weet.
Het was voor mij de aanleiding om na te denken over anonieme posts: het is erg laagdrempelig, met als gevolg dat ze ook regelmatig best irrelevant zijn. Daarom lees ik liever posts van mensen "met naam": dan weet ik van te voren of het de moeite waard is om te lezen. Het mag anoniem zijn in de zin van dat ik niet weet WIE het is, maar wel of het steeds dezelfde is, ofwel een nickname mag ook (doe ik ook). Bovengenoemd systeem leek daar een voorzet toe.

Een andere benadering (dan de door Erik genoemde signing) is het stimuleren van niet-anonieme gebruikers, door geregistreerde gebruikers iets extra te geven. Ik denk bv. aan een "like" achtige functie, en dan bv. een tellertje met "Eens" of "Informatief", waar je als geregistreerde gebruiker op kan klikken. Dan komen interessante posts eerder naar voren, zowel anonieme als van geregistreerde gebruikers. Je krijgt dan inzicht in de kwaliteit van antwoorden van geregistreerde gebruikers, maar wordt ook gewezen op interessante posts van anonieme gebruikers. Op die manier kan ik mijn tijd op dit forum efficiënter gebruiken.

Wat vinden jullie hiervan?
04-12-2019, 13:42 door [Account Verwijderd]
Door Q1: Even een idee:
In je voorstel propageer je een methode om bij anonieme posts wel te kunnen zien of posts bij elkaar horen (van dezelfde poster zijn). Ik postte ook veelal anoniem omdat dat zo makkelijk is, terwijl ik wel de meerwaarde zie van posts waar ik de auteur van weet.
Het was voor mij de aanleiding om na te denken over anonieme posts: het is erg laagdrempelig, met als gevolg dat ze ook regelmatig best irrelevant zijn. Daarom lees ik liever posts van mensen "met naam": dan weet ik van te voren of het de moeite waard is om te lezen. Het mag anoniem zijn in de zin van dat ik niet weet WIE het is, maar wel of het steeds dezelfde is, ofwel een nickname mag ook (doe ik ook). Bovengenoemd systeem leek daar een voorzet toe.

Een andere benadering (dan de door Erik genoemde signing) is het stimuleren van niet-anonieme gebruikers, door geregistreerde gebruikers iets extra te geven. Ik denk bv. aan een "like" achtige functie, en dan bv. een tellertje met "Eens" of "Informatief", waar je als geregistreerde gebruiker op kan klikken. Dan komen interessante posts eerder naar voren, zowel anonieme als van geregistreerde gebruikers. Je krijgt dan inzicht in de kwaliteit van antwoorden van geregistreerde gebruikers, maar wordt ook gewezen op interessante posts van anonieme gebruikers. Op die manier kan ik mijn tijd op dit forum efficiënter gebruiken.

Wat vinden jullie hiervan?

@Q1,

Een levensvatbaar idee! Ik ben weer niet iemand die heel diep gaat nadenken over de eventuele voordelen of nadelen. Maar waar ik geen voorstander van ben is een mogelijkheid om 'dislike posts' chronologisch lager in de rij te paatsen. Een onderscheid zoals op eBay waar je een knop hebt om hetzij alle positieve, ofwel negatieve, danwel neutrale beoordelingen op te roepen is dan weer wel zinnig.

Mijn motivatie om dit een aardig idee te vinden ligt ook in het feit dat ik niet meer reageer op anonieme posts zeker als zij in mijn visie nogal ehh... negatief zijn. Een andere reden is dat in een lopende discussie het best mogelijk is dat je op twee anoniemen reageert in de veronderstelling dat het dezelfde persoon is. Trolgedrag vermijd en negeer ik op die manier.
05-12-2019, 11:43 door Anoniem
Ik vraag me toch sterk af wat het probleem is dat door de voorgestelde cryptografische technieken moet worden opgelost want is er, buiten een gefrustreerde enkeling, überhaupt een probleen met anonieme reacties?
Security.nl staat toe dat anoniem gereageerd kan worden en deze reacties worden pas geplaatst als deze ontopic zijn. Als Security.nl alleen reacties met account zou toestaan zou dat inmiddels in effect zijn geweest.
Het is niet verplicht om Security.nl te bezoeken. Als je niet met anonieme reacties kan leven dan staat niets je in de weg om een eigen Security website te beginnen waar je alleen met "the chosen ones" kunt communiceren.

En ja, sommige reacties zijn behoorlijk off-topic of zelfs vervuilend (zeker die onzinnige Linux vs. Windows discussies) maar dat zijn ook veel reacties van accounthouders, want daar zit namelijk geen moderatie op wanneer deze geplaatst worden. Het is maar hoe druk je jezelf wilt maken of hoe kort je lontje is.
Daar kun je overigens ook hulp bij vragen om daarmee te leren omgaan.
05-12-2019, 14:37 door Anoniem
Af en toe, zo ook in, is er op security.nl onduidelijkheid of een anonieme bijdrage van de hand van dezelfde persoon is als een eerdere anonieme bijdrage.

Triest, dit soort posts. Geen enkel respect voor de keuze van je medegebruikers. Jij bepaalt of jij anoniem post, ik bepaal of ik anoniem post.
05-12-2019, 14:41 door Anoniem
In principe zou je van dat gedonder af zijn als iedereen de moed had om een account te maken en gebruiken, maar kennelijk wil niet iedereen dat en bovendien is zelfs dan nog verwarring mogelijk...

Kennelijk vindt de redactie van security.nl het ook geen probleem, want anders zouden ze anoniem reageren wel uitschakelen. Wie ben jij, om dit gedonder te noemen, en andere bezoekers te vertellen wat ze moeten doen ?

Ben je het er niet mee eens, mail de redactie.
05-12-2019, 18:21 door Erik van Straten - Bijgewerkt: 05-12-2019, 18:34
@Anoniemen vandaag 11:43, 14:37 en 14:41: ik schrijf nergens dat ik geen anonieme bijdragen wil (sterker, ik post zelf ook wel eens anoniem).

Het enige dat ik, als gedachtenspinsel, beschreef was een systeem waarbij een anonieme bijdrager, desgewenst, zelf kan aantonen dat 2 of meer bijdragen van zijn of haar hand zijn zonder zijn of haar identiteit prijs te geven. Dat zou in het belang van de lezers kunnen zijn, maar ook in het belang van de betreffende anoniem zelf (niet alleen op security.nl, maar wellicht ook handig voor klokkenluiders, dissidenten, tipgevers en journalisten). Op security.nl o.a om te voorkomen dat je met een andere anoniem wordt verward - bijvoorbeeld omdat je net zo dyslectisch bent als een andere Anoniem, er een vergelijkbare schrijfstijl op nahoudt, en/of ergens ogenschijnlijk hetzelfde -maar op details ander- standpunt inneemt (bijvoorbeeld openlijk anti-Microsoft bent, maar *BSD prefereert boven Linux).

Kortom, er moet niks, wat ik voorstelde is volstrekt vrijblijvend (zo schreef ik onder meer: "Ik verwacht niet dat alle anoniemen hierop duiken en lezers voortdurend met cryptografische hashes in de weer zijn"), en ik probeer juist mogelijkheden te creëen om anoniem te blijven en desgewenst een van de nadelen daarvan te mitigeren.

Waarom dan dat gejank? Waarom niet alles lezen wat ik schreef maar mij wel afzeiken? Waarom laat Anomiem van 14:37 opzettelijk "[1]" weg bij het quoten van mijn tekst? Triest dit soort posts, duidelijk geschreven door trollen, en m.i. onterecht door de moderator(en) doorgelaten - iets dat steeds vaker lijkt te gebeuren op deze (m.i. -helaas- zinkende) site.

P.S.
Als je niet met anonieme reacties kan leven dan staat niets je in de weg om een eigen Security website te beginnen waar je alleen met "the chosen ones" kunt communiceren.
The thought crossed my mind.
05-12-2019, 23:19 door Anoniem
Tijdje niet geweest. Ik bespeur steeds meer vaker topics op dit forum, van regelrecht aluhoedje gehalte tot "q" en "qanon" alt-right supporters. Brrrr..

Tijd om maar eens afstand te nemen van deze site en de "buitenlandse" gaslightende trollen die overigens perfect Neerlands spreken want het zijn net buren met hun lokaal dialect...

Mvgr,
Ron vd.


P.s. Het is een heel interessant idee van Erik van Straten. Ik zou zelf geen toepassing weten en blijf voor mijn beperkte internet activiteiten gewoon bij PGP voor wie het leuk vind om daar uit principe (omdat de mogelijkheid bestaat) gebruik van te maken zoals in 1995 toen PGP signing bijeenkomsten zeer populair waren. Uit principe en voor de fun natuurlijk.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.