Eh... Ze adviseren Skype om "secure" te bellen? WTF??? Is toch allang bekend dat Microsoft (en wie nog meer?) toegang heeft tot de gesprekken...

Waar zie je dat ze Skype 'adviseren'?
Van Skype wordt er duidelijk gezegd:
Daarna worden er een aantal veiligere alternatieven genoemd.

https://toolbox.bof.nl/tools/skype/

Moet zeggen, het staat er wat onduidelijk. Er staat dat je met skype gratis kan bellen, maar dat het geen privacy vriendelijke tool is.

Dit staat er als je netjes het stukje helemaal leest:

er staan wel meer dingen in waar je je vraagtekens bij kan zetten. Voor deze community is dit misschien niet toereikend en zelfs niet altijd kloppend. Maar voor de standaard gebruiker die nog nooit bij dit soort risico's heeft stilgestaan is het wel een goede start.

Volgens bronnen (tijdens NCSC ONE) is de aanschaf van Skype door Microsoft in opdracht van de NSA gebeurd. Men was bang dat de beveiliging te goed zou worden als het niet door een Amerikaans bedrijf zou worden uitgevoerd. De actie om alle supernodes vervolgens binnen het netwerk van Microsoft te plaatsen, was een logisch vervolg daarop.

Peter

Huh, de 'Internetvrijheid Toolbox' van BOF bestaat toch al een paar jaar? Een update dunkt me..

Van de website over Veracrypt:

"Veracrypt en de cloud

Veracrypt is minder geschikt om (grote) dataverzamelingen versleuteld op te slaan bij een cloudaanbieder. Alleen als de dataverzameling een nooit wijzigend archief is, kan Veracrypt hier goed voor worden ingezet. Elke wijziging aan het archief vereist namelijk dat het bestand in zijn geheel weer opnieuw moet worden verstuurd naar de cloudaanbieder."

Dat klopt niet. Als je bijvoorbeeld een Veracrypt vault op een cloudstorageprovider hebt staan als Dropbox, en je wijzigd wat aan de inhoud van deze vault, dan zul je zien dat alleen de gewijzigde blokken (zoals in de AES structuur ook logisch is) opnieuw versleuteld worden en dus veranderen. Dropbox (in ieder geval) heeft de intelligentie aan boord om te zien dat niet de complete file is verandert, maar slechts een gedeelte, en zal dus ook alleen de wijzigingen uploaden en niet de complete file.

Dank voor deze opmerking. Ik vermoed dat je gelijk hebt. Maar het is de vraag of je daar blij van moet worden...

Als een aanvaller meerdere versies van een encrypted file (of schijf image) in handen heeft, waarin op specifieke plaatsen wijzigingen optreden, zou dat wel eens kunnen helpen bij cryptanalysis. Vooral als de aanvaller (ongeveer) weet wat er gewijzigd is (bijv. omdat dit uit andere gegevens, zoals een blog, valt af te leiden).

Bewijzen kan ik dit niet, maar het voelt in elk geval "niet goed".

Sophos - internet monitoring
Utimaco Safeware (Sophos) - internet monitoring / phone monitoring

https://wikileaks.org/The-Spyfiles-The-Map.html
Internet monitoring / UK

DPI Overview
https://wikileaks.org/spyfiles/files/0/53_200906-ISS-PRG-UTIMACO.pdf

Telecom Data Retention / Future Lawful interception
https://wikileaks.org/spyfiles/files/0/54_200906-ISS-PRG-UTIMACO2.pdf

@Erik,

Helaas is een 'gevoel' niet echt bepaald exacte wetenschap, en is er gewoon een logische en technische verklaring voor wat er gebeurt.

Enerzijds zit dat in de gebruikte encryptiemethode. AES is een zogenaamd block cypher. Dat betekend dus letterlijk dat het data in blokken opdeelt, en dan per blok de versleuteling toepast. In geval van AES is dat altijd 128 bits (niet te verwarren met keysizes, die kunnen zijn 128, 192 of 256 bits).

Een True/Veracrypt container werkt netjes volgens dit systeem. Stel je creeert een 10 megabyte container, dan krijg je ook daadwerkelijk een 10 megabyte bestand op je computer, of je hier nu wel of geen data hebt ingezet. Dat is juist een indicatie dat er geen sprake is van cryptoanalyse, maar daar kom ik later op terug.

Goed, als je dus zo'n container opent, er wijzigingen in aanbrengt, en daarna weer afsluit, dan zal True/Veracrypt in samenwerking met de crypto netjes die blokken opnieuw versleutelen die zijn aangepast door de wijzigingen. Alleen die data in de container die is aangepast (de delta) zal opnieuw worden versleuteld, en alleen die blocks zullen dus op de disk worden aangepast (in blokken van 128 bits).

Als je dan uiteindelijk zo'n bestand zou analyseren (op block level) dan kun je inderdaad de aangepaste delen van het bestand terugzien. Hier is niks aan de toen, je besturingssysteem en je bestandssysteem moeten immers nog steeds handelingen verrichten met die data. En dat geeft verder ook niet, want het is immers versleutelde data.

En van dat gegeven maakt Dropbox dus gebruik. Maar ook vrijwel alle moderne back-up en imaging tools (rsync bijvoorbeeld) doen bewerkingen op block-level ipv file-level. Computers zijn tegenwoordig snel genoeg om data op block level in te lezen en direct te analyseren, zodat alleen de aanpassingen (delta's) worden gekopieerd. Dat is aanzienlijk sneller dat alle bestanden afzonderlijk 1 voor 1 te benaderen en te kopiëren.

Over die cryptoanalyse hoef je je niet druk te maken. Althans, zolang deze maar niet ECB Mode gebruikt. Want dan krijg je inderdaad bij het gebruik van dezelfde sleutel over dezelfde data, dezelfde cryptotext als output. Maar als de IV uniek en 'random' genoeg is, dan heeft cryptoanalyse op AES helemaal geen zin.

Dank voor jouw uitgebreide antwoord, maar mijn zorgen zijn niet weg.

Als Veracrypt filecontainers op dezelfde wijze behandelt als reeksen (fixed-size) sectors zoals bij FDE, zou dat kunnen betekenen dat er geen (variable-size) ruimtes met random bytes worden tussengevoegd, en er van AES in XTR mode gebruik gemaakt wordt. Als dat zo is, lees dit: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/.