Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - crypton

Pages: [1] 2 3 ... 101
Unsorted / Ricochet: Anonymous instant messaging for real privacy
« on: November 10, 2015, 11:18:27 AM »
Ricochet is a different approach to instant messaging that doesn’t trust anyone in protecting your privacy.

Eliminate metadata. Nobody knows who you are, who you talk to, or what you say.
Stay anonymous. Share what you want, without sharing your identity and location.
Nobody in the middle. There are no servers to monitor, censor, or hack.
Safe by default. Security isn’t secure until it’s automatic and easy to use.

How it works
Ricochet uses the Tor network to reach your contacts without relying on messaging servers. It creates a hidden service, which is used to rendezvous with your contacts without revealing your location or IP address.
Instead of a username, you get a unique address that looks like ricochet:rs7ce36jsj24ogfw.
Other Ricochet users can use this address to send a contact request - asking to be added to your contacts list.
You can see when your contacts are online, and send them messages (and soon, files!). Your list of contacts is only known to your computer - never exposed to servers or network traffic monitoring.
Everything is encrypted end-to-end, so only the intended recipient can decrypt it, and anonymized, so nobody knows where it’s going and where it came from.
For more information, you can read about Tor and learn more about Ricochet’s design.

Antox is an Android 2.3+ client for Tox created by Mark Winter. It aims to bring the full multimedia support Tox offers to your device, although it's still currently in heavy development. Antox is currently available for alpha testing on Google Play and F-Droid.


Unsorted / The Blockchain Magic: Φ Free Anonymous Internet
« on: November 09, 2015, 11:17:18 AM »
Φ--Free Anonymous Internet, upgrades internet by providing ultimate freedom and anonymity

Ultimate Freedom

Can NEVER be deleted, locked, modified or censored
Accessible from anywhere

Ultimate Anonymity
No real world personal data needed
Footprint untraceable

Next generation Internet infrastructure
Full compatibility to existing internet system
Plenty of general purpose APIs enabling quick and powerful Apps development
Open source to ensure safety and upgradability

Core Innovations :

Φ Account

The Φ account system is based on asymmetric cryptography, specifically, ECDSA technology

Each user can create a unique Φ account by himself/herself. A Φ account is a privatekey – namekey (publickey) pair. Namekey represents the Φ account, and digital signatures signed by private key proves the control of the Φ account and triggers digital operations

A Φ account is fully owned and controlled by the user only. No website, organization, or government is able to access your Φ accounts

The absence of any link between Φ account and real world personal information ensures ultimate anonymity

Φ account is free. The zero cost to create, possess, use and abandon as many Φ accounts as needed ensures ultimate freedom

Φ accounts are compatible with all kinds of digital system and are extremely easy to implement. "One account for any app" will become true in the near future

Φ Network

Φ network system is based on P2P technology, aka decentralized network

Φ network has no centers. Every node in the Φ network is equal. Users can communicate point-to-point, or broadcast and relay Φ information

Because of the cascade spreading of Φ information in the Φ network, there's no way to block, censor or modify Φ information

Also because of the cascade-spreading of Φ information in the Φ network, it's extremely difficult to track the origin of Φ information. Ultimate anonymity is ensured meanwhile

Any digital device can join the Φ network by following the basic Φ network protocol. Many kinds of apps can run on Φ network, even without a server

Φ Database

The Φ database system is based on blockchain technology

There's always only one valid version of Φ database in the whole network, while many node/digital devices keep a full copy of it

No Φ information can be deleted, because every node in the Φ network has a full copy of the Φ database

Φ information following Φ database rules will go into Φ database after confirmed by Φ miners. The Φ database rules strictly require digital signature from the sender of the Φ information, so that no one else can modify the Φ information, i.e. the Φ information will be stored in the Φ database as what it is forever. Because of the decentrality of miners, there’s no way to block any valid Φ information going into Φ database

Because everybody has exactly the same copy of Φ database, there're no ways to know what data a user has browsed. Ultimate anonymity is ensured

The Φ database is open for any kind of digital information, including not only text, image, video, but also programs, settings, operation commands, etc

Φ Currency

The Φ currency system is based on Bitcoin technology

The Φ currency is published and distributed independently on Φ system. It has no relationship with traditional currencies, so it's independent from any traditional banking and financial system

Any Φ account can receive and send Φ currency. Naturally, the Φ currency system inherits the freedom and anonymity of Φ account

A unique advantage of Φ currency system is that, the currency transaction is processed together with information and operation commands on the Φ system. It is unimaginably easy for merchants or app developers to integrate currency functions into their programs

Privacy apps for mobile devices / Briar: Secure messaging, anywhere
« on: September 06, 2015, 10:37:04 PM »

Secure messaging, anywhere

    Peer-to-peer encrypted messaging and forums
    Messages are stored securely on your device, not in the cloud
    Connect directly with nearby contacts - no Internet access required
    Free and open source software

How it Works

Briar is a messaging app designed for activists, journalists, and anyone else who needs a safe, easy and robust way to communicate. Unlike traditional messaging tools such as email, Twitter or Telegram, Briar doesn't rely on a central server - messages are synchronized directly between the users' devices. If the Internet's down, Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis. If the Internet's up, Briar can sync via the Tor network, protecting users and their relationships from surveillance.

Briar uses direct, encrypted connections between users to prevent surveillance and censorship.

Briar provides private messaging and public forums that are protected against the following surveillance and censorship threats:

    Metadata surveillance. Briar uses the Tor network to prevent eavesdroppers from learning which users are talking to each other. Each user's contact list is encrypted and stored on her own device.
    Content surveillance. All communication between devices is encrypted end-to-end, protecting the content from eavesdropping or tampering.
    Content filtering. Briar's end-to-end encryption prevents keyword filtering, and because of its decentralized design there are no servers to block.
    Takedown orders. Every user who subscribes to a forum keeps a copy of its content, so there's no single point where a post can be deleted.
    Denial of service attacks. Briar's forums have no central server to attack, and every subscriber has access to the content even if they're offline.
    Internet blackouts. Briar can operate over Bluetooth and Wi-Fi to keep information flowing during blackouts.

Briar is designed to resist surveillance and censorship by an adversary with the following capabilities:

    All long-range communication channels (internet, phone network, etc) are comprehensively monitored by the adversary.
    The adversary can block, delay, replay and modify traffic on long-range communication channels.
    The adversary has a limited ability to monitor short-range communication channels (Bluetooth, WiFi, etc).
    The adversary has a limited ability to block, delay, replay and modify traffic on short-range communication channels.
    The adversary can deploy an unlimited number of devices running Briar.
    There are some users who can keep their devices secure - those who can't are considered, for the purposes of the threat model, to be controlled by the adversary.
    The adversary has a limited ability to persuade users to trust the adversary's agents - thus the number of social connections between the adversary's agents and the rest of the network is limited.
    The adversary can't break standard cryptographic primitives.

Our long-term plans go far beyond messaging: we'll use Briar's data synchronization capabilities to support secure, distributed applications including blogging, crisis mapping and collaborative document editing. Our goal is to enable people in any country to create safe spaces where they can debate any topic, plan events, and organise social movements.


Decentralized websites using Bitcoin crypto and the BitTorrent network


    We believe in open, free, and uncensored network and communication.
    No single point of failure: Site remains online so long as at least 1 peer serving it.
    No hosting costs: Sites are served by visitors.
    Impossible to shut down: It's nowhere because it's everywhere.
    Fast and works offline: You can access the site even if your internet is unavailable.


    Real-time updated sites
    Namecoin .bit domains support
    Easy to setup: unpack & run
    Password-less BIP32 based authorization: Your account is protected by same cryptography as your Bitcoin wallet
    Built-in SQL server with P2P data synchronization: Allows easier site development and faster page load times
    Tor network support
    TLS encrypted connections
    Automatic, uPnP port opening
    Plugin for multiuser (openproxy) support
    Works with any browser/OS

How does it work?

    After starting you will be able to visit zeronet sites using{zeronet_address} (eg.
    When you visit a new zeronet site, it tries to find peers using the BitTorrent network so it can download the site files (html, css, js...) from them.
    Each visited site becomes also served by you.
    Every site contains a site.json which holds all other files in a sha512 hash and a signature generated using site's private key.
    If the site owner (who has the private key for the site address) modifies the site, then he/she signs the new content.json and publishes it to the peers. After the peers have verified the content.json integrity (using the signature), they download the modified files and publish the new content to other peers.




Working features:
   - Sending messages
   - Receiving messages
   - QR codes for addresses
   - Address Book
   - Import addresses
   - Export addresses
   - Choose which servers to use (including your own)

Roadmap for development (subject to change):
   - Update for Bitmessage Protocol Version 3
   - Lite client message retrieval using prefix filters (credit to Peter Todd for suggesting this)
   - Local encryption of the database, using SQLCipher
   - SSL for connections between clients and servers
   - POW implemented in C or C++ via the Android NDK
   - Support for broadcasts
   - Refresh the UI


- Bitseal is not ready for widespread use yet. A full release is planned once lite client message retrieval is implemented. The app will be available on the Google Play store once this is done.

- Bitseal is free, open source software, released under the Gnu General Public License Version 3.

- Some parts of Bitseal include, are based on, or are reliant upon software written by others, including Jonathan Warren, Sebastian Schmidt, Tim Roes, Roberto Tyley, the bitcoinj developers, and the Bouncy Castle developers. This is noted in the source code where applicable.

- I have set up a few default servers which can be used for testing purposes. Anyone is free to set up and use their own. The server application is simply a slightly modified copy of PyBitmessage.

- The development of Bitseal has been a large project, taking many months of work. I'm doing it on a purely non-profit basis. Bitcoin donations are very gratefully received: 1ALTrxJ3Yn3Rc85Uf467u3ZcpHCzx4jDAT

Bitseal 0.5.5 is now available.

- Fixed a bug which caused new screens to be opened instead of re-using existing ones.
- Modified configuration for communication with server to improve performance.

Known Issues:
- Scrolling in the Inbox and Sent lists is still slow while catching up with the network.
- Bitseal still uses a lot of bandwidth and battery life! Keep an eye on this while testing.

Beta testers who have joined the Google+ testing group should get the update automatically.

Other testers can either download a pre-compiled APK file or compile the app from the Github repository.

Many thanks to all the testers for their feedback so far! Particular thanks also to everyone who has donated to support Bitseal's development.

Anyone who would like to make a donation can use the Bitcoin address 1ALTrxJ3Yn3Rc85Uf467u3ZcpHCzx4jDAT.

PeerWasp works with the power of the P2P technology and is a full open-source solution for distributed file sharing and synchronization. There is no Cloud or Server storage and therefore no access point for any third-parties to your data!

Sophisticated encryption technology in place
No hidden Code - check it by yourself on Github
Windows Context and Taskbar Notification Area Integration
Easy Installation - Intuitive Handling

Toxim gibts auch für Android/IOS :)

Bitseal - a Bitmessage client for Android


Außer Anonymität ist Sicherheit auch wichtig, sichere kommunikations apps für Smartphones :)

Also hab gesehen I2P gibts sogar für Android

Bote für I2P

Board News / Re: Update auf SMF 2.0.10
« on: June 16, 2015, 07:49:21 PM »
Sieht top aus, gefällt mir schon besser das design:)

RetroShare / Re: RetroShare 0.6 released!
« on: June 16, 2015, 06:24:17 PM »
Wow, seems that RetroShare is one of the systems who are still under development. :)

yes RetroShare has active Developers,helpers, patchers more and more people want help to improve RetroShare.

RetroShare / RetroShare 0.6 released!
« on: June 14, 2015, 01:02:52 AM »


The network paradigm has changed a little bit: Retroshare still offers the possibility to securely connect nodes using SSL links, authenticated by PGP signatures. But now, in addition, the users have the possibility to create pseudo-anonymous identities which can be used to sign forum posts, talk in chat lobbies, send distant messages, etc. This decorrelates the identities from the actual nodes of the Retroshare network.

We also took the opportunity to change a lot of low level protocols, and pushed a significant number of long waiting changes. As a result, the new 0.6 version is not compatible with the 0.5 version. That means you will need to upgrade your friends too if you want to keep them. Of course, the PGP keyrings and signatures stay, so your web of trust stays intact. In order to make the transition easy, we made it possible to use both Retroshare 0.5 and 0.6 on the same computer simultaneously. Linux executables and packages being 100% independent (except for the keyrings)

What hasn’t changed a bit is the rule of thumb: all the data that comes or leaves your node get through your trusted friends.

Major new features

Version 0.6 brings some very cool features. A separate blog post will probably cover some of these topics in the near future.

Retroshare Identities

When talking over the Retroshare network(s) you need to be able to consistently know who posted which information, whereas that person might not want to be tracked either.

We solved that problem by adding pseudo-anonymous identities. These are RSA key pairs that can be used to encrypt/sign/authenticate posts. They can be either signed by your PGP key (which makes them extremely hard to impersonate) or anonymous (quite impossible to trace).

The new “People” tab allows you to manage your own identities (you can have as many as you want) and also displays the identities relevant to your own local view of the network. Every time an identity is needed, it is asked to your friends, along the flow of data that also uses the same identities. Forum posts for instance are signed by these identities, and the public keys that allow to check the signatures can always be requested to whoever transmitted the post to you.

Pseudo identities can have avatars, Utf8 encoded names, etc. The only not-yet-activated thing is the ability to make groups out of them, and control access to data in the network based on these groups. But this is ongoing development.

Hidden Nodes using Tor

Retroshare now offers—as an option—the possibility to create nodes that are only visible through the Tor network, represented by an onion address. As such, users of a hidden node totally hide their IP address even from their own friends. Hidden nodes do not use the DHT, and only share .onion addresses through the network discovery system. Hidden nodes do not use “Tor exit nodes” either except when talking to non hidden nodes. Beyond anonymity, hidden nodes are an excellent way to bypass firewalls, at the cost of an insane amount of crypto (basically DHE-SSL over Tor  ;-) ).

Connecting to a hidden node is also possible if running a normal node, as soon as you are also running Tor on your machine (without any further configuration). Just make sure the Tor proxy port is correctly given in config/server/Tor (9050 is the default). Each hidden node you connect to will appear with IP equal to

In order to run your own hidden node, you need in addition to create a Tor hidden service: edit your Tor config file (e.g. /etc/tor/torrc on linux)  and add:

HiddenServiceDir /var/lib/tor/retroshare/
HiddenServicePort 9023

Now just launch Tor, and read the onion address (should look like  uido4sbabwem5bq6.onion)  that Tor created for your Retroshare node in


In the node creation manager at start, select “advanced” and then “Create a hidden node”. Supply your onion address and port:

hidden_node_creationNote that this can be changed afterwards in the server->Tor options. Also make sure to use the right port. In the node creation window, the port that is expected is the port in the Tor network (here 9023).

Integrated Web interface

Although we already had a web interface, we recently came up with a simpler and integrated web interface based on react.js and libmicrohttpd, thanks to the work of a new member of the team (thank you electron!). The web UI currently covers basic functions such as adding/removing friends, controlling file transfers and searching files. It is under heavy development at the time of writing this post.

The web UI works with both Retroshare-nogui and Retroshare. If enabled, it is basically accessible by pointing your web browser to localhost:9090 (or whatever port you chose for the web UI either in the config or using command line parameters of Retroshare-nogui):

/usr/bin/RetroShare06-nogui --webinterface 9090 \
           --docroot /usr/share/RetroShare06/webui/

A clean and secure way to access the web UI from a distant machine is therefore to create a SSL tunnel to forward the local port: use Putty on Windows; on linux just do:

ssh -L 1463:localhost:9090 -N

That command securely forwards port 9090 on where Retroshare06-nogui runs, onto port 1463 on localhost (the machine from which you type the ssh command). From know on, you can access your web UI at localhost:1463.
Reshaped forums and channels, and new Posted service

Forum, Channels and Posted are 3 instances of services based on the new cache system (see below). They share the ability to post comments, vote over posts, and sign posts with pseudo-anonymous identities. From posts, you may send distant messages to forum posters, talk to them in the chat lobbies, or privately using a secured chat tunnel.

Non subscribed threads no not transfer anything more than the number of posts available and we also collect the number of friends who are advertising them, giving a reliable measure of popularity.

Posted is a new service which allows you to share html links and vote for them or comment them. It is not entirely finished yet, but still quite usable. So it is included in the RC of v0.6 as a way to get some feedback about how we may improve it.

Distant chat and distant messaging

The distant chat system now allows to talk to a Retroshare pseudo-anonymous identity using an encrypted tunnel. The tunnel is secured using DHE+AES and authenticated using the RSA key pairs that represent talking identities on both ends. A led indicates the status of the tunnel, which may be interrupted because of network topology changes. Nevertheless, tunnels soon reconfigure and you’re able to talk again. Nothing guaranties that a person is close enough to be reached that way, but the distant chat still offers the possibility to privately talk to a lot of people.

The distant messaging system also connects pseudo-anonymous identities using a multi-hop e-mail system, that is asynchronous (mails can be received after the source has disconnected). Messages are encrypted and signed using the identity RSA keys. The system also includes a signed receipt mechanism which is used to remove the message sent from the outbox. So when that happens, you can be sure that the destination got the email.

Additional goodies

Fine service-based tuning

It is possible to disable services manually using a dedicated widget in the configuration window. The widget displays both your own enabling status and your friends enabling status. Only when both are ok does the data flow for each particular service.

Network statistics window

We did a bit of graphical work there. You can get from that window all sorts of statistics about what’s going on: bandwidth, tunnels, routing matrix, etc. with cool graphs to look at ;-)

New certificate format

We got rid of the old ascii certificate format. The certs now look like a blind block of text, which—at the expense of ease of read—provides a lot more robustness and compactness. It’s quite impossible now to accidentally mis-cut or mis-copy one part of the certificate. We also improved the UI so that tooltips show the user the actual content of the certificate.

Improved file transfer

File transfer now supports multi-tunneling, which means that multiple tunnels can link the same (source, destination, hash) triplet. As a consequence the data flows more efficiently into the best tunnels at every moment during a transfer. The speed of transfers has also been improved. It is of course limited by the upload capacity of every link along a tunnel, but we drastically improved the handling of data which makes it possible to transfer along single links at up to 10MB/s, if the connection bandwidth allows it.

VOIP plugin now does video

 Although not entirely satisfactory, we have already all the building blocks for a real Video chat system. The UI has been improved as well, so as to give a reasonable experience to the user. The codec we’re using currently is however extremely basic and therefore does not allow much control yet.

Whitelist/blackist system

Retroshare has recently been “attacked” by what we think are network profiling actors who basically used the DHT to impersonate your friends and blindly relay the traffic between peers, without the ability to decrypt it. Still, such an attack would allow to progressively map the network and measure bandwidth. We contacted the abuse service of the related internet ranges but got no answer. So we implemented multiple measures to efficiently get rid of this problem:

    A black list system automatically collects suspicious IPs from multiple sources. (1) the DHT reports masquerading IPs when the same DHT peer claims to have multiple IPs at once; (2) friends exchange suspicious IPs using a dedicated service; (3) you might enter IP ranges to ban manually. In the interface, you can then choose how drastically you want to use the blacklist: ban everything or just ranges automatically created for you. The default settings should keep you reasonably safe.
    A white list allows to override the blacklist. The white list is totally controlled by you, and is quite useful to remove  false alarms raised when using the most drastic options from the blacklist system
    Optionally, you may request some friends to be white-listed before connection. This is a very secure option, but it is painful to use for friends who do not have a static IP. So this option can be switched for each friend independently.
    Once connected using a secure authenticated channel, friends exchange their effective address of connection. If a friend reports to you a contact address that is different than what your Retroshare node thinks its own external address is, a warning is raised in the news feed. This very efficiently detects traffic forwarding. However, false positive warnings will be raised when your IP is changing and a friend connects before Retroshare has figured it outs. Just keep an eye on them.

When many IPs in the same range are reported as suspicious by the DHT, Retroshare automatically creates banning rules for them in the black list. When you’re sure of them, the safe move is to make them permanent (by selecting them, adding a comment and submit them to the black list). To avoid traffic forwarding with 100% efficiency, either require all peers to be in the white list, or use a TOR hidden node.
Under the Hood – New Back-end

The GXS cache system

Forums, channels, posted and identities are all handled by a common back-end system called GXS (General eXchange System), which replaces the old—inefficient—cache system based on file transfer. GXS improves over the old cache system in many ways:

    cache metadata is stored encrypted, using the sqlcipher library.
    the cache uses a differential update system which only transfers what’s needed. As a result the network load due to cache exchanges is  limited to the bare minimum.
    cache storage is much more efficient than in v0.5 and shouldn’t be a problem any longer.

The basic brick of the GXS system is Groups, which is used to represent all actors: forums, identities, channels, etc. It’s quite a complex system which will require a blog post in itself.

The global router

The global router is a passive decentralised data routing system, which securely brings data from one Retroshare Identity to another. It is asynchronous and redundant, which means that you do not need the source and destination of a data packet to be simultaneously online.

The routing mechanism mixes two redundant system: tunnels provided by the anonymous tunnel system (also shared with distant chat and file transfer) and friend-to-friend routing, based on the so called “routing matrix” that encodes for each peer the best friends to which a packet to a given Identity should be sent. The construction of the routing matrix is achieved as forum/channel post signers get known: a friend sending a signature from a given identity will be more likely to be used as a route toward that particular identity.

The global router is currently used to send distant messages between Retroshare Identities. It can also be used by new services installed by plugins, since only the source and destination of a packet need to be able to handle its real content. The global router ensures authentication and encryption of the data that is sent.
Work plan

Our workplan is the following:

    implement identity circles. This is actually almost done. Retroshare still needs a way to encrypt the data that is restricted to a circle of identities in a reliable way. The rest of the software already has what’s needed to manage access rights based on groups. This is currently all hidden in the GUI to avoid confusion with unfinished stuff.
    implement new differential file list system and get rid of the old cache system. The current file list system is the last bit of Retroshare that uses the old cache system. We would like to get rid of it, and take that opportunity to re-design the file list exchange in a way that is more responsive and more efficient. Basically we’re aiming at a differential update using a priority list that would ensure that when you’re browsing friends’ files, they get updated first.
    IPv6 support. This is almost done and preliminary experiments are very encouraging. We still need to make the whitelist/blacklist system compatible with IPv6.
    add a serious video codec to VOIP. Our video codec now is based on encoding each frame in JPEG, which is quite a shame. We need to plug in a x264 codec. If anyone wants to help us with this, we would be eternally grateful. This is not a difficult task since it will not require to understand the Retroshare back end. It needs some knowledge on how to use the codecs and good programming skills. If you feel like doing it, contact us!
    use our own DHT, where we can add a bit more authentication between peers, so that it is not possible to perform large scale traffic forwarding attacks.


As you can see, we have been quite busy. I would like to thank the many contributors to this great project for this step. Beyond the official developers who devote a significant part of their life making the things happen (coding, packaging, debugging, etc) we are constantly encouraged and given very useful feedback by many devoted testers (Special mention to Jolavillette, ASmith), some of which submitted very good patches (Special thanks to Cave, Chozabu, G10H4ck, Henry, Phenom, Sehraf, … please forgive me if I forgot any of you!). Many thanks also to Beluga for the new web site!

We provide builds for windows and all supported Ubuntu. Still missing are builds for Debian (Will be very soon hopefully) and some special distribution-architecture combinations such as debian+arm. Unfortunately we don’t have MacOS builds at this time either, but we’re working on it.

Since this release contains many new features, and we obviously cannot test all configurations, we partly rely on you to send us as much feedback as needed to improve this release candidate 1. We’ll publish an improved version soon based on what feedback we get.

We hope that Retroshare-0.6 will be a step forward to our ultimate goal: providing a social network that can avoid surveillance. It is designed to be powerful and safe, but we cannot ensure you that it is perfectly secure either. So use it wise

Off-Topic / Re: Verschlüsselung und Anonymität im Internet
« on: January 06, 2015, 11:36:56 PM »

Klar, warum nicht mal alte Zöpfe abschneiden und sich mit dem befassen, was

a) funktioniert und
b) tatsächlich aktiv weiterentwickelt wird

Das hat jetzt zwar nichts mit den von crypton genannten Themen zu tun, aber ich stelle trotzdem mal ganz unverbindlich die Frage in die Runde: Wer wäre gegebenenfalls bereit, sich freiwillig für die Übernahme alter Beiträge in ein neues Forensystem zu melden?
Ergo wäre die einzige Möglichkeit, alte Beiträge in ein neues Forum zu übernehmen, dies per copy & paste zu tun und im "alten" Forum dann auf das neue zu verweisen. Das ist zwar nur suboptimal, aber wenn schon eine Reorganisation der Foren stattfindet, dann gleich richtig. :)

Wann hast du das vor? vielleicht kann ich bischen helfen.
Das neue Forum sollte auch den schwerpunkt auf die Sicherheit der Datenübertragung setzen.
Sichere Kommunikation ist wichtig.

Off-Topic / Re: Verschlüsselung und Anonymität im Internet
« on: January 02, 2015, 01:50:57 PM »

Bei den F2F-Netzerken Alliance/Oneswarm tut sich aber auch nix mehr.
Ja leider tut sich da nichts mehr, ist aber eine von den Projekten die noch nutzbar sind.

Eine neue Alternative wäre hingegen:
goldbug ist auch eine modfizierte version von spoton.

Stimmen die Funktionweisen von GnunNet überhaupt noch hiermit ein: ???
Da wurde so viel Umstrukturiert/geändert, was sind die neusten Fakten der Funktionsweise bei Gnunet?

Weiß nicht genau, hab nur gelesen Gnunet entwickelt mit an SecureShare.
Gnunet war bis jetzt nicht so richtig nutzbar meiner meinung.
Vielleicht ändert sich das bei SecureShare
SecureShare prototyp liegt in der subversion repository von Gnunet.

twister is a microblogging peer-to-peer platform, that is, it is a distributed system like bittorrent or similar file sharing technologies.
Being completely decentralized means that no one is able to shut it down, as there is no single point to attack.
The system is also designed so it cannot be censored, freedom of speech cannot be taken from you.
And because the cryptography is employed end-to-end, no entity is able to spy on your communications.


Pages: [1] 2 3 ... 101