Startend bedrijf presenteert nieuwe encryptiemethode

Silicon Valley meldt dat een startend bedrijfje uit Palo Alto in de Verenigde Staten, luisterend naar de naam Voltage Security, een nieuwe encryptiemethode heeft ontwikkeld, die eenvoudiger een goedkoper zou zijn dan de nu veelgebruikte public key-methode. De methode is gebaseerd op de identiteit van de gebruiker en heet dan ook niet voor niets Identity-Based Encryption, kortweg IBE. Voltage Security, opgericht door voormalige professoren en studenten van Stanford University, is op dit moment bezig met de laatste testen voordat hun product publiek beschikbaar zal worden.

IBE maakt gebruik van de uniekheid van ieders e-mailadres, welk met behulp van een algorithme versleuteld kan worden. Wil Truus beveiligd een bericht sturen naar Bob ([e-mail]), dan versleutelt zij het dus met het IBE-algorithme. Op het moment dat Bob het bericht ontvangt, authenticeert hij zich bij een speciale key-server, waarvan hij vervolgens de ontsleutelingscode ontvangt. Bij de reguliere public key-methode moet eerst een aparte public key worden geregistreerd, die via omslachtige certifcaten aan de identiteit wordt gekoppeld. Het voordeel van IBE is dat iedereen direct al zijn eigen public key heeft, namelijk zijn e-mailadres:

``The truth is that these public key systems are extremely difficult to use for end users,'' said Voltage's chief executive, Sathvik Krishnamurthy, noting that many people still fax or mail intellectual property they want protected. ``We've eliminated a pretty major step.''

Identity-Based Encryption takes a completely new approach to the problem of encryption. IBE can use any arbitrary string as a public key, enabling data to be protected without the need for certificates. Protection is provided by a key server that controls the mapping of identities to decryption keys. The design of an Identity-Based Encryption system was a long-standing open problem in cryptography. Voltage now offers a platform based on the first secure, practical IBE system, the Boneh-Franklin IBE Algorithm.

Reacties (74)

[Darkvater]

Goed zo, doe maar alles via een Centrale server

Wat als die gekraakt wordt, of de overheid verplicht stelt dat er backdoors voor hun moeten worden ingebouwd?

Noem me paranoide, maar ik vind dit niet zo'n goed idee.

[atomik]

Goed zo, doe maar alles via een Centrale server

En waar denk je dat je nu een public key aanvraagt dan? Er zal toch ergens een onafhankelijke partij moeten zijn die de identiteit van de verzender en ontvanger garandeert, zoals bijv. Verisign dat is in het huidige PKI stelsel. Aan een centrale server ontkom je dus niet. En zo'n zogenaamde root-authority, kraak je niet zomaar hoor. Die staat off-line ergens in een atoombunker en bepaalde taken worden gedelegeerd aan onderliggende authorities.
Hier is echt wel over nagedacht.

[jkf]

Je hoeft in ieder geval technisch gezien je private key niet bloot te geven om een public key gecertificeerd te krijgen, wat in dit voorbeeld wel duidelijk het geval is.

[atomik]

Het lijkt me (zie reactie iets lager) dat de private key in deze constructie steeds veranderd. Dan wordt het dus al een stuk minder erg als dat ding onderschept wordt.

[ichnaton]

Sorry hoor maarre je hebt echt nog nooit met PGP gewerkt, dus. Voor SSL certificaten geldt je verhaal wel

edit:
in die zin dat die meestal gekocht worden maar je ze ook zelf kan maken.

Met PGP maak je zelf een key-pair door je passphrase in te typen en daarna nog een keer of 100 op de spatiebalk te beuken om randomness te genereren.

[arjankoole]

of de overheid verplicht stelt dat er backdoors voor hun moeten worden ingebouwd?

de overheid hoeft dat helemaal niet verplicht te stellen, met name de NSA in amerika niet, die hebben supercomputers staan die de gemiddelde encryptie van PGP/GPG/SMIME en SSL binnen de halve seconde kraakt.

[Verwijderd]

die hebben supercomputers staan die de gemiddelde encryptie van PGP/GPG/SMIME en SSL binnen de halve seconde kraakt.

Dat lijkt me enigzins onwaarschijnlijk. Als er met vele 10 duizenden pc's (over het algemeen niet de minste pc's) het 3 jaar duurt om een 64bit encryptie te kraken (via brute force: ) dan lijkt het me niet waarschijnlijk dat een 128 bit (wat nu zo'n beetje standaard is) encryptie in enkele seconden te kraken. En dan heb ik het al helemaal niet over nog hogere encryptie want de tijd om hogere encrypties te kraken gaat redelijk exponentieel omhoog.

[Verwijderd]

Arjan heeft het hier over de NSA. Deze jongens hebben de allerbeste en allernieuwste supercomputers tot hun beschikking. Die zijn speciaal ontworpen om encryptie te breken (dat is namelijk één van de belangrijkste taken van de NSA). En de supercomputers van de NSA zijn in capaciteit niet te vergelijken met de DC-projecten om b.v. RC5 te breken. Misschien is een halve seconde wat overdreven, laten we het verdubbelen. Doen ze er een seconde over.....

edit:
reactie op rbs:
Jij praat erover alsof de NSA een kleine organisatie is. Het budget is moeilijk te bepalen (groot geheim), wordt door deskundigen geschat op zo'n 4 miljard dollar per jaar. Dat is wat ze ongeveer terug kunnen vinden in de begroting van de US. Het grootste probleem van de NSA is niet het kraken van encryptie. Het grootste probleem is te bepalen welke communicatie met encryptie het kraken waard is.

[Verwijderd]

Jij praat erover alsof een supercomputer een desktopje is net als alle andere, en dat de NSA er wel een paar in de kantine heeft staan ofzo. Niet dus. Vergeet niet dat die krengen extreem duur zijn, en ik verwacht dan ook niet dat oom agent voor een routine onderzoekje ff een uurtje op de supercomputer mag.

[blobber]

Wat denk je dan waarom die jongens uit de usa geen 128 bit encryptie mogen exporteren?Omdat het verdomd lastig te kraken is, zelfs voor supercomputers.

[Verwijderd]

Blijf dan fijn bij PGP, daar heb je geen centrale server. Edoch een partij die je zelf kiest en vertrouwt.

[LauPro]

En als je nu dat verkeer tussen Bob en die Key Server tapt . Volgens mij ontloop je dan dit hele systeem, en nog gevaarlijk ook want de hacker heeft de PRIVATE key in handen .

Je zult op z'n minst een versleuteld VPN hier over moeten gooien maar dat zullen ze gemakshalve wel vergeten zijn...

Trouwens: zolang de e-mailclient kan worden voorzien van Macro's die de inhoud kunnen bekijken van een e-mail heb je aan dit hele systeem niks .

[atomik]

En als je nu dat verkeer tussen Bob en die Key Server tapt . Volgens mij ontloop je dan dit hele systeem, en nog gevaarlijk ook want de hacker heeft de PRIVATE key in handen .

In ieder geval lijkt het of er voor elke sessie dan een nieuwe private key afgegeven wordt aan Bob, dus aan het aftappen heb je niets, want voor het net verstuurde bericht ben je te laat (en als je ook dat captured is er ongetwijfeld wel een of ander mechanisme dat een rollback van de data voorkomt) en voor elk nieuw bericht geldt dan weer hetzelfde.

[Buffy]

Begrijp ik het nu goed. De decryption key wordt gegenereerd aan de hand van een willekeurig (email adres) te kiezen public key?
Maar als dat mogelijk is dan kan iedereen dat toch als ze het algoritme kennen. Encryptie op basis van een geheim algoritme zou ik nooit vertrouwen.

[atomik]

Dus jij stopt ook acuut met het gebruik van je pinpas?

[nightlight]

Je moet dus eerst een verbinding maken met een externe server opgezet door een commerciele partij voordat je in staat bent de door jou ontvangen versleutelde mail te lezen. Een dergelijk concept is niet open genoeg om een succes te worden (misschien een beetje als het transparant "ingebakken" wordt in clients als MS Outlook, en als MS Passport als deze "public server" gaat gedragen).

[Lancer]

Da's nu toch niet anders. Het huidige public/private key mechanisme werkt ook met behulp van trusted third parties. Alleen is het nu zo dat verzender en ontvanger daar hun sleutel moeten halen. Met dit algoritme hoeft alleen de ontvanger dat.

[Verwijderd]

Uh...heb je ooit met PGP / RSA gewerkt?

zender en ontvanger creeren allebei een keypaar (public en private). Het public deel wordt voor iedereen zichtbaar en gebruikt om e-mail mee te encrypten door de verzender. De ontvanger gebruikt zijn private key om de mail weer te ontcijferen. De private key wordt NOOIT uitgegeven, dat is ook helemaal niet nodig.

Het systeem wat hier uitgelegd wordt is eigenlijk compleet overbodig. Er bestaan public-key servers (juist met de public key dus!) die de keys van alle mensen die daar een key naar geupload hebben staan.

Dit maakt het systeem van die pipo's compleet overbodig. Het enige wat er nog aangepast kan worden zijn de mail-clients om het geheel wat vloeiender te laten lopen...dit systeem (GnuPG) is volledig open trouwens...

<font color=#786562>* [Felix] heeft 't idee dat dit net zo'n verhaal is in de categorie van het wisselende IP van een tijdje terug...</font>

[Lancer]

Maar...., PGP kan niet aantonen dat de afzender ook echt de persoon wie je denkt dat hij is. Als de public key eenmaal is geverifieerd is het OK. Maar bij het eerste mailtje dat je krijgt met PGP zul je toch zelf moeten vaststellen wie het is.

Berichten ondertekend met een eigen PGP certificaat heeft niet dezelfde rechtsgeldigheid als een bericht ondertekend met een certificaat van B.V. verisign.

Overigens het het algoritme waar het om gaat ook te gebruiken in een PGP-achtige oplossing. Je hoeft dan niet eerst om iemand zijn public key te gaan vragen, iets wat je met PGP zelf eerst moet uitwisselen. (Je moet met PGP eerst iemand een mailtje sturen voordat hij het ge-encrypt iets kan terugsturen)

[deadinspace]

Maar...., PGP kan niet aantonen dat de afzender ook echt de persoon wie je denkt dat hij is. Als de public key eenmaal is geverifieerd is het OK. Maar bij het eerste mailtje dat je krijgt met PGP zul je toch zelf moeten vaststellen wie het is.

En daar is al een kleine eeuwigheid een open, gedecentraliseerde, schaalbare oplossing voor: het web of trust.

Een web of trust werkt min of meer als volgt: Jij kent persoon A persoonlijk, en kan zijn public key verifieren. A kent B persoonlijk, en kan zijn public key verifieren. Nou heeft A B's key gesigned. Dat wil zeggen, dat A zeker weet dat B's public key bij B hoort. Jij hebt persoon B misschien nooit ontmoet, maar omdat jij persoon A en zijn key vertrouwt, kun je persoon A geloven als hij zegt dat B's public key bij B hoort.

Nou is het voorbeeld dat ik gaf lineair (jij -> A -> . In werkelijkheid signed iedereen de keys van meerdere personen. Je krijgt dan een ingewikkeld netwerk, dat (net als het world-wide-web) een webstructuur heeft, vandaar de naam "web of trust". Omdat in zo'n web er meerdere (vaak heel veel) paden van de ene naar de nadere persoon zijn, kan een enkele foute keysigning ook niet al te veel problemen opleveren.

Wat leesvoer:

http://www.rubin.ch/pgp/weboftrust.en.html
http://world.std.com/~cme/html/web.html
http://www.heureka.clara.net/sunrise/pgpweb.htm

[Verwijderd]

<I>
Berichten ondertekend met een eigen PGP certificaat heeft niet dezelfde rechtsgeldigheid als een bericht ondertekend met een certificaat van B.V. verisign
</I>

Jawel dat heeft het wel. De BV Verisign is niet eens als CSP erkend bij de OPTA, laat staan dat ze voldoen aan de technische eisen. Het zijn dus gewoon "ongekwalificeerde" certificaten. :-p

Lees maar de wet elektronische handtekeningen na op wetten.nl ;-)

[Verwijderd]

kan wel zo zijn maar heb je kan iedere email account open via het internet zelfs @home gebruikers.


er zijn pagina's die dat kun je rustig de email lezen en als je het binnen haalt lijkt net of dat niemand het gelezen heeft terwijl die al gelezen heeft dus..

tjsa...

[Croga]

(misschien een beetje als het transparant "ingebakken" wordt in clients als MS Outlook, en als MS Passport als deze "public server" gaat gedragen).

Ja, dan weten we tenminste zeker dat het veilig is...........?

[blade181]

Lijkt me niet, je vraagt alleen een private key aan. Dit gaat aan de hand van het zelf aangemaakte public key. Met daarin het email adres, dat is ook best slim, omdat een email adres op het gehele internet maar 1 keer voor kan komen heb je ook meteen een unieke public key voor iedereen.

Aan de hand van een private key wordt je mail encrypted. Wel makkelijk moet ik zeggen hoor.

Het enige punt is of die keyserver wel secure is. Zodra die gekraakt wordt dan heb je de poppen aan het dansen.

[Verwijderd]

Ik vind de term 'nieuwe encryptie methode' wat overdreven. Er verandert niks, behalve dat je key uit je e-mail instellingen komt in plaats van uit een randomiser.

[egeltje]

Ha, dat was ook precies mijn gedachte. Het enige dat je hier niet hoeft te doen is je registreren (want dat doen zij blijkbaar al on the fly).
Blijf ik me afvragen hoe je je kunt legitimeren, want iedereen kan wel in zijn mailclient instellen dat hij [e-mail] is... Je zult dus je sleutel ergens moeten registreren in je mailclient. Of je daar nu '[e-mail]' voor gebruikt of 'qw#gl34-g2@ga', dat maakt niet uit. Het is voor de doorsnee gebruiker alleen simpeler om [e-mail] te lezen, meer niet.

[Verwijderd]

Als jij een private key aanvraagt en je doet je voor als Bob met adres [e-mail] dan wordt deze naar Bob en niet naar jou gestuurd. Op deze manier kun je Bob's private key dus niet achterhalen.

[VisionMaster]

idd
dit is gewoon een cheap en simpel versie van bestaande pki.
Helaas zijn certificaten duur om te kopen, maar ik snap niet dat het gebruik van x.509 certificaten zo duur en 'lastig' of zelfs 'omslachtig' gevonden wordt.
Allerlei technieken liggen er al kant een klaar om te gebruiken. Certificaten tja ... je koopt er 1 van een CA als ISP ofzo en je maakt certificaten voor de users door een nieuw certificaat te generen vanuit het certificaat van de ISP. (Private Key van je ISP ondertekend je eigen certificaat)
Bij het gebruik geef je je certificaat af, de tegenparty zoekt naar je public key, die is encrypted door je ISP, de OpenSSL lib zoekt door naar het certificaat van je ISP, die is ondertekend door Verisign ofzo en hoppa de tegenparty kan nu bij de public key van je certificaat en weer verder gaan met authenticatie).

1 certificaat 2 rule them all
* 786562 VisionMaster

[zwippie]

De laatste opmerking over dat je security-issues gekoppeld worden aan je (fysieke?) internet toegang, daar ben ik het in ieder geval helemaal mee eens.
Het idee dat je onbeperkt en anoniem, niet-te-traceren en virtueel je dingen kan regelen is onzin, en een slechte uitgangspositie voor een (eventuele?) internet-economie. Wil je serieus gebruik maken van internet (mailen, kopen, diensten gebruiken), dan moet je ook serieus ergens geregistreerd staan. Om gebruik te beschermen ern misbruik te voorkomen.

[VisionMaster]

Je had het niet begrepen, want het moet zeker nooit een een fysieke koppeling zijn/worden.

Je heb gewoon een certificaat die je gebruikt om je te identificeren als jezelf bij een site. De site geeft ook zijn certificaat, zodat jij (electronisch) kan controleren dat je met de juiste server babbelt. Zo weet ik dat ik met de juiste server contact heb en weet die server dat ik die aankoop gedaan heb. Als je dus anoniem wil internetten staat dit je niet in de weg.

[Bor]

IBE maakt gebruik van de uniekheid van ieders e-mailadres

Ik vind het niet zo;n goed plan om alleen het e-mail adres als "persoonlijke factor" te gaan gebruiken. Veelal worden juist voor e-mail slechte wachtwoorden gebruikt. De mail adressen zijn ook nog eens altijd volgens een vaste methode opgebouwd (bv [e-mail]). En hoe zit het met de opslag van data? Tot nu toe zie ik in bovenstaand stuk alleen maar dingen over het versturen. En wat als ik bijvoorbeeld van provider (en dus van mail adres) verander?

In principe is het e-mail adres dus op deze manier de public key. En worden alle private keys dus door een centrale server opgeslagen / generereerd ipc bijvoorbeeld op een smartcard van de gebruiker oid.

Hoe gaan ze hier trouwens om met dns poisoning waarbij je dus kant hebt dat de e-mail berichten fout worden gerouteerd? Verder mist voldoende info over het verkeer tussen de communicerende partijen - communicerende partijen en de centrale server om een goed oordeel over de veiligheid te geven.

[SWINX]

ik vraag me ook af hoe dat dan gaat met dat mailadres. Ik zal er vast bij zeggen dat ik van de huidige methode ook geen verstand heb, maar wordt je email-adres (pub key) automatisch verzonden?

Gaat die bijvoorbeeld ook werken als je gebruikt maakt van forwardings.

Piet: ([e-mail] forwards naar [e-mail])
Jan stuurt mail naar [e-mail] met pub key [e-mail]

Piet ontvangt mail op [e-mail] en stuurt [e-mail] als key (gaat dit automatisch of moet piet zelf zijn emailadres invullen)

Dan moet Piet wel steeds kijken of het rechtstreeks naar hem is gestuurd of via zijn forwarder

[Dangerous_Dave]

Lijkt me niet dat andere email adres heeft weer een andere unieke code.

Een beveiligde verbinging werkt ook niet via een proxy server, de proxy server ontvangt het certificaat, niet je eigen pc.

[kodak]

Het grootste probleem bij cryptografie is bijna standaard de regel: hoe gemakkelijker het wordt, hoe onveiliger het is.
Het is nog maar niet gepubliseerd of de opmerkingen vliegen al door de lucht dat er verschillende punten zijn die bij deze nieuwe cryptografie methode zwak zijn.
Daarbij moet ook opgemerkt worden dat er gebruik wordt gemaakt van een nieuw algorithme, waarvan doorgaans pas na vele jaren door vele experts goed testen van gezegd kan worden of het veilig is. Maar een enkele algoritme doorstaat dit traject, de meeste komen er uit als te zwak. Dat het door een universiteit is ontwikkeld maakt vaak niets uit.
Kortom: voorlopig bestempel ik het als de zoveelste nieuwe methode die zich nog maar moet bewijzen. Als je echt veilig bezig wil zijn zou ik hier niet aan beginnen.

[purge]

Ik ben het eens met de stelling/regel dat iets onveiliger wordt naar mate deze standaard of eenvoudig te voorspellen is.
Ik vind het desondanks toch een goed idee om hiermee de markt op te gaan. Hoe eenvoudiger iets voor de massa is hoe sneller dit wordt geaccepteerd. Als (bijna) alle Internet gebruikers gebruik maakt van deze technieken (al dan niet veilig) kan je makkelijker overstappen naar een veiligerder systeem.
Het bekende spreekwoord "Beter iets dan niets" is mijn ogen dan ook terecht.

[Verwijderd]

Ik ben het _niet_ eens met de stelling/regel dat iets onveiliger wordt naar mate deze standaard of eenvoudig te voorspellen is.
Het public key systeem is heel erg simpel, maar de veiligheid hangt louter en alleen af van de lengte van de key, dus niet van de complexiteit O() van het cipher. Een nadeel is gewoon dat je de public key van de ontvanger moet authentificeren (met een certificate), anders encrypt je per ongeluk een bericht voor de private key van de onderschepper Je betaalt dus een derde partij die probeert te garanderen dat key A van ontvanger A is. Een ander nadeel is dat de private key terug is te berekenen uit de public key, dus de key moet flink langer worden gemaakt dan bij symetrische systemen. public key systemen zijn daardoor minder efficient dan symmetrische.
Symmetrische systemen zijn wat mij betreft een beetje , want je moet de key over een beveiligd kanaal oversturen om vervolgens het bericht over een onbeveiligd kanaal te kunnen sturen. maar goed, er zijn wel goede implementaties.

het idee nu om het emailadres van de ontvanger als public key te gebruiken is wel okee, maar nu moet de ontvanger zich dus identificeren om de private key te krijgen. Dus de identificatie verplaats zich.

Als je je bericht versleuteld met iemand email adres, hoezo is dit veilig dan? Het algoritme is dus onbekend?

``The truth is that these public key systems are extremely difficult to use for end users,'' ...
...``We've eliminated a pretty major step.''

Over kort door de bocht gesproken zeg...

En wat als 2 computer nou willen communiceren. Mijn computer heeft geen email adres. Waarom kiezen ze dan geen GUID.

Zoals iemand anders al opmerkte: Er is nog een beetje weinig bekend over de techniek om er een serieus oordeel over te geven. Maar er zijn al wel experts die het gedaan hebben natuurlijk. je krijg nie zomaar venture capital.

[Verwijderd]

Wie is Truus?

Bob krijgt toch altijd berichten van Alice?
En af en toe sturen ze nog iets naar een bank?
Die ken ik, maar Truus....

[eamelink]

Juist, en Oscar kan hier heus wel iets op verzinnen

Ik zat ook al te denken, WTF, Truus???

Alice is gewoon een van de zekerheden in het leven

[Verwijderd]

Cryptografie kent meerdere toepassingen dan allen het verbergen van een boodschap in een mail(vertrouwelijkheid).
Toepassingen cryptografie:
- Vertrouwelijkheid (cipher-text, door een algoritme zoals: DES, AES of elliptic curve)
- Integriteit (bijv. Hash)
- Authenticiteit (signatuur)
- Onweerlegbaarheid (bewijs identiteit bijv. bij PKI)
- Autorisatie (dmv toegangscondities)

Ik kan me bij dit nieuwe algoritme wel een paar toepassingen bedenken uit het bovenstaande(minstens 3). Het huidige popuaire PKI, een zgn asymmetrisch systeem, zal op een gegeven moment toch een keer achterhaald worden. Ok dat duurt jaren, maar echt efficient is het ook niet; wie van jullie beschikt (prive) over een public-key voorzien van een certificate van een TTP (trusted third party)? Niemand toch....

[Verwijderd]

Even over EC: dat algoritme is van Sun en heeft Sun 'opensource' beschikbaar gestelt. Althans, daar lijkt het op. Maar het EULA komt er op neer dat wanneer je het gebruikt, je Sun niet mag aanklagen op geen enkele manier. Dus ook niet vanwege een reden die verder niks met EC te maken heeft. OpenSSL heeft hier helaas niet naar geluisterd, heeft het genegeerd, en heeft dit in de standaard distributie geimplenteerd.

Over het onderwrp: dus het verschil is dat er ipv. random data het email address gebruikt wordt als key waardoor een random public key niet nodig is. Lijkt me niet zo veilig.

SecureId is ook interessant. Alles copy/pasten is wat veel maar is m.i. het lezen wel waard.

Het is een soort ACL gebaseerd op kennis ipv. op een user/passwd of public key.

For secure access, SecureId uses a knowledge system. Since information is associated with different contexts, you need to define what is necessary to gain access to those contexts. Rather than listing who can gain access, you simply say what they must know. Depending on the type of context, you can imagine different levels of accessibility. For example, your friends change; it would be a hassle to have to list them every time that you wanted them to have access to something of yours. Instead, you might be able to assume that anyone who knows who your favorite musician can be assumed to be one of your friends.

In zo'n geval zit het wachtwoord in je hoofd en hoef je geen wachtwoorden, keys of useraccounts aanmaken. Dus men kan niet zomaar jouw mail doorsturen. Gebeurd dit wel, dan heeft men de kennis nodig over jou. En dat weet een buitenstaander niet. Je zou er dan wel op moeten letten dat die informatie niet publiekelijk beschikbaar is.

Volgens de site is het prima te gebruiken voor email. Hier zijn trouwens ook al implementaties van. Zo is er een patch voor OpenSSH om dit daar in te implementeren.

[Ryan1981]

Misschien overbodig, maar ik krijg tegenwoordig gewoon spammail met als afzender mezelf...

[crazyx]

dan maken ze het je wel heel gemakkelijk om er een filter op te zetten . Je stuurt immers toch nooit email naar jezelf met je eigen emailadres.

[intGod]

Toch wel. Vanop m'n werk een documentje naar mezelf mailen is niet zo moeilijk Ik ga echt geen Terminal Services of PC Anywhere thuis draaien. Dus mail ik alles lekker naar mezelf.

[crazyx]

je hebt thuis toch niet hetzelfde emailadres als op het werk

[Mega-Druif]

Er bestaat ook nog webmail?

Ik doe het zelf ook vaak genoeg, even een mailtje naar mezelf, en die thuis via de webmail weer ophalen.

[Zucht]

Wat is er mis met?:

compu_werk$ scp document.txt zucht@compu_thuis.nl:doc_dir

Documenten naar jezelf mailen vind ik nogal een omslachtige manier om documenten van de ene computer op de andere computer te krijgen.

[theXE]

Er is niks mis mee, want ik vind het omslachtiger om er een programma voor te installeren. En wat bedoel je met die code? Wil ik dat ook kunnen?

[broes willems]

Misschien overbodig, maar ik krijg tegenwoordig gewoon spammail met als afzender mezelf...

Misschien een methode van de spammers om het bouncen tegen te gaan ?

[Zucht]

Signeer al je email dan met een OpenPGP signature en accepteer alleen email van jezelf indien deze gesigneerd is.