https://securemessage.nl/

Een kip een ei probleem.

Gewoon voice gesprek, en uitspellen ?

voor deze ene keer gpg inrichten, en emailen met pubkey ? Wel netjes key signature checken van je iemand.

mailen met symmetrische encryptie (kan ook via gpg , openssl, of gewoon zip) , en het password _daarvan_ via voice delen ? (of dan maar via teams ofzo, ander medium dan het oorspronkele gecrypte bestand) .
Niet geweldig als je denkt dat je permanent gemonitord wordt door een super elite hacker, maar anders wel goed genoeg.

Dat als jij het bericht gelezen hebt het verwijderd wordt, maakt de boel niet perse veiliger.

Ik zou zeggen: verstuur username en password via twee los van elkaar staande communicatiemethoden, en verander de credentials zodra je ze binnen hebt.

Mits je een eigen server kan opzetten.
Ik zou niet adviseren om het te sturen via public privatebin servers.
https://privatebin.info/

Houdt uiteraard niet tegen dat de andere kant het opslaat en verspreid maar dat is hoe dan ook onmogelijk.

Je kan eventueel er nog een wachtwoord aanhangen voor er uberhaubt link data uitgelezen kan worden of mits de ander het niet erg vind zou je ook een IP allow list kunnen maken met een deny all erna.
kunt er zowel tekst als media bijlages mee sturen.

Werk er al jaren mee ontwikkeling is traag maar dat is prima voor mij want het moet maar 1 kunstje goed kunnen doen.

UserID via email, wachtwoord via SMS?
UserID via email, 2de mail met in een encrypted zipfile het wachtwoord. wachtwoord van de zip file via SMS?
UserID via email, wachtwoord in notepad typen, print screen van maken, deze via eenmalige functie via whatsapp als plaatje sturen? En dan hopen dat de andere kant dit bewaart of een print screen van maakt, anders moet je dit herhalen.

Hoe moeilijk wil je het maken? Gaat het om atoombom codes of zo iets?

Papier en postzegel

Inderdaad de eerste optie die hierboven staat voldoet prima.
UserID via mail en het wachtwoord via SMS of zelfs gewoon via Voice (ja dat kan ook nog tegenwoordig).
Belangrijk is dat de paden voor uitgifte gescheiden zijn en voor een meeluisteraar geen context heeft.
Dus niet door de telefoon gaan zeggen: Dit is wachtwoord XYZ die behoort bij userid ABC.

Ik zou zeggen: 3 x.
Een met het userID.
Een andere met het (eenvoudig) versleuteld wachtwoord.
En een met de sleutel.
Bij elke stap zowel verzending als ontvangst per mail of SMS bevestigen. En dan pas de volgende stap zetten.

Tenzij je brievenbus niet te vertrouwen is, maar normaliter geldt dat brievenbussen tegenwoordig volledig onder de radar gezakt zijn omdat iedereen alles online doet

Interessant.

Wel heb ik een vraag hoe er precies versleuteld is.
Gebruikt met AES of iets anders? Graag een reactie.

Dat kun je toch aan je browser vragen? Klik op het slotje en kijk bij technical details.

M.b.t. https://securemessage.nl/:
TLS v1.3 - voor de verbinding. En een DV (Domain Validated) https servercertificaat voor de authenticatie van de server. Het énige dat ik nu behoorlijk zeker weet is dat mijn webbrowser verbinding heeft:

• Met een server met een IP-adres dat mijn webbrowser verkreeg na een DNS-lookup van "securemessage.nl", en

• Dat die server beschikt over de private key (of een kopie daarvan) die past bij de public key in het https servercertificaat dat mijn webbrowser ontving van die server (en dat genoemd certificaat geldig is), en

• Dat genoemd https servercertificaat is verstrekt door een certificaatuitgever ("Sectigo RSA Domain Validation Secure Server CA") nadat deze heeft vastgesteld dat het om de server gaat met het IP-adres dat, onmiddelijk voor de certificaatuitgifte, als antwoord werd verkregen na een DNS-lookup van "securemessage.nl".

Oftewel, de DNS-requests van zowel Sectigo als van mijn webbrowser retourneerden één of meer IP-adressen van één of meer servers die over dezelfde private key beschikken.Veel betrouwbaarder dan het -onbetrouwbare- DNS protocol is dit niet. Ik heb dus sowieso géén idee van wie de server is (waarmee mijn webbrowser verbinding heeft), hoe zorgvuldig de eigenaar met de private key en de beveiliging van diens DNS-registrar-account omspringt, en ook niet welke beheerders toegang hebben.

Na verder uitzoekwerk:

• Op de website zie ik ook geen informatie over de eigenaar en beheerders, en ook een privacy policy mis ik (als die informatie wel op die server te vinden zou zijn, heb je geen idee of dat bij elkaar gelogen is of niet).

• Ik kan wel naar de door de server verzonden http headers kijken: geen enkele beveiliging, zelfs geen HSTS (en dus ook niet op de preload list: https://hstspreload.org/?domain=securemessage.nl). Geen CSP e.d.

• Ik heb geen idee of mijn bericht -los van de transportbeveiliging- daadwerkelijk wordt versleuteld, en zo ja: waar dit gebeurt (in mijn browser of op de server), noch welke versleuteling, KDF etc. er worden gebruikt.

• Volgens https://www.reddit.com/r/thenetherlands/comments/n9cywu/comment/gxn8x6r/ is de sourcecode van securemessage.nl te vinden in https://github.com/exonet/securemessage. Dat zou kunnen, maar de code op securemessage.nl kan ook ooit zijn afgeleid van die github repo - waarbij vervolgens aangebrachte wijzigingen niet kunnen worden uitgesloten. Ik kan op https://www.exonet.nl/ geen verwijzing vinden naar securemessage.nl; wie de eigenaar is (laat staan of je deze kunt vertrouwen) blijft dus een raadsel.

• Met NoScript actief, zonder dat er JavaScript wordt uitgevoerd door mijn webbrowser, kan ik een bericht op securemessage.nl invoeren en submitten (óf er versleuteld wordt, blijkt nergens uit) - en eveneens zonder JavaScript kan ik dat bericht zichtbaar maken door de opgegeven URL te openen en de code in te voeren. Ik kan me vergissen, maar áls er al iets versleuteld wordt, gebeurt dat op de server (het zou bij deze server om een onderzoek kunnen gaan waarbij wordt vastgesteld hoeveel idioten hun geheimen delen met onbekende partijen op internet, of om verzamelaars van geheimen).

Tenslotte suggereert Anoniem op 08-05-2023, 17:20 dat dit een oplossing zou zijn voor de TS. Ik zie niet hoe, want zelfs als dit veilig zou zijn: daarmee is het probleem van het veilig vragen om de credentials, bijv. via e-mail, niet opgelost (een AitM kan dat verzoek blokkeren en zelf een mail sturen vanaf een lijkt-sterk-op afzenderadres van die AitM, met als inhoud iets als "mail gewoon naar mij" - of de mail doorsturen met een toegevoegde Reply-To header naar de AitM) en ontvangen daarvan niet opgelost, want gebruikmakend van securemessage.nl moet de andere kant veilig een URL plus een code naar de TS sturen (in plaats van de credentials).

@TS: gebruik beiden dezelfde chat-app met "E2EE" en controleer elkaars public keys tijdens een face-to-face ontmoeting; daarna is het redelijk veilig om vertrouwelijke informatie uit te wisselen (mits beide partijen hun smartphones en chat-apps up-to-date houden en geen foute apps installeren). Je kunt ook met GPG/PGP aan de slag, maar dat is lastig en risicovol (omdat teveel mensen er niets van begrijpen). Je kunt ook IRL een sterk wachtwoord overeenkomen dat je vervolgens gebruikt om bestanden te versleutelen die je via e-mail uitwisselt.