'Rusland kraakte encryptie FBI-communicatie'

De Russische inlichtingendienst zou er vanaf 2011 in geslaagd zijn om de versleutelde communicatie van mobiele surveillanceteams van de FBI in te zien. Ook het back-upsysteem zou daarna niet veilig zijn geweest.

Russische spionnen konden dankzij het kraken van de encryptie de radiocommunicatie van de lichtgewicht radiosystemen die FBI-teams bij inlichtingenoperaties gebruiken inzien. De communicatie onderschepten ze onder andere met mobiele afluisterstations: spionnen liepen, of reden met busjes naar een plek in de buurt van de FBI-teams. De acties van de Russen hinderden de mogelijkheden van de FBI om de locaties en bezigheden van Russische spionnen op Amerikaans grondgebied te achterhalen. De Russen zouden zo inzicht hebben gekregen in tactieken en samenstellingen van de Amerikaanse teams.

Of ze de communicatie in real-time konden kraken is niet bekend. De FBI zou lang in het duister hebben getast over hoe Rusland de versleuteling ongedaan kon maken. De faciliteiten van Russische diplomaten in de Verenigde Staten speelden eveneens een rol als afluisterstation bij het onderscheppen, verwerken en kraken. Daaronder vielen twee locaties in Maryland en New York die Rusland in 2016 op last van toenmalig president Obama moest ontruimen waarbij hij tientallen Russische diplomaten 72 uur de tijd gaf om het land te verlaten.

Naast de radiocommunicatie konden de Russen ook het back-upsysteem van de FBI met succes onderscheppen. Dit systeem bestond uit telefoons met walkie-talkie-achtige eigenschappen. De Russische inlichtingendienst kon die telefoons identificeren en de signalen opvangen.

De bevindingen blijken uit gesprekken die Yahoo News met meer dan vijftig medewerkers en voormalige personeelsleden van inlichtingen- en beveiligingsdiensten hield. Enkelen wijzen erop dat het kunnen kraken in de hand is gewerkt door het gebruik van gebrekkige, ineffectieve systemen door de FBI. Er zou een geïntegreerde infrastructuur voor de communicatie gebouwd worden, maar deze kwam niet van de grond.

Reacties (61)

[gertvdijk]

Al in 2011 verscheen er een paper over de gebruikte apparatuur (P25) met alarmerende resultaten over de veiligheid. Draadje op Twitter.

quote: https://twitter.com/mattblaze/status/1173581533405487105

No one can say they weren’t warned.

Het is onduidelijk in hoeverre deze toen ontdekte zwakheden verband houden met wat hier precies heeft afgespeeld, maar het geeft wel een beeld...

[Reactie gewijzigd door gertvdijk op 23 juli 2024 13:03]

[vliegendekat]

Het is onduidelijk in hoeverre deze toen ontdekte zwakheden verband houden met wat hier precies heeft afgespeeld, maar het geeft wel een beeld...

Als u de wikipedia-pagina over het radioprotocol even opzoekt en doorleest, ontdekt u dat er werd gewerkt met DES-OFB en dus met een effectieve keysize van 56 bits, of met ADP, een eigen protocolletje van Motorola dat gebaseerd is op RC4. Wat ik zo snel online kan vinden over de gebruikte sleutellengte, lijkt heel erg op een lengte van 64 bits.

Aangezien men DES-sleutels vaak doorgeeft als 64 bits getallen met elke 8-ste bit als pariteitsbit, lijkt het erop dat men gewoon een geheugen van 8 bytes per radio in de radio-groep heeft gebruikt voor de versleuteling.

We hebben dus meer dan genoeg informatie en aangezien de EFF in 1998 al een DES-cracker kon bouwen die het spul in 56 uur kon kraken. Een half jaar later ging het al over 22,5 uur.

Ik denk dat wij dus gewoon aan moeten nemen dat de Russen realtime, of met een zeer kleine vertraging, mee konden luisteren met het radioverkeer van de FBI. In mijn ogen is er namelijk meer dan genoeg technische informatie beschikbaar.

[ymmv]

Israël is ook betrapt in de VS, maar aangezien Israël een bondgenoot is wordt dat nieuws vakkundig gesmoord door alle partijen.

https://www.bbc.com/news/world-us-canada-49678034

[grimlock]

Ach, Engeland zat ook in België, de VS bij Merkel op haar telefoon. Nederland legt de Iraanse kerncentrales plat voor de VS. Nederland komt binnen bij het hackersclubje van Rusland. De Russen zitten weer in Nederland. Het enige dat me grappig leek was dat Blackberry vroeger van Saudi Arabië de opdracht kreeg om de encryptie open te stellen. Ofwel, iedereen leeft zich uit, het is een grote wereld en de informatie ligt overal voor het grabbelen. En als het niet lukt om te hacken dan gaan we de leverancier wel onder druk zetten.

[Verwijderd]

Nederland legt de Iraanse kerncentrales plat voor de VS? Nou ho ho. Zo is dat dus niet gegaan.
Het virus schrijven, is niet volledig door NL gedaan en diegene die het hoogstwaarschijnlijk heeft geplaatst is een Iraniër. Nederland heeft mee gewerkt ja, maar niet net als USA, zo arrogant zeggen: kijk hoe goed ons land is en wat we hebben gedaan.

[netfast]

"kijk hoe goed ons land is en wat we hebben gedaan"

Ik vind er anders helemaal niks goeds aan... We zouden allemaal eens moeten stoppen met deze oorlog onzin. Kan er niet echt trots op zijn eigenlijk....

[Vayra]

Helaas zit zo de wereld niet in elkaar...

Wees maar blij dat we die kennis hier hebben en dat die loyaal aan ons is. De beste verdediging is de aanval en afschrikking.

[Reactie gewijzigd door Vayra op 23 juli 2024 13:03]

[netfast]

Daar ben ik me erg van bewust ;-)
Vond meer het trots zijn op opvallend...

[The Zep Man]

Enkelen wijzen erop dat het kunnen kraken in de hand is gewerkt door het gebruik van gebrekkige, ineffectieve systemen door de FBI.

Handig om gesloten (implementaties van) encryptiealgoritmes/protocollen te gebruiken, in plaats van te leunen op breed getoetste en toetsbare open standaarden.

[dasiro]

ik vermoed dat een volledig custom onbekend protocol veiliger is dan een open standaard, maar dat wil niet zeggen dat je beiden niet kan combineren.

[ATS]

Dat is een denkfout. Een open protocol heeft het grote voordeel dat er vele onafhankelijke experts naar kunnen kijken en zwakheden identificeren. Bij een gesloten standaard is dat per definitie niet mogelijk. Een goed protocol zit zo in elkaar dat het prima is dat het protocol te kennen zolang de sleutel geheim is.

[Stiggy]

Dat is ook een denkfout. Dat het kan wil niet zeggen dat het gebeurt. Het aantal mensen dat naar source code van anderen wil kijken is sowieso beperkt. Het aantal mensen dat er verstand van heeft en genoeg in de code zit om een security risk op te merken nog veel kleiner. Vandaar dat ook in open source software security issues soms heel lang kunnen zitten (b.v. HeartBleed).

[GeoBeo]

Het aantal mensen dat naar source code van anderen wil kijken is sowieso beperkt. Het aantal mensen dat er verstand van heeft en genoeg in de code zit om een security risk op te merken nog veel kleiner.

Niet als verschillende overheden miljarden uitgeven om elkaars encryptie te kunnen ontcijferen.

Internet staat vol met informatie als deze over hoe veel gebruikte (verouderde) encryptie gehacked kan worden. Het zou mij echt helemaal niets verbazen als de FBI oude apparatuur gebruikte die zelfs jij en ik na het lezen van een hackers uitleg zouden kunnen hacken.

Er zijn professionele hackers die lekken vinden. En daar tonnen mee verdienen.

Er zijn professionele criminele hackers die lekken vinden en doorverkopen aan bepaalde bedrijven (die ze weer doorverkopen aan overheden). En daar miljarden mee verdienen.

En er zijn geheime diensten die miljarden uitgeven aan o.a. het vinden van lekken in encryptie.

En dan heb je nog de bedrijven die de software en hardware ontwikkelen (de "slachtoffers" van de hackers), waar ook miljarden in om gaan en die ook hun eigen experts in dienst hebben die niets anders doen dan cryptografie. Apple, Facebook, Telegram, Google, makers van defensie apparatuur (Thales e.d.), Tesla, "the military industrial complex" en ga zo maar verder.

Dus als je denkt dat de hoeveelheid mensen "die naar source code kan en wil kijken" of kan uitvogelen hoe encryptie in elkaar zit "beperkt" is dan schat je dat een heel klein beetje verkeerd in. Om het zachtjes uit te drukken.

Het is onder crypto experts de consensus dat "zelf gebakken" (closed source) encryptie eigenlijk per definitie gehacked kan worden. Omdat er simpelweg veel te veel haken en ogen aan het complete encryptie en decryptie systeem zitten om niet een paar steken te laten vallen. Cryptografie die "goed" gevonden wordt zijn systemen waar 100'en experts op verschillende gebieden jaren lang aan gewerkt hebben.

Dat ga je echt niet kunnen evenaren in een middelgroot bedrijf door je brakke verzinsel simpelweg "geheim te houden". Dit is 1 van de redenen, waarom die community zo'n kritiek heeft op het eigen-baksel van bijvoorbeeld Telegram.

"There are 2 types of organizations in the world: those who where hacked and those who didn't know they where hacked."

[Reactie gewijzigd door GeoBeo op 23 juli 2024 13:03]

[SPT]

Jullie maken allebei een denkfout. Je kan een custom protocol combineren met een bestaand protocol, en zo de voordelen van beide systemen combineren. Het ontwikkelen van een custom protocol is dus zeker waardevol.

[BeosBeing]

Als je een veilig open protocol gebruikt in combinatie met een eigen gemaakt geheim protocol (bv twee maal encrypten) en die tweede blijkt een gat te hebben, dan kan het zijn dat men door dat gat de inhoyd kan inzien en dus dat gat dus ook de beveiliging met het goede protocol compromitteerd.

Kraken gaat o.a. met pattern search en als er door de tweede encryptie een patroon ontstaat terwijl er dat na de eerste encryptie niet was, dan kan dat nu net hetgeen zijn waardoor men de sleutel vind.

[CAPSLOCK2000]

We moeten hier even onderscheid maken tussen code (de implementatie) en algoritmes (de wetenschap er achter). De algoritmes die in praktijk voor encryptie gebruikt worden, zijn over het algemeen goed bestudeerd en jarenlang getest door crypto-wetenschappers. Het is een bijzonder moeilijk onderwerp, en het is echt nodig om met heel veel wetenschappers naar die algoritmes te kijken om er op te kunnen vertrouwen dat er geen fouten in zitten. Het proces duurt vele jaren en de meeste algoritmes vallen voortijdig af. Wat na al die jaren overblijft is over het algemeen best aardig, de meest gebruikte standaarden gaan vele jaren mee.

De praktische implementatie van die algoritmes is helaas een ander verhaal. Er is ontzettende veel software dat die crypto-algoritmes implementeert, maar de kwaliteit is nogal, eh, wisselend. Het ontwikkelproces gaat veel sneller (dagen of maanden, geen decennium) en er zijn maar weinig gekwalificeerde mensen om het werk te controleren.

[ATS]

Dat is bij encryptie (en hashing) algoritmes dus zeker wel het geval. Die worden heel, heel uitgebreid bestudeerd.

[Verwijderd]

Dat zou je denken he? Maar elke blijkt weer er gewoon heel weinig mensen zijn die WERKELIJK naar open source kijken. Het feit dat de mensen die aan encryptie werken meestal erg ambitieus zijn is de redding van veel protocollen.

[ANdrode]

Tijdens het ontwerp van encryptie en hashing algoritmes wordt er zowel vanuit academia als daarbuiten heel uitgebreid naar de veiligheid gekeken. Neem bijvoorbeeld het NIST Post-Quantum Cryptography traject.

Tegelijkertijd wordt er zeer beperkt naar de implementaties van deze cryptografie in open source systemen gekeken. En de partijen die echt zekerheid willen kijken niet naar OpenSSL maar naar hun eigen library. Want je moet bij elke wijziging naar het hele systeem kijken…

[sebastienbo]

Je vergelijkt appelen met peren.

Heartbleed was geen open source algoritme
Het was een open source applicatie dat een zwakte had door haar implementatie naar geheugen toe.
Een applicatie bevat miljoenen algoritmen waardoor je er wel eens iets in kan missen.
Bij security algoritmen heb je heel de wereld die kijkt naar één klein stukje code.

Bij gesloten algoritmes vind je altijd iets om te misbruiken,en het valt niet op want niemand mag het evalueren

[Terrestrial]

Ik zou ook kiezen voor een custom oplossing en niet direct niet opensource, hoewel het best een combinatie kan zijn. . Vaak is het probleem niet eens het algoritme maar de implementatie er van in de apparatuur die slecht is uitgevoerd. SoC met een lek of bug er in, 1x jatten en uitlezen is genoeg om de operationele sleutel te krijgen. Sleutel wisselen is mogelijk maar lastig en dan nog.. misschien hebben ze een hash table.

[DigitalExorcist]

Niemand is verantwoordelijk voor de code. Als iedereen inderdaad denkt dat een ander de code wel kent, kent niemand ‘m...

[EraYaN]

Ik denk dat je even een random stukje code van een random programma door de war haalt met de kernel die de daadwerkelijke encryptie doet, ga er maar van uit dat die per operatie volledig is doorgelicht door duizenden personen. Puur en alleen al omdat er zoveel te halen valt als jij bijvoorbeeld even een veel gebruikte AES implementatie onderuithaalt.

[DigitalExorcist]

Ja, en wie kent de vollédige code? Als onderdeeltje x aangepast wordt, wie kan dan alle gevolgen overzien van het geheel?

[EraYaN]

AES kernel implementatie past in enkele honderden regels code in puur C. Het is allemaal niet zo heel ingewikkeld omdat zo'n implementatie geschreven als er dan na jaren de wiskundige algoritmes ontworpen zijn. Dus ik denk dat er best wel een hoop mensen zijn die de "hele" code kennen.

Kijk bijvoorbeeld hier: https://github.com/openss...ter/crypto/modes/cbc128.c de OpenSSL implementatie van AES 128 CBC. Dat stukje kun je echt wel checken op correctheid hoor.

[TweakerNummer]

En toch werkt het niet. Pas bij correct toegepaste formele verificatie (eerst op de compiler en daarna op de kernel) krijg je de implementatie sluitend. En wiskundig krijg je het waarschijnlijk nooit sluitend. En ja, deze case studies bestaan.

[Reactie gewijzigd door TweakerNummer op 23 juli 2024 13:03]

[EraYaN]

Daar verplaats je de doelpalen dan toch wel even een heel eind. "Volledig sluitend" bestaat natuurlijk niet binnen software, zelfs als je echt lekker gaat met je modellen maken gaat het daar ook vaak mis. Maar dat hoeft ook helemaal niet. En een closed source implementatie doet dat ook niet veranderen of iets dergelijks.

En gelukkig toont de praktijk aan dat het wel werkt, dus "En toch werkt het niet" is een beetje te voorbarig vooral als jij dan dus beweert dat jij een probleem kent in (deze implementatie van) AES128-CBC. Je kon nog wel eens verrast staan hoeveel zeer invloedrijke figuren je dan interessant zullen vinden.

[TweakerNummer]

Ik heb het over het menselijke checken van correctheid van code, niet over de implementatie van AES-128-CBC in OpenSSL.

In de praktijk laat OpenSSL ook gewoon audits uitvoeren dus code kwaliteit zal over het algemeen wel hoog zijn.

[Reactie gewijzigd door TweakerNummer op 23 juli 2024 13:03]

[Marty007]

Je hebt het over Een geheime dienst die een andere geheime dienst hackt...
Hoe kom jij in hemelsnaam bij "het aantal mensen die de code bekijkt etc..Is beperkt"???
Dit is wat die gasten doen met hele afdelingen tegelijk... overal beperkt maar hier geconcentreerd.

De beste beveiliging is plain sight.. daar waar iedereen de bron kan zien, elke fout die jij ziet zal ook door anderen gezien worden.
Bij een gesloten systeem is het simpelweg eenmaal aangeleerd en begrepen een zeer kleine omgeving waar slechts weinig partijen mee kijken, een fout vinden kan tussen twee partijen decennia zijn waar dit met open source over het algemeen wel een decimaal minder is in erge gevallen.

[kozue]

Maar dan nog blijft het feit dat die algoritmen ontworpen zijn om veilig te blijven wanneer de implementatie algemeen bekend is. Dat kun je niet zeggen van een custom oplossing die er op leunt dat niemand deze implementatie kent. Security by obscurity werkt niet, dat hebben DRM systemen al volop bewezen.

[DigitalExorcist]

Goeie security werkt wel. En goed opgeleide medewerkers. Het een kan niet zonder het ander.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 13:03]

[CivLord]

Dat is een denkfout. Een open protocol heeft het grote voordeel dat er vele onafhankelijke experts naar kunnen kijken en zwakheden identificeren. Bij een gesloten standaard is dat per definitie niet mogelijk. Een goed protocol zit zo in elkaar dat het prima is dat het protocol te kennen zolang de sleutel geheim is.

Het voordeel is dat vele onafhankelijke experts dat kunnen doen. Feit is dat slechts enkelen dat ook daadwerkelijk doen, omdat dat veel werk is dat erg kostbaar is. Er zijn echter wél vele afhankelijke experts (van organisaties die geïnteresseerd zijn in bv. de communicatie van de FBI) die met vrijwel onbeperkte middelen en mankracht het protocol onderzoeken en gevonden kwetsbaarheden voor zichzelf houden.
Closed source is niet inherent beter. Het eerste initiële product van open source en closed source zal ongeveer even goed zijn. Maar bij closed source is de ingang voor kwaadwillenden een stuk lastiger. Bij open source is er een kans dat een grote kwetsbaarheid snel door een onafhankelijke expert wordt gevonden en openbaar wordt gemaakt, maar de kans dat het door een kwaadwillende expert wordt gevonden die het niet openbaar maakt is even groot en dat is voor veel veiligheidsexperts een te groot risico.

[TweakerNummer]

Experts bestaan niet. En ook die jij als dusdanig aanwijst maken fouten. En juist bij open source kan je niet voldoende dekking geven over wat er wel/niet onderzocht wordt (want random mensen die ernaar kijken).

[Reactie gewijzigd door TweakerNummer op 23 juli 2024 13:03]

[nobraininvolved]

tenzij ze bij de FBI al weten dat die open protocollen bv zero days hebben die al door andere instanties zoals de NSA gebruikt worden om alles af te luisteren

[monotype]

De voorbeelden die ik persoonlijk ken zeggen me dat het gesloten zijn van standaarden geen extra veiligheid oplevert zolang er mensen zijn met de resources om ze te reverse-engineeren. Zelfs 'hobyisten'(*) kunnen hierin een slag slaan, zoals bij de OV-chipkaart is gebleken: https://wiki.eth0.nl/index.php/OV-chipkaart .
Gebrekkige peer review bij het ontwerp en de implementatie van crypto-systemen zijn een serieus probleem juist bij gesloten standaarden - een denkfoutje of een glitch in de implementatie is snel gemaakt.


(*)zonder de resources van een '3 letter agency'

[dasiro]

daarom ook mijn suggestie om een alternatief protocol ook nog eens te encrypten. Als je complete jitter opvangt zonder te weten volgens welke encryptiestandaard er is gewerkt, laat staan dat je weet hoe die te exploiten of decrypten is, dan is het onbegonnen werk, zelfs voor een '3 letter agency'. Aangezien we over zo'n agency spreken lijkt het me evident dat ze voldoende funding hebben om zoiets op te zetten en zoniet, dan spreken we nog altijd over een overheid die dit voor zo'n agencies zou kunnen.

[PolarBear]

Moet je niet vergeten dat de NSA de middelen en de mensen heeft om een encryptiealgoritme te ontwerpen en valideren. Dat brede toetsen kan in de praktijk maar door een select aantal programmeurs en wiskundige gedaan worden, de Amerikaanse overheid heeft er daarvan wel een aantal in dienst.

[The Zep Man]

De meeste programmeurs en wiskundigen die het kunnen maken, begrijpen en verbeteren zijn in academische kringen, en wisselen daar ook informatie met elkaar uit. Daar kan geen overheid tegenop.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 13:03]

[CivLord]

Maar dat wordt dan enkel toegepast voor een paar soorten van top-secret communicatie. Niet voor de handsets waar misschien wel tienduizenden FBI-agenten mee rondlopen.

[WillySis]

Als men de open standaarden niet vertrouwt (omdat de Russen die misschien kraken) een eigen inferieure encryptie verzinnen is natuurlijk niet handig. Dat zet de deur open voor ouderwets spionagewerk.

[Armin]

Handig om gesloten (implementaties van) encryptiealgoritmes/protocollen te gebruiken, in plaats van te leunen op breed getoetste en toetsbare open standaarden

Maar wie zegt dat dat gebeurd is? Sterke nog, dikke kans dat men juist één van de gangbare protocollen gebruikte. Bij de overheid in de VS is men daar juist erg star/streng in en gebruikt juist bijna enkel oude protocollen die net een jaartje of 10 a 20 ouder zijn dan wat jij en ik op de PC gebruiken.

Bij gebrek aan details gok ik er meer op dat andere zaken de kraak veroorzaakten.

[Skit3000]

Zou de encryptiemethode van de FBI op last van de FBI ook van een backdoor zijn voorzien? [/sarcastisch]

Verder is het apart dat ze schijnbaar vanaf 2011 tot 2016 (of misschien nog later?) van dezelfde encryptiemethode gebruik hebben gemaakt. Zeker met het oog op dat de FBI hun geheimen zo lang mogelijk geheim wil houden zou je verwachten dat ze regelmatig de methode of in ieder geval de sterkte van de gebruikte sleutels aanpassen. Daarnaast begrijp ik niet waarom bij communicatie tussen werknemers van één organisatie als de FBI onderling, geen gebruik gemaakt wordt van een onkraakbare one-time pad.

[Jace / TBL]

Een one-time pad lost weinig op. Dan moet je de sleutels veilig kunnen uitwisselen en die zijn net zo groot als de te versleutelen data zelf. Dus als ze al een methode hebben om veilig de eenmalig bruikbare sleutels uit te wisselen kunnen ze daarmee net zo goed de data zelf versturen.

[Skit3000]

Naar je FBI-kantoor rijden en de twee mensen die later moeten kunnen communiceren, samen in een kamer zetten en twee USB-sticks volzetten met dezelfde random waarden zou het al moeten doen? Als je verwacht dat je komende maand 10GB aan data moet versturen, moet je dus een opslagmedium hebben van 10GB.

[djwice]

En dan tijdens hun slaap, insluipen, kopie trekken en weer ongemerkt vertrekken.
Of.. gewoon bij beide insluipen en USB vervangen door stick met eigen inhoud.
Of.. device die de USB gaat lezen modificeren etc..

[Skit3000]

Maar die problemen heb je sowieso. Het gaat in dit artikel over vermeende zwakheden in de encryptiemethode waardoor het mogelijk is geweest om afgetapte communicatie te decoderen. Als de communicatie was afgetapt doordat op grote schaal is ingebroken terwijl iemand sliep was dat wel de titel geweest en stond dit bericht waarschijnlijk niet op Tweakers.

[CivLord]

Verder is het apart dat ze schijnbaar vanaf 2011 tot 2016 (of misschien nog later?) van dezelfde encryptiemethode gebruik hebben gemaakt. Zeker met het oog op dat de FBI hun geheimen zo lang mogelijk geheim wil houden zou je verwachten dat ze regelmatig de methode of in ieder geval de sterkte van de gebruikte sleutels aanpassen.

De FBI is gewoon een overheidsorganisatie. Dat betekent dat deze apparatuur via een aanbesteding is aangeschaft. Het bedrijf dat met de beste combinatie van een laag bod en goede bull-shit praatjes komt krijgt de aanbesteding. Dat is een lang traject, met over het algemeen veel bijkomende kosten. Die bijkomende kosten zorgen er dan weer voor dat het project over langere tijd wordt uitgesmeerd (er is na de beoogde levensduur van de apparatuur nog geen geld beschikbaar voor een vervangend systeem). Daarna komt een nieuwe langdurige aanbesteding, die wanneer er iets misgaat opnieuw gedaan moet worden. Tegen de tijd dat het oude systeem vervangen gaat worden, is het inmiddels hopeloos verouderd, terwijl gebreken en lekken niet meer gerepareerd worden, omdat het al lang end-of-life is.

[Jace / TBL]

Dat krijg je er nou van Eigenwijs je eigen encryptie verzinnen in plaats van door en door bestudeerde field tested oplossingen te gebruiken zoals AES.

En bij twijfel kun je het ook nog allebei doen, bijvoorbeeld AES en daar dan je eigen enigma verzinsels overheen. Bij geneste encryptie is de ketting zo sterk als de sterkste schakel.

[fastedje]

Ik heb de PDF van gertvdijk bovenaan doorgekeken, maar P25 ondersteund weldegelijk AES encryptie. Het probleem zit hem dus niet in de keuze van de ciphers, maar meer in het nogal chaotisch opgezette protocol en het gebrek aan checksums/MACs die voorkomen dat je de inhoud van berichten kan veranderen.

In dat opzicht vraag ik me af of het niet beter is om packet radio te gebruiken (wat TCP/IP over radio mogelijk maakt), in combinatie met een veelgebruikt en bewezen TLS (zoals bij https) en Perfect Forward Secrecy. Hierbij kan je er wel zeker zijn dat de data onveranderd ontvangen wordt.

[Bielie993]

Klinkt als een James Bond film, maar het is dus de werkelijkheid. We zijn nergens veilig!

[icecreamfarmer]

Meer als the Americans. Sterker nog volgens mij is er een aflevering waar exact dit gebeurd.

[bilbob]

ik ben hartstikke veilig hoor

[Tetraquark]

Het RODE GEVAAR ! ! kruip onder je bankjes kinderen !

[well0549]

Tja de Russen zijn niet achterlijk... Amerikanen dus blijkbaar wel

[icegodd]

"achterlijk... Amerikanen dus blijkbaar wel"

Dat is allang bekend... zie Snowden leaks en Trump/handel oorlog met china.

[MadMarky]

De titel staat niet voor niets tussen quotes, wat had je dan verwacht?
Als je altijd een diep gefundeerd onderzoek verwacht moet je de artikelen die gebaseerd zijn op geruchten maar skippen.

[OxWax]

De titel staat niet voor niets tussen quotes, wat had je dan verwacht?
Als je altijd een diep gefundeerd onderzoek verwacht moet je de artikelen die gebaseerd zijn op geruchten maar skippen.

Ik vind persoonlijk dat Tweakers die maar eens moet beginnen 'skippen' of apart onderbrengen. Het is een techsite.

[Reactie gewijzigd door OxWax op 23 juli 2024 13:03]

[Tetraquark]

Ach ja, copy en paste he, ter opvulling