Vela QA

"Vela" means "sail (fabric)" in Latin.

Vela is a mix between an instant messenger and an email manager applications.

Vela combines the communication speed of instant messages with the storage features of emails, and adds digital signatures, encryption, reliability of delivery and lack of spam.

Vela has no centralized authentication service. The authentication is achieved with UPNs. A UPN (= Universal Peer Name) is a text made of a few tens of random-looking characters. UPNs are shared by the users like email addresses.

Vela was designed for people who can meet in person so that they can exchange their UPNs, thereby avoiding man-in-the-middle attacks.

Vela was designed so that there can be no spam, not even (unilateral) "friend" requests from (un)known people, not even from people who know your UPN; this is done by ensuring that each person must add an account for the other's UPN to his / her storehouse.

Digital signatures are used to make sure that your contacts receive your letters, and that you are notified of that. Only an extreme conjunction of adverse circumstances can break this assurance, like when your contact's computer harddrive reports to Vela that it has saved the letter (though it has not) and a power failure occurs before the harddrive actually saves the letter.

The encryption is used to make sure that a spy could not even tell that you are communicating with someone else through Vela, unless the spy has your (or your contact's) UPN.

Vela doesn't anonymize the network traffic, so your contacts (or spies who monitor your network traffic) can find out your IP address. (Your IP address is also exposed to the people who receive emails from you.)

Vela is not a distributed file sharing application (like a BitTorrent client is). The integrated peer-to-peer mechanism is used strictly to resolve UPNs to IP addresses. However, Vela does support file transfer. See the How are the files attached to a letter being transferred? question for details.

Vela is for people who want to communicate securely and in a decentralized manner, people who understand that some trade-offs of convenience are necessary for a high level of security.

The main convenience trade-offs are: no log in from other computers (except if you copy your storehouse to those computers), communication may be impossible in some cases (where firewalls block inbound network traffic or port forwarding, or there are NAT devices between the peers, or where IPv6 network support doesn't exist).

To see how you can use at work the storehouse from your home, see the Can I log in to my storehouse from other computers? question.

However, there is also an advantage. Even if you don't have an Internet connection, Vela will still work within your local area network (at least so long as Internet-wide host names are not used as alternative peer addresses). This means that Vela can work within a locked-down company network, where no network traffic is allowed to exit to the Internet.

The following features are not possible because there is no centralized server:

• User-friendly account names, like email addresses.
• Bypassing of (company) NATs. Port forwarding is supported for IPv4 networks, but companies usually disable the (UPnP) protocol in their routers.
• Bypassing of (company) firewalls which block inbound network traffic.

For the average computer user, no. For the average computer user who is willing to gain maximum security in exchange for some comfort, yes.

The PNRP is a bit sensitive. Normally, peers are (automatically) found on the network by using the PNRP. However, at least in some cases, especially when it's stressed a bit, it needs even tens of minutes to reach a state in which it can find peers over the Internet.

If you think that the PNRP unacceptable, you can set the alternative peer address for each account, with the remote peer's IP address or host name (use dynamic DNS). For details, see the tooltip of the "Alternative peer address" text-box from the "Edit Account" window, and the How does Vela perform peer routability? question.

Vela is decentralized, that is, it really is just an application, not a service, not even for authentication.

Everything is stored (in encrypted form) on your computer, including the letters that you send and receive.

Letters are sent encrypted and are digitally signed.

A letter can send thousands of files of any total size. File transfer resume is supported.

Letters can be transferred offline peer-to-peer (that is, even when their computers are not connected to the Internet), by exporting and importing them.

Vela's network traffic looks like random data. The PNRP network traffic, used to resolve UPNs to IP addresses, makes exception.

The emoticons are large (192 pixels in height) and gorgeous.

The color scheme has a black background which protects your eyes during prolonged use.

Vela is open source and public domain.

Vela is a mix between an instant messenger and an email manager applications, but real time communication is more natural in Vela.

Vela is designed from the ground up to be secure and have no data leaks, at least none other than IP addresses, a type of leak which occurs with virtually all means of online communication.

Vela has support for offline messaging. See the How can I use Vela only offline? question for details.

Vela shows you a digitally signed receipt confirmation, thus guaranteeing that you know exactly when your contacts actually receive your messages.

Vela allows you to transfer thousands of files of any total size, together with a single message.

Vela doesn't require you to sign up with a service, and will therefore not centralize your messages like email providers do.

Vela is as decentralized as possible.

Vela normally finds peers using the PNRP Windows service. This service needs to connect sometimes to some bootstrap servers. According to the documentation, peers are found using the entire network of peers, in a decentralized manner, without (necessarily) using the bootstrap servers. The bootstrap servers are used (only) to link otherwise isolated islands of peers.

The bootstrap servers are, by default, Microsoft's, but they can be changed in your operating system's configuration.

To reduce this centralized dependecy, Vela stores the last known IP address of each contacted peer, and tries to use it directly the next time it will attempt to communicate with the remote peer.

Using the PNRP can be avoided by using the alternative peer address. See the Can Vela be used on a network without IPv6 support? question for details.

A "Universal Peer Name" (UPN) is a random-looking text which provides name resolution, encryption and authentication between peers. Two people can communicate securely if they exchange their UPNs.

Here is a sample UPN: KSF4 G6M3 UK3Y 1V3R DZ8C GA1M N46T 3A22 VZG4 0U46 1BS4 78XP UXUK 0

A UPN is generated from the public information of a digital identity. No personally identifiable information can be extracted from a UPN.

The following UPN properties are generated from the UPN: fingerprint, long and short host labels, classifier, and symmetric encryption key. It's practically impossible (with cryptographic certainty) to find out any of a UPN's properties from any other.

In order to avoid man-in-the-middle attacks, UPNs have to be exchange in person.

It's safe to first exchange the UPNs through unsafe communication mechanisms (like email), so long as the UPNs are later verified (= reexchanged) in person; only from that moment on you can be sure that there was no and there will be no man-in-the-middle attack.

Since a UPN is generated from the public information of a digital identity, and since the UPN you are given by a contact of yours is compared with the UPN from the presenter of that contact (presenter which is retrieved by Vela through the network when you add an account), you can be sure (with cryptographic certainty) that you send letters to and receive letters from the person who has given you the UPN.

People who have your UPN (or its long host label, short host label or classifier) can find out your IP address (but only so long as your Vela application is running and keeps your UPN registered on the network).

Your UPN fingerprint is exposed when a contact of yours sends you a document (as a file, not through Vela's network communication mechanism), like a securing document. This happens because your UPN fingerprint is used as a locator. You can be sure (with cryptographic certainty) that someone else who sees such a document, can't find out your IP address (from your UPN fingerprint).

Your operating system has to be at least Windows Vista SP2. Your display's resolution should be at least 1200 * 720 pixels.

Because Vela uses Microsoft .NET 4.5, dual-stack IPv6 and PNRP 2, it requires at least Windows Vista SP2.

You can find the requirements for the Microsoft .NET 4.5 (and also download the installer) from here.

The (integrated) firewall configuration utility requires at least Windows Vista.

The feature which shows letter notifications in the taskbar requires at least Windows Vista.

Vela needs to have IPv6 network connectivity. In a default Windows installation, you have an IPv6 connection (if your network has IPv6 support), but this might be disabled by default in your router (if you use one), and your Internet service provider might not offer you IPv6 Internet access.

To check if your computer has an IPv6 connection, visit this.

Also see the How should the firewall be configured in order to be able to use Vela? question.

If you are comfortable with handling IP addresses or host names, see the Can Vela be used on a network without IPv6 support? question for details about how to use Vela on a network without IPv6 support.

Download Vela from its website. A file called "vela.zip" will be saved on your computer.

Unzip this file in a folder, of your choosing, on your computer. It's recommended that this be your computer's "Program Files" folder; port forwarding will not work otherwise.

In the chosen folder you will now find a sub-folder called "Vela".

In this sub-folder, you will find a file called "Vela.Im.exe". Run this file in order to start the application.

Vela will ask if you want to automatically create the firewall rules. It's strongly recommended to accept this. See the How should the firewall be configured in order to be able to use Vela? question for details.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

Follow the instructions shown in the application's "Quick Help" window in order to create your first vault, send your UPN to a contact of yours, receive that contact's UPN and create an account which links the two UPNs.

In order to resolve UPNs to IP addresses, Vela uses the PNRP implemented in Windows, and this requires a network with IPv6 support.

It's possible to avoid using the PNRP protocol by using the alternative peer address.

For details, see the tooltip of the "Alternative peer address" text-box from the "Edit Account" window.

See the How does Vela perform peer routability? question for details.

In order to resolve UPNs to IP addresses, Vela uses the PNRP implemented in Windows, and this requires a network with IPv6 support.

See the Can Vela be used on a network without IPv6 support? question for a way around this limitation.

IPv6 network support is mainly dependant on the network service providers.

To check if your computer has an IPv6 connection, visit this.

In order to resolve UPNs to IP addresses, Vela uses the PNRP implemented in Windows.

It's possible to avoid using the PNRP protocol by using the alternative peer address.

For details, see the tooltip of the "Alternative peer address" text-box from the "Edit Account" window.

See the How does Vela perform peer routability? question for details.

If you use a router, this is likely having its own IPv6 firewall which may block the PNRP network traffic. You can add in the router a firewall rule to allow network traffic on the UDP port 3540; to specify that all IPv6 addresses are allowed, use "::/0" (without the quotes) as local or remote IPv6 address. Alternatively, if you use a software firewall (the Windows Firewall is enabled by default), you can disable the router's IPv6 firewall.

Vela tries to perform automatic port forwarding when the computer on which it runs is connected to a router.

Port forwarding allows your contacts to reach you using an alternative peer address, using your IPv4 address.

The processing ports of the current storehouse, and the processing ports of the vaults from the current storehouse are forwarded.

If you reboot your router, it will lose its (dynamic) port forwarding rules configured by Vela. In this case you should restart Vela, if you know that some of your contacts are using IPv4 to communicate with you.

Yes, but there are some conditions.

The best solution is for the company to have IPv6 network support for the Internet, to allow inbound traffic for the dynamic ports (those between [49152...65535]), and to implement the firewall rules detailed in the How should the firewall be configured in order to be able to use Vela? question.

Chances are that your company either doesn't have IPv6 network support, or the firewall blocks incoming connections, or it blocks UDP traffic (which is necessary for PNRP), or blocks port forwarding (specifically, the UPnP protocol in the routers). See the Does Vela work if my computer is connected to a router? question for details.

So, chances are that you will not be able to use Vela to receive letters from outside the company's network.

However, it's likely that you can fully use Vela inside the company's network. To do that, you and your contacts will perhaps have to fill in the "Alternative peer address" text-box when each of you add a new account with a UPN.

The value which has to be put in there is the host name of the computer of the remote peer / contact for which the account is created. For details, see the information copied to the clipboard by the "Clip alternative peer address information" button from the "Edit Vault" window, and the tooltip of the "Alternative peer address" text-box from the "Edit Account" window.

You can send letters, but you can't receive letters.

To do this, your home computer has to be accessible with an alternative peer address. It's recommended to configure a host name (use dynamic DNS) for your home computer. For details, see the information copied to the clipboard by the "Clip alternative peer address information" button from the "Edit Vault" window.

At work, export the presenter of your vault.

At work, add an account with the UPN of your home vault. Make sure to fill in the alternative peer address with the host name of your home computer. Alternatively, see the next step in order to understand how you can create the account using your home presenter.

At home, create an account by importing your work presenter, from the Vela's "Vaults" tab, using the "Add account with file" context menu. Your home vault must be focused.

Your company's firewall may be so restrictive that you may need to override the remote port when you create the account at work. This is the case if your company allows outbound network traffic only for the HTTP(S) protocol (to the remote ports 80 and 443). See the How can Vela work through a strict firewall? question for details.

Once both your work and home computers are online and running Vela, the account on your work computer will be created and you will be able to send letters to your home computer.

However, you will not be able to send files because files are being downloaded by the recipient, not uploaded by the sender, and the company's firewall blocks exactly this kind of behavior. Files are being downloaded by the recipient because this makes it easier to code the process, especially the resume feature.

Global IP address routability is a fundamental design goal of the Internet. It means that one computer can directly communicate with any other computer in the world. However, in IPv4 networks, global routability is broken, that is, it sometimes work, it sometimes doesn't. This has been fixed in IPv6 networks.

"Peer routability" means that a peer can find another peer, anywhere in the world.

Vela has no centralized services. Therefore, peer routability is more limited than in the case of the systems which use, for example, a centralized authentication service, where the centralization acts as a work-around for the broken global routability in IPv4 networks.

Vela uses the peer routability mechanisms listed below.

Vela normally finds peers using the PNRP (Windows service).

This is the preferred and default mechanism because it's automatic. However, all the peers who communicate must have IPv6 network support.

Using the PNRP can be avoided by using the alternative peer address.

This method requires manual user configuration.

This is the most decentralized mechanism, but IP addresses usually change, so all the peers who communicate must synchronize their IP addresses through other communication channels (like phone calls, emails).

Fixed IPv6 addresses are easier to obtain, but all the peers who communicate must have IPv6 network support.

For details, see the tooltip of the "Alternative peer address" text-box from the "Edit Account" window.

Using the PNRP and IP addresses can be avoided by using a host name (which is resolved by a dynamic DNS service).

This method requires manual user configuration. You can either use an external service, or your router's feature (which still uses an external service, but it's easier to configure).

If the host name resolves to both IPv6 and IPv4 addresses, the IPv6 ones are used first.

For details, see the information copied to the clipboard by the "Clip alternative peer address information" button from the "Edit Vault" window, and the tooltip of the "Alternative peer address" text-box from the "Edit Account" window.

No, but most users need it for comfort. PNRP is only needed to resolve UPNs to IP addresses. Once a UPN is resolved, the PNRP is no longer used for that UPN so long as the remote peer can be contacted at the last known IP address.

Even if the (remote) IP address changes, if the remote peer contacts you, the IP address is updated in your storehouse, so Vela will be using it from that moment on.

Yes. For example, someone could block the PNRP bootstrap servers at a country's level. The IP addresses of the users would expire in a few hours or days, so the IP address caching from Vela would quickly become useless.

Despite such an attack, it's still possible to communicate through Vela by setting the alternative peer address (of each desired account) with a host name which is resolved by a dynamic DNS service. However, due to the extra necessary steps, this is not suitable for everybody.

Obviously, for this solution to work, a little known dynamic DNS service has to be used, otherwise it could be blocked as well.

The following information is sent outside your computer:

• The information that is required to register your computer on the peer network. The peer network is formed by the computers of all the available peers, and also the PNRP bootstrap servers that are managed by Microsoft. This information is handled by the underlying infrastructure of the operating system, specifically by the PNRP Windows service.
• The information that is required to let you communicate with other peers. This information is handled by Vela.

Vela doesn't "phone home" (even for application updates).

When you communicate with someone, the IP addresses of both of you are exposed.

When your Vela application is running, it registers your UPN classifier on the network, exposing it to everybody.

See the What is a UPN? question for details.

People who have your UPN (or its long host label, short host label or classifier) can find out your IP address (but only so long as your Vela application is running and keeps your UPN registered on the network).

People who have your IP address may find out your physical location with a varying accuracy, normally only the city.

As a side note, your IP address is also exposed to the people who receive emails from you.

There might be, depending on your threat expectations.

Although your UPN may be made public without influencing the security of your communication, there are some advantages in keeping it hidden from the public:

• Nobody other than your contacts would know that you are communicating through Vela. To other people, the network traffic of your Vela would appear random data that could be generated by an unknown application.
• People who have your UPN can find out your public digital identity. Then, they can verify the signatures of the documents that you have sent to other people.
• If your UPN is public, a large scale organization may create (on the network) a large number of fake registrations for that UPN, fact which would make it (almost) impossible for other people to find your UPN registration.
• While peers find themselves through UPNs, they actually communicate through IP addresses, so a criminal can find out your IP address and then launch a denial of service attack on your computer.

It's recommended that you only share your UPN with your trustworthy friends and acquaintances. There is no point in sharing it publicly since Vela was specifically designed for people who already know themselves.

As a side note, you don't share your email address publicly for some of the same reasons.

Those people may find out your physical location with a varying accuracy, normally only the city.

Like any other application which connects to the network, Vela connects peers using IP addresses. Anyone who knows your UPN can find out your IP address and put it through a geolocation service (like WhatsMyIp, see the "IP Location" function), learn your latitude and longitude, and then use a map (like Google Maps) to find out your city.

As a side note, your IP address is also exposed to the people who receive emails from you.

As secure as it can possibly be. The entire philosophy behind Vela is to ensure that only the individuals involved in a communication can see what is being communicated.

Vela uses symmetric and asymmetric encryption, digital signatures, steganography, random-looking data and random communication ports in order to achieve the highest possible levels of security, trust and privacy during your communications.

While there are ways to also hide the IP addresses of the peers who communicate, that is done at a great performance costs, so Vela doesn't do this.

To understand how Vela transfers information between peers, see the How does Vela transfer information between peers? question. There, you can see that the privacy of the network traffic depends on the privacy of your UPN (and on the privacy of the UPNs of your contacts). If your UPN (or the UPNs of your contacts) is known to "them", "they" know (that you are using Vela).

If the answer to this question were only to depend on Vela and the privacy of UPNs, nobody would know that you are using Vela. Unfortunately, this is not the whole story; there are several telltale signs that you are using Vela.

The first telltale sign is if you download Vela from its home website. In this case, "they" know (that you are using Vela).

The second telltale sign is the PNRP protocol, protocol which communicates information publicly, so "they" know that you are using it, although this protocol is also used by other applications. This can be disabled, but then you and your contacts would have to use the alternative peer address.

The third telltale sign is the traffic filter integrated in Vela. This is meant to protect your Vela from denial of service attacks. The filtering rules are rather specific, so "their" suspicions (that you are using Vela) may become solid if they actively send information to your computer's network ports until their requests are blocked. Starting with version 2 of the program, the default rules are set so high that an attacker can't practically deduce that this program is being used by the attacked target; the disadvantage is that the attacked target can't be protected from denial of service attacks.

The fourth telltale sign is the action request retry mechanism integrated in Vela. This is meant to automatically send action requests to their recipients when they come online after some period of time of being offline. Starting with version 2 of the program, the retry rules are (partly) random, so longtime, continuous monitoring and statistical analysis of attacked target's network traffic would have to be performed in order to use this as a telltale sign.

No.

Vela is not a service. Vela has no centralized authentication service, no centralized storage mechanism, no "phone home" feature (not even for application updates), is open source, public domain and free.

The decentralized authentication means that the Vela Entity is also unable to block a specific user from using Vela. However, you can block any contact of yours by setting the "Approval" for the account you want (see the "Approval" combo-box from the "Edit Account" window of that contact), or by deleting the account.

Microsoft's bootstrap servers are used by the PNRP only when UPNs can't be directly resolved by the peer-to-peer network, and also to ensure that different peer-to-peer network islands don't remain isolated from all the others.

This means that Microsoft can know what IP addresses are using the PNRP, and (to a limited extent) what peer addresses (= a more generic type of UPNs) they are trying to communicate with. However, Microsoft can't know whether or not these users are using Vela or some other application which uses the PNRP.

Aside from this type of relation identification that Microsoft could perform, Vela transfers information strictly peer-to-peer, without any sort of centralization in between. Third parties can't see what the transferred information is, can't see what the data's actual size is (since some random padding is added to all the messages), and can't see that Vela has created the data because this is encrypted once more with a UPN derived secret. See the How does Vela transfer information between peers? and the Does Vela protect the size of the transferred information? questions for details.

Even if Microsoft would decide to alter / highjack the PNRP's functionality and resolve peer addresses to wrong IP addresses, the only effect would be the innability of the peers to communicate through Vela while the PNRP is active. The security of the transmitted information would not be affected one bit.

If you still have issues with using the PNRP, you can use the alternative peer address to bypass it. This allows you to use either IP addresses or host names to identify your contacts. However, this will require some manual configuration by all the people who want to communicate in this way. See the What is the alternative peer address? question for details.

If you believe that any form of Vela's online activity may compromise you, Vela can work offline. You can export letters your letters, send them through whatever alternative communication channel you want, and the recipient can import your letters. See the How can I use Vela only offline? question for details.

Yes. The communication security depends on the Vela protocol, not on the network.

If an attacker were to alter / highjack the DNS's functionality and resolve domain names to wrong IP addresses, the only effect would be the innability of the peers to communicate through Vela while domain names are used. The security of the transmitted information would not be affected one bit.

Yes. The communication security depends on the Vela protocol, not on the network.

If an attacker were to alter / highjack the network's routing functionality and route IP addresses to wrong computers, the only effect would be the innability of the peers to communicate through Vela. The security of the transmitted information would not be affected one bit.

Since Vela is decentralized, there is no limit to its scalability.

However, Vela uses some infrastructure network resources which are, to some extent, limited.

For example, the documentation states that the PNRP scales easily to billions of peers.

The dynamic DNS services which can be used in the alternative peer addresses also have a limited scalability; still, they are a distributed network resource. Since this is a manually activated feature, it doesn't concern most users.

Letters work more like emails than traditional instant messages, but the messaging system is less formal than email (because there is only the email's message) and more reliable than both email and instant messaging (because there is cryptographic proof that you get an error if the letter is not delivered).

Whenever Vela has to send a letter, it actually queues it into a module which continuously tries to send it until it receives a signed confirmation of its reception (, or until the request expires).

You can see the state of each letter. The "Sent" state means that the letter has been received by the recipient, and that a confirmation signed by the recipient was received by your Vela.

It is not guaranteed that the letters are sent and received in the order in which you have created them.

Yes.

Letters are signed when they are sent, and their signatures are verified when they are received.

In order to prove who the sender of a signed letter is, it must be proven who owns the identity associated to the UPN of the sender of the letter.

Since a peer responds to requests to resolve a given UPN, the responding IP address is therefore from where the UPN (and its associated identity) is controlled. If the sender deletes the vault (from his / her storehouse) to which the UPN belongs, that UPN can no longer be found over the Internet and therefore its ownership can't be proven (with cryptographic certainty) anymore.

To guarantee the identity of the sender, or at least that the sender has the private identity (it may have been stolen), and at the same time retain the sessionless and offline mode properties of letters. Also, so that a business party can easily prove the promises made by another business party, without any of them having to even think or require that those promises be (manually) signed.

Home users are normally not affected by this feature.

The users who may be harmed if their signed letters are found on someone else's computer should see the Can I send unsigned letters? question. For details on why the signatures are irrelevant anyway in such a case, see the Does Vela provide backward secrecy? question.

The same as the total size of the files stored by the computer of either the sender or recipient of the letter.

While you may attach thousands of files to a letter, you should not attach many more than this. The total size of the attached files is not intrinsically limited. Tests with over 10'000 attached files have shown an unpleasant lack of responsiveness of the user interface (when attaching the files and queuing the letter).

The recipient rejects the letter with the attached files if the available hardrive space can't store the attached files plus an extra gigabyte of data.

The transfer of the files should end in 16 days from the moment when the letter was received. If it does not, and if the transfer is interrupted at some point after that, it will no longer be able to resume (and will fail permanently).

If this happens to you and it's a huge problem, you can still resume the transfer manually. Because the progress of the file transfer is determined based on the current size of the saved files, it's possible to do this with relative ease.

Ask the sender to send again (just) the (huge) file where the transfer was interrupted. Allow the transfer to start on your computer; for this, check that the file is created in the download folder. Then, stop Vela, rename the old folder (where the transfer was interrupted) as the new folder (the new file can be discarded without problems), and restart Vela. Now, the file transfer will continue from where it stopped in the old folder.

Files are being transferred as easily as you send a letter, as user-friendly as email attachments. Type a message, browse and attach files, send the letter and the recipient starts to automatically download even hundreds of gigabytes of data from your computer.

Files are not shared in the sense of file-sharing applications (which use the BitTorrent protocol), that is, a peer can't browse for files to download from another peer's computer.

Because of the way in which the file transfer works, you can send files which are stored anywhere on your harddrives, that is, you don't need (for security reasons) to have a single folder which contains all the shared files.

Note that the recipient can find out where each transferred file is stored on your computer, so there may be accidental slips regarding the full name of the parent folders of the transferred files. Basically, if you want to send files to Bob, don't put those files in a folder called "Bob sux".

Nobody else can download the files that you have sent to one of your contacts. This is enforced by checking the signature of the recipient of the files, on the sender's side. While the recipient can't (directly) forward the "download link" for the files, he / she can send the files to someone else once they are downloaded on his / her computer.

For security reasons, the names of the downloaded files have an underscore character appended to their ends, except for a few types of files which are known to normally be free of malware, like text and media files. So, if you want to use the files with "unknown" types, make sure that you remove the underscore (after they are completely downloaded). If you want to transfer thousands of files of unknown types, it's better to add them to an archive and attach the archive to a letter.

Severely, at least when it's compared to the maximum possible speed of a local area network. However, it's unlikely that you would be affected by this, unless the network over which the transfer occurs is actively capable of a very high speed.

Tests have shown that, for a 1 Gbps wired local area network, the transfer speed (for large files) is about 13 MB / s, which is more than what a normal Internet connection supports.

If you are transferring a large number of files, for maximum performance the average size of the files should be at least several hundred kilobytes.

The default value is 10, but this may be changed in Vela's configuration file. This number is separate for the service and client modules of Vela, and separate for each service port.

This becomes visible if you are sending or receiving this many letters with attached files, files which take more than a few seconds to transfer.

For maximum security, or if you don't have a network connection, Vela can also be used only offline. Even if your computer is connected to the Internet, you can switch Vela offline by unchecking the "Peer is online" check-box from the "Application Configuration" window.

Once you create your vault, you have to export your presenter (from Vela's "Vaults" tab).

Send the presenter to your contacts.

A contact can create an account linked to you by importing your presenter (from their Vela's "Vaults" tab, using the "Add account with file" context menu); the vault to which the account is linked must be focused.

Each peer can send letters normally, although they will not reach their recipient since there is no network connection between their sender and their recipient.

To actually send the letters to their recipients, they must be exported (from the "Letters" tab, using the "Export" context menu); each letter to export must be focused.

An exported letter must be sent to its recipient through an alternative communication channel.

The files attached to a sent letter will not be exported as part of the letter, so they will not be sent to the recipient.

The recipient must import the letter (from the "Letters" tab, using the "Import" context menu).

Vela stores everything (except the attached files) related to peers in a storehouse. You can have as many storehouses as you want.

A storehouse is a set of files which contain various information, like vaults, tallies, accounts, letters.

For example, the following files make a storehouse called "John": "John.vstore" and "John.vstoreattach". Note that both files, together with the storehouse password, are required in order to be able to open the storehouse.

In order to keep your information safe, BACK UP / copy your storehouse(s) outside your computer, for example on memory sticks or external harddrives.

A few other things are stored in the application configuration file. This file contains only non-critical information, so you can delete it at any time.

The underlying database engine (MS SQL CE) limits a storehouse's capacity to about 350'000 letters; transient letters don't contribute to the occupied space. This number was obtained as an average from over 5'000 (sent and received) letters.

This scenario is important to the people who want to use the same UPNs both at home and at work. In such a case, you might create your storehouse at home and want to use it at work as well.

Vela has no centralized authentication service, so you somehow have to log in (from work) to the storehouse from your home.

To do this, you can either use a remote desktop application to connect to your home computer, or you can copy your storehouse to your work computer.

In the first case, you have to be aware that if the connection between your home and work computers is interrupted, you will not be able to send letters or see the received letters.

In the second case, you have to be aware that the storehouses from home and work will not be synchronized, that is, the changes that you will make in either of them will not be present in the other.

Also, in the second case, if both storehouses are running, you will receive letters in only one of them. Which will receive the letters is determined by the network parameters of both you and the contacts who send you letters. This means that if you are at work and the letters are received at home, you will be unable to respond to those letters until you get home. This issue can be avoided if only one of the storehouses is runnig at a time.

When you type your password, a character (from 3 possible) that you have not typed is shown in a password box. These characters are in no way related to the characters that you type, and therefore they can NOT reveal your password.

Their goal is to give you an idea of how many characters you have typed, and also if the confirmation password is a match.

A strong password should have at least 6 random words, or 16 random characters.

Random passwords are difficult to remember, and since the most secure and useful password is the one that you can remember (and that you are willing to type every time it's needed), a phrase (= text which doesn't contain random words) may be a better choice. If you intend to use a phrase then you must use a password obfuscation algorithm.

You can generate random characters for your password by rolling two dice, one roll yields one character.

You should use two different dice, one for the horizontal axis and one for the vertical axis of the table below. The dice should have round corners and edges, to roll easier. Use this table to convert the rolled values to characters.

A password obfuscation algorithm is a mechanism by which you convert a simple password (like a phrase) into a complex password (which is typed into a password window, in an application which requires a password).

Examples of obfuscation algorithms:

• Invented words.
• Merged words.
• Misspelled words.
• Grammatical mistakes.
• The original words translated in various languages.
• Antonyms or synomyms of the original words.
• Combining parts from several phrases.
• A phrase with the words in reverse order (from the end toward the beginning).
• Only the consonants of a phrase.
• The mixed letters of the words, like the first letter from each word, then the second, and so on.
• The first X characters of each word.
• The first and the third characters of each word.
• Every second character of each word.
• Double every third character of each word.
• Write a phrase in a bi-dimensional matrix (with X rows and Y columns) and choose a path (like in the form of a character) which you'll use to extract the characters that you'll type.

No.

People have been continuously telling you that a password is strong only if it contains non-alphanumeric characters and both letter capitalizations. Now Vela tells you otherwise. You are obviously asking yourself who is right.

From a security point of view, no variant is more right than the other. However, using non-alphanumeric characters and both letter capitalizations will increase your chances to forget a password.

In fact, Vela recommends you to use only alphanumeric characters and a single letter capitalization in order to make your password easier to remember, and to be able to generate it randomly with dice.

This limited set of characters does not decrease your security because this security depends on both the total number of possible characters and on the size of your password, which means that if you have a smaller set of possible characters, just use longer passwords to compensate.

Consider that the keys of a keyboard can each generate a character. In order for you to use non-alphanumeric characters and have both letter capitalizations, you have to press the "Shift" key together with another key (this generates the alternative character of each key).

The "Shift" key is basically a password obfuscation algorithm which is present on the keyboard. By pressing the "Shift" key you add 1 bit of entropy to your password: yes / no, on / off, uppercase / lowercase.

From the point of view of an attacker, your ability to press the "Shift" key adds 1 bit of potential entropy for each character from your password. This is because while in general you will not press the "Shift" key, the attacker knows that you could have pressed it while typing any character from your password.

But what if you don't use the "Shift" key? It's quite simple: type twice (or more) the keys for which you may have wanted to press the "Shift" key. Either pressing the "Shift" key or typing twice the key has the same effect on security, typing speed, but allows you to generate passwords randomly using dice.

Enforcing letter capitalization and special characters in passwords is pointless. Users can have passwords just as secure without special characters, passwords which require the same effort to memorize: press the "Shift" key or double a character. Applications which require strong passwords should simply check the passwords of the users against a dictionary of weak passwords.

Take a sheet of paper and fold it three or four times. Tear the sheet in the pieces of paper delimited by the folding edges. Stack the pieces of paper.

Create a password as shown in the How can I have a strong password? question.

Write the password on the top piece of paper; you should, perhaps, not write a few of the characters (just memorize them).

Burn the remaining empty pieces of paper and destroy the resulted ash.

Type the password daily. At some point, you may be confident enough to burn the written password.

There is no need to change a random password, even for decades, unless you know or suspect that it has been compromised. Why can you keep for so long? Well, if your password is compromised once without your knowledge, what makes you think it would not be compromised again (without your knowledge)? That's why, in order to change your password, you have to at least suspect that it was compromised and how it was compromised.

See the tooltip of that element.

Some 8 years. The idea has been floating around for even longer, but its form has changed continuously.

The project took about 2'000...2'500 hours of researching, planning, creating patterns, writing and rewriting code, describing what is being done, designing a user interface, searching for emoticons, and testing.

This much time was necessary because Vela is an application based on a framework, the Vela framework. A framework has a wider purpose than an application, has to be reusable, and has to be future proof.

With current technology, dropping the framework and storehouse requirements, an experienced programmer who knows what he / she is doing would be able to do something similar in a tenth of the time.

Because the security of a civilization begins with the security of its individuals.

Because the world is heating up, asking for freedoms, while its leaders strive for total control, thinking that humans are machines. Nothing can change the nature of a creature other than outside change, Nature itself, the Evolution of others.

Because in order to create an email account, one has to give his name, birth day, phone number (where an activation code is sent), zip code, another email address, answer several "secret questions", decipher more and more twisted "captchas" and wait longer and longer for emails to arrive, if arrive at all. That is not evolution.

In between these, you can throw anything you think is wrong with this world...

... But the most important reason is that one day you stop philosophizing and start building. THAT is evolution.

This goes right to the heart of the questions of what a human is, what is human nature, and what is the difference between a human and an ape?

The answer is simple: more psychological barriers which result in caring for more than life itself, more than one's own life. Humans have long arose from the primordial soup where the mere survival of life was crucial.

What do privacy-conscious humans care about? They care about some things that together form a distinct personality. They care about life, liberty, self determination (opposite to the will of the majority), love, personal symbols, consistent moral principles, intimacy (they are not a part of the primordial soup where all life forms are a single entity), secrets, personal choice to suffer while fighting for the ideas and ideals that Nature has put into their brains, suffering while resisting those who want to control them.

Or in simpler words, they care about being a human who acts, not a machine which reacts.

Evolutionary speaking, such people are willing to pay higher costs in exchange for possible higher gains. Such people don't choose the path of the minimal resistance, they fight to have more.

How much more important is it?

Perhaps the best way to bring clarity in this matter is to understand why murder is relevant to humans. Most people would say that it is because the victim's body is no longer alive, it no longer moves.

But that isn't the whole story. In fact, it's just the secondary effect. The primary effect is that people's minds are affected.

For example, if a stone is crushed, the stone doesn't care, other stones don't care, people don't care. The stones have no minds to be affected.

People care about their bodies, the bodies of their relatives and friends, and the bodies of people like them. They don't want those bodies to be physically or mentally hurt, they want to use those bodies as they see fit.

In other words, if Alice wants to kill Bob, Bob's mind refuses to relinquish the control it has over its body, it refuses to allow Alice to control / hurt the body. Bob's mind requests that Alice does not act in a way which affects his body and mind. So the crime here is Alice's action which affects Bob, while Bob's mental refusal is the proof of life, of importance of action.

This refusal matters most. It is the mind's ability to say "No" that makes the distinction between humans / life and machines / objects. Of course, the mind suffers with various intensities depending on what is happening, and if the body is killed, the mind probably suffers most.

The mind's importance becomes even clearer if we consider that the crime is rape where the body is not physically hurt. It is now that the refusal of Bob's mind to relinquish the control (it has over his body) becomes paramount. Yet, the response of any psychopath, told with what he / she thinks is a shrewd sense of humor, is "Then just don't fight it / me!"

It is the mind's ability to say "No" to someone else, that represents the critical factor, and the intensity with which it feels affected and wants to go its own way makes the difference between crimes.

Those who think that the privacy of billions of people is irrelevant when compared to the death of people, could now understand that the (intensity of the) effect on "our" and "their" minds is dramatically different.

From a simpler perspective, the statement which is answered here is used to justify the destruction of privacy since this has no visible physical effects, while murder has. But the reverse it also true: the means to protect privacy have no visible physical effects, and it's only the murder itself that has. Consequently, if you want to fight crime, fight the actual actions which have visible physical effects - the murder itself.

Someone might say that people are not above the law. It's true, they are not above it, but they are the law, they make it and unmake it, their collective actions and inactions determine the law. You, however, are not the law no matter how much you want this to be true. Most importantly, you are not above the people that you want to control, and only people's inactions may allow this to happen.

Someone might say that the short term consequences are more important then the long term ones. But before thinking that a civilization should be a prisoner of a few leaders who want to know everything you say and do, and who tell you what you may and must say, or may and must do, take a good look at those leaders, look at their abuse of power and how they cling to it. Do you actually want to give these leaders more power?

Was all this too philosophical? Then, to all those who want to invade my privacy and control my mind, body and life, I say, from the bottom of my heart, "Get the hell out of my life!"

But the reality is that most of the invaders will not stop. Moreover, it is at this point that a wannabe dictator's main philosophical question comes to life: "So what? What can they do about it?"

The answer to this question is, here and now, Vela. Others may do other things.

And if anyone doubts the intensity of the above request, just think that all the time which has been invested in Vela had to be invested because of the people who think that privacy doesn't matter, and that humans are objects for others to control.

No.

See this.

A car (/ software) manufacturer (/ developer) sells you (or gives you as a prize) a car. You now own the car, but not the name / brand. You can now sell the car, but not the name / brand.

In very limited circumstances, yes. See the license for details.

If you want to use the emoticons in your application, you have to buy them.

See the Credits section for the list of artists who made the emoticons.

If they are outside your budget, you should take a look at the ones from icons-land.com.

Donations are not accepted at this time.

Original development and non-emoticon images: Gardener of Thoughts.

Cryptography (source code modules): Chew Keong Tan, Kazuki Oikawa, mono-project.com (Matthew S. Ford, Ben Maurer, Thomas Neidhart, Sebastien Pouliot, Pieter Philippaerts), bouncycastle.org.

Programming knowledgebase: stackoverflow.com.

Emoticons: Yael Weiss, Visek Art, BNP Design Studio, Ron Leishman, Pushkin, R Formidable, KJ Pargeter, Melisende Vector, Maya Wizard, Ralf61, Cory Thoman, Michael Travers, Lisa Arts, Oligo, Dero CZ, Andrei Marincas.

Ghost emoticon: Inky2010. This image was released by its author under the Creative Commons 0 Universal License, Public Domain Dedication.

Thanks go to clipartof.com for their simple license terms and great support.

An account alias is meant to uniquely identify an account, but the uniqueness is not mandatory. When enforced from the application configuration, aliases ensure that you don't accidentally send a letter to the wrong peer.

An account alias can always start a draft letter and is removed before the letter is sent. While typing, if the program detects that a draft letter starts with an account alias followed by a white space, it automatically switches the active account to the account which is uniquely identified by the alias.

If the "Letters may be sent only if they are prefixed with an account alias" check-box from the "User interface" tab from the "Application Configuration" window is checked, a draft letter may be sent only if it's prefixed with a unique account alias. If the account alias is not mandatory, you might accidentally send a letter to the wrong contact. Of course, you can still mistakenly type another alias, so you can still send a letter to the wrong contact.

When an account is created, the alias of that account is automatically generated from the entity name of the remote peer; by default, an alias starts with "@", but this is not mandatory. You can then modify it in the "Edit Account" window of that account.

Remote peers can't see any account alias that you have.

Drag-and-drop the folders on the text-box where you write the letter's message. The folder itself is not actually attached, but all the files from it are; this means that if new files are added in the folder while the letter is being sent, none of those new files will be sent.

The folder structure will be recreated on the recipient's computer, starting with the title of each dropped folder (not with the parent folders of the dropped folder). For example, if you drop the folder "Z:\Stuff\Trips\2013 - Summer at the beach" on a letter, a folder named "2013 - Summer at the beach" will be created on the recipient's computer, in the folder with the files downloaded for that letter (folder that you can explore with the "Explore attached files" context menu).

"Sending a wallpaper" means that you (remotely and automatically) change the (desktop) wallpaper of a contact.

To send a wallpaper, send a letter with the ";Wallpaper" emoticon and with an image file attached to it. The image file's extension must be one of the following: ".bmp", ".gif", ".jpg", ".jpeg", ".png".

The wallpaper of the recipient will be automatically changed if the recipient has set the "White" approval for your account.

If there are more image files attached, a random one which meets the required conditions is used.

If the letter's message summary has at least 1 character (excluding the ";Wallpaper" and ";=" emoticon symbols, the names of the attached files, and any surrounding whitespaces), it will be written on the wallpaper.

The decentralized authentication means that the Vela Entity is unable to block a specific user from using Vela. However, a user who isn't your contact can't contact you through Vela anyway.

You can block any contact of yours by setting the "Approval" for the account you want to "Black", or by deleting the account.

Open the storehouse manually, go to the "Storehouse" tab and press "Change password" in order change the password of the storehouse to "0123456789" (without the quotes).

Check the "Auto-open last storehouse with the application" check-box from the "Application Configuration" window.

The next time the application starts, the (last opened) storehouse will be automatically opened.

When you see a speaker symbol in the "Files" column of a letter, after the number of attached files, right-click on the letter and click the "Play attached media files" menu.

The configured application will be launched and the attached media files will be loaded by it.

The applications which are launched for each type of media (= video, audio, image) can be configured in the "Application Configuration" window.

The default application is VLC, but you can change this in the application's configuration, in order to use your preferred media player(s).

You can use this for video, audio and image media types.

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --one-instance --no-qt-video-autoresize --playlist-enqueue --playlist-tree --playlist-autostart --no-video-title-show "{PlaylistFileName}"

You can use this for the audio media type.

"C:\Program Files (x86)\foobar2000\foobar2000.exe" /add "{PlaylistFileName}"

You can use this for the image media type.

"C:\Program Files (x86)\IrfanView\i_view32.exe" /one /fs /filelist="{PlaylistFileName}"

You can drag-and-drop image files in the "Select Emoticon" window, in order to automatically update the emoticons in your Vela (with the dropped image files). The existing custom emoticons are never automatically deleted, they may only be replaced.

If the names of the dropped image files are the same as some existing (including predefined) emoticon symbols, the images of the existing emoticons are replaced. Otherwise, the emoticons show up in the "Custom" category.

You should create a folder where you put all the custom emoticon image files. The files may be organized in sub-folders, but the sub-folders don't show up as separate categories. Copy the folder in the "CustomEmoticons" folder from the application's configuration folder. Then, either start Vela, or press the "Ctrl + E" key in the "Select Emoticon" window, in order to update the custom emoticons in your Vela.

The path of the "CustomEmoticons" folder is "[AppData]\Vela.Im", where "[AppData]" is the application data folder path of the user who is currently logged on. An example of this path is "C:\Users\JohnDoe\AppData\Roaming\Vela.Im".

An image file's extension must be one of the following: ".bmp", ".gif", ".jpg", ".jpeg", ".png".

The file titles, without the file extensions, are used as emoticon symbols. Blank spaces are ignored. If you want to use characters which are invalid in file titles, you can instead use the following placeholders (which will be replaced by Vela with the associated characters), without the quotes:

• "{Apostrophe}" -> "'"
• "{Backslash}" -> "\"
• "{Close}" -> ")"
• "{Colon}" -> ":"
• "{Greater}" -> ">"
• "{Open}" -> "("
• "{Pipe}" -> "|"
• "{Question}" -> "?"
• "{Quote}" -> """
• "{Semicolon}" -> ";"
• "{Slash}" -> "/"
• "{Smaller}" -> "<"
• "{Star}" -> "*"

If you need to use a character as a start for the custom emoticon symbols, you should use "=" because it's easy to type.

Once you have custom emoticons in your Vela, you can remotely and automatically update the custom emoticons of a contact. You will then both be able to send (those) custom emoticons to each other. See the How do I update the custom emoticons of a contact? question for details.

You can remotely and automatically update the custom emoticons of a contact, if the contact has set the "White" approval for your account. You will then both be able to send (those) custom emoticons to each other.

If you already have custom emoticons in your Vela, click the "Attach custom emoticons" menu from the context menu of the draft letter (from the "Letters" tab), and then send the letter.

If you don't have custom emoticons in your Vela, send a letter with the ";Emoticons" emoticon and with image files attached to it, images which represent the custom emoticons. From the context menu of that letter, click the "Update emoticons" menu in order to update the custom emoticons in your Vela.

When you send a letter with custom emoticons to a contact, the contact's existing custom emoticons are updated not deleted, so you can send (new) custom emoticons in batches, over time.

You can start using the custom emoticons once the image files attached to the sent letter are fully transferred.

With transient letters.

A transient letter is not signed when it's sent, its signature is not verified when it's received, and is deleted from the storehouse when the application closes (except when the operating system is shutting down).

Even though the transient letters are not signed, the underlying envelopes in which the letters are transferred between peers are still signed. However, since these envelopes are always deleted, the privacy provided by transient letters remains high.

A transient letter doesn't provide a guarantee that it will be deleted from the recipient's storehouse, or that it won't be copied to the clipboard, or that it won't have a screenshot of it taken. A transient letter is just a way to automate the steps required to delete sensitive letters from the computers of both the sender and the recipient.

An orderly automatic shutdown / restart of the computer, like during automatic updates, may delete all the transient letter even if the recipient hasn't read them (because he / she wasn't at the computer between the time when they were received and the time when the automatic shutdown / restart was initiated).

Transient letters do not offer the same level of safety as backward secrecy.

For example, if an attacker intercepts all the network traffic of the recipient of your transient letters, it could force the recipient to relinquish his / her the digital identity, and with that it can decrypt the intercepted envelopes and see your transient letters, even though they are no longer stored on your or your contact's computers. Note that only the recipient's digital identity can decrypt the intercepted envelopes, yours would not work.

This type of attack is somewhat irrelevant considering that the attacker could force the recipient to testify against you, or even to cooperate with the attacker in real-time.

If you want to send only transient letters to a contact, see the tooltip of the "Transient interaction" check-box from the "Edit Account" window of that contact.

Since this answer is rather complex, it's only for people whose lives may be in danger if they are tracked while using Vela. While this process is rather convoluted, it has the maximum flexibility, and once set up it's very efficient in protecting the relationship between you and the journalist.

Remember that Vela doesn't anonymize your network traffic, so someone who monitors the journalist's network traffic may see that you are sending information to the journalist. Therefore, you must use Vela in offline mode. Obviously, this also means that you must not send emails or make phone calls to the journalist.

See the How can I use Vela only offline? question for how to use Vela offline.

The journalist must use Vela (even if it's in online mode), and must create a vault and publish its presenter on some website. In order to avoid man-in-the-middle attacks, the journalist must also publish the vault's UPN and must make sure that the UPN can be read from various places in the world without modifications.

You must get the journalist's presenter through a communication channel which allows you to not be linked to the journalist.

In order to send information to the journalist, you must create an account between one of your vaults and the journalist's presenter, using the "Add account with file" context menu. Your vault must be focused.

If you want to be sure that there is no man-in-the-middle attack, check that the created account has the same UPN as the journalist's UPN.

You can then either:

• Create letters and export them as files that you send to the journalist.
• Create a ZIP archive with all the files that you want to send to the journalist, create a securing document from this archive and send it to the journalist. To create a securing document that only the journalist can decrypt, see the "Create securing document" menu from the context menu of the account which links you and the journalist.

Export your vault's presenter and send it to the journalist, so that the journalist can create an account from it.

Send all the files (including your presenter) to the journalist through a communication channel which allows you to not be linked to him / her. Your presenter must be unencrypted so that the journalist can create an account between him / her and you. Remember that someone who has your UPN or presenter can find out your IP address if you run Vela in online mode (see the How can I use Vela only offline? question for details).

In order to avoid man-in-the-middle attacks you have to ask the journalist to send back to you your entire message (or something particular to your message or files); this works because an attacker can't know what you are telling to the journalist, so the attacker can't respond with what you are asking to receive back from the journalist. This is necessary only one time, usually for the first sent letter.

Visit this in order to check if your computer has an IPv6 connection. If you don't have one then make sure that your ISP has IPv6 network support, and also that IPv6 is enabled in your router (if your computer is connected to one).

Make sure that Vela is in your computer's "Program Files" folder; port forwarding will not work otherwise.

Run the firewall configuration utility from the "Application" tab. If you need to know low-level details about the firewall configuration, see the How should the firewall be configured in order to be able to use Vela? question.

The computer's firewall rules identify an application based on its entire file name (with path), not just the application name, so make sure that you are running Vela from the file path which is in the firewall rules.

Make sure that the router's IPv6 firewall allows inbound network traffic on the UDP port 3540. If you have to manually create a firewall rule, in order to specify that all IPv6 addresses are allowed, use "::/0" (without the quotes) as local or remote IPv6 address. If this doesn't work, if your computer has a software firewall (the Windows Firewall is enabled by default), you can disable the router's IPv6 firewall until you understand how you can add rules (that work) to it.

Make sure that the UPnP protocol is enabled in the router; this is only required if your contacts use IPv4 to communicate with you. This allows Vela to perform automatic port forwarding when the computer on which it runs is connected to a router. See the Does Vela work if my computer is connected to a router? question for details.

If Vela's system tray icon is not green, it means that the PNRP is not working properly. This could mean that either your computer doesn't have an IPv6 network connection, or that your computer's or router's firewall is blocking the PNRP network traffic. Normally, peers are (automatically) found on the network by using the PNRP. However, at least in some cases, the PNRP needs even tens of minutes to reach a state in which it can find peers over the Internet.

In Vela's "Application Configuration" window, in the "Advanced" tab, the value from the "Filler UPN classifiers count" edit-box should be at least 5. The higher the number is, the larger the peer network can get, that is, the higher the "Number of cache entries" and "Estimated cloud size" values (in the PNRP state) can get, but the CPU usage would also be higher; see the Manually check the PNRP state section for details.

If in the state of a letter you see an error which says "An attempt was made to access a socket in a way forbidden by it's access permissions", either your computer's or router's firewall is blocking Vela's outbound network traffic, or the firewall of the computer or of the router of the letter's recipient is blocking Vela's inbound network traffic.

If the system tray icon is green when Vela starts, but after a few minutes it becomes blue, the firewall is likely blocking the inbound network traffic; most likely, the problem is the router's IPv6 firewall. In this case, if you check the PNRP state (see the Manually check the PNRP state section for details), you can see that the "Number of cache entries" and "Estimated cloud size" values are decreasing over a few minutes, to very small values.

If the communication problems persist then restart the router, restart the computer, restart Vela.

If the problems persists, it's possible that your contact's firewall is blocking Vela's inbound network traffic.

If the PNRP just won't work, of if it's unacceptable for you to use it, you can set the alternative peer address for each account, with the remote peer's host name (use dynamic DNS) or IP address. For details, see the tooltip of the "Alternative peer address" text-box from the "Edit Account" window, and the How does Vela perform peer routability? question.

Also see the Can Vela be used on a network without IPv6 support? question for a way to avoid having to use IPv6. See the Why is IPv6 network support required if there are many people who don't have it? question for the reason why IPv6 is normally required.

Click the "View PNRP state" button from the "Application" tab.

Alternatively, you can do this from a command line window. While Vela is running, run "netsh p2p pnrp cloud show statistics Global_" (the underscore must be included).

If the PNRP is working, you'll see some details about it. There, if "State" is not "Active", "Use Server" is not "Used", "Cloud Operational Mode" is not "Full Participant", "Number of cache entries" is less than 40 or "Estimated cloud size" is less than 100, the PNRP will most likely be unable to resolve UPNs (to IP addresses).

From a command line window, run the "telnet {ip} {port}" command, where {ip} is the IP address of your contact's computer, and {port} if the port of his / her UPN. You should try with both the IPv6 and IPv4 IP address.

(You may need to enable support for "telnet". Start "Turn Windows features on or off". In the shown list, check the "Telnet Client" check-box and click "OK".)

If the connection succeeds, the command line window will be (nearly) blank.

If an error (like "Could not open connection") is displayed, the network infrastructure is causing the problems. Either a firewall is blocking the TCP traffic to the specified IP address and port, or the network has no / limited IPv6 support.

If you see this behavior regularly on a fast network, the most likely reason is Windows Defender scanning files in real-time. When Vela saves parts of the files it receives, Windows Defender scans them, but because its scanning performance is awful, it uses most of the processing power and therefore slows the download speed below 1 MB / s.

To fix this, open Windows Defender, go to its settings and enter in the "Exclusions" section. There, add an exclusion for the folder from the "Root save folder name" edit-box from Vela's "Application Configuration" window.

If that contact has a photo and you two can send letters to each other, then your contact has set an approval for your account which doesn't allow you to see his / her photo. Ask him / her to set the approval (for your account) with "Blue" of higher.

If you two can send letters to each other and that contact has sent you a wallpaper in a letter which has the ";Wallpaper" emoticon, then your approval for the account of that contact doesn't allow your (desktop) wallpaper to be changed. Set the approval (for the account of that contact) with "White".

When you change the photo in your vault, your new photo is sent only to your contacts who are linked to that vault and have the approval of their accounts set with at least "Blue".

For details, see the tooltip of the "Approval" combo-box from the "Edit Account" (or "Add Account with UPN") window.

If that were allowed, if you were to receive a letter while the letters (with the "Main" flag) were being deleted, the new letter might also be (accidentally) deleted.

While something similar also happens when you update the flags of all the letters, the new letter would still be in your storehouse, with the new flag, and the "New letter" notification would indicate that it exists.

All Vela's functions were designed to make it (technically) impossible for you to miss a new letter (notification).

This operation can't be sped up from Vela. If you move your storehouse on an SSD, this operation will be 2...3 times faster.

Another possible cause is that you have activated the "LogDebugMessages" setting from the configuration file.

The shown time is the scheduled one (for the next retry to send the letter), calculated for the recipient of each letter, not for each letter itself. The actual processing time can be later, depending on various factors, one of which is the number of requests which are queued for processing.

This mechanism ensures that all the letters meant for a certain recipient will be sent as soon as the recipient receives one letter.

This happens when you send attached media files using Vela version 1.0.3 or higher to someone whose Vela version is older than 1.0.3.

To solve this, ask your contact to update to the newest version of Vela. Alternatively, you can send the media files in an archive file.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

The Manually check the PNRP state section describes how to see the "Number of cache entries" and "Estimated cloud size" values.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

Go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

The following are the know issues:

• The underlying UI framework wastes a lot of working memory while handling images (especially animated ones).
• Sometimes, it may be difficult to connect to your contacts. If this happens, go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.
• In some cases, when sending files to an older version of Vela, you may get the error "No more retries to process the action request may be made", and "Invalid signature" on the recipient's side. This is because from version 2 onward the order of the attached files is guaranteed, whereas before it wasn't (which may have caused the same error in some case). If you get this error, you can send the files one at a time, or attach the files in alphabetical order, or upgrade (both you and the recipient) to the newest version of Vela.

This is not related to Vela in any way. Somebody who worked on Windows 8 thought that automatic system maintenance should be done at 3 AM. He / she thought that the best time to do this is when most people either have their computer... off, or are sleeping and can be awaken by the noise made by the fan of a computer running at 100%.

In the system search bar, type "maintenance". In "Security and Maintenance", in the "Maintenance" section, click "Change Maintenance Settings". Now you can change the time when you want the maintenance to be run.

The following rules are in adition to the default core networking rules from the Windows Firewall, the rules whose names start with "Core Networking".

Vela initially asks if you want to automatically create these rules.

If you are manually configuring your firewall, apply the rules below.

In the advanced configuration of the firewall, in all profiles, the state of the "Inbound connections" must NOT be "Block all connections". The reason for this is that "Block all connections" blocks all inbound connections, even if there are inbound rules which allow some applications to accept them, and only outbound connections may still be allowed.

Allow network access (for all profiles) for Vela (= "Vela.Im.exe"), for the TCP protocol, at least for the dynamic ports (those between [49152...65535]). This is for Vela's main network traffic.

Allow network access (for all profiles) for Vela (= "Vela.Im.exe"), for the outbound remote UDP port 1900, for the IP address 239.255.255.250. This is for the port forwarding feature. For port forwarding to work, it might be necessary for Vela's folder to be inside the computer's "Program Files" folder.

Allow network access (for all profiles) to the "Peer Name Resolution Protocol" service (= "PNRPsvc"), for the inbound local UDP port 3540 and the outbound remote UDP port 3540. This is for the PNRP.

You should allow edge traversal for the inbound rules.

If Vela can't communicate with your contacts, go through the checklist from the Is there a checklist to go through if Vela can't communicate with a contact? question.

By default, for communication, Vela uses a randomly created port which is stored in the storehouse and is contained in UPNs. This port is within the dynamic port range: [49152...65535].

If you use Vela in a place where a firewall blocks the dynamic ports, you can manually add a port which will be used instead of the random one.

To do this for all the storehouses which you will create in the future, go to the "Application" tab and click the "Edit configuration" button. In the window which opens, change the value of the "Processing port" text-box to the desired port (and click "Okay").

To do this for the currently opened storehouse, go to the "Storehouse" tab and click the "Edit configuration" button. In the window which opens, change the value of the "Processing port" text-box to the desired port (and click "Okay"). From this moment on, all the UPNs which you have already created in the storehouse, will be available on this port, as well as on the previous ones.

However, the people who already have one of these UPNs from you, will have to set the overriding remote port in order to use the new port that you have set for the storehouse. This can be done by editing the account which links them with you, and changing the value of the "Overriding remote port" text-box with the new port (and click "Okay"). This is only necessary for the people who were initially having problems sending you letters.

The default fixed port allocated to Vela is 8676, which is the concatenation of the decimal codes of the "VL" characters.

The simplest way to bypass a firewall is to use one (or all) of the following fixed ports: 80, 443, 8676. The ports 80 and 443 are usually used by web-servers, so if one is running on your computer, they can't be used by Vela. These ports are also not automatically forwarded because (at least) some routers don't allow it, so you have to forward them manually (in your router, but only if some of your contacts use IPv4 to communicate with you on these ports).

Why isn't the port 8676 added by default to storehouses? Because that would help censors to find out who is using Vela.

For details, see the tooltips of the mentioned text-boxes.

If your firewall blocks IPv6 traffic and you can't change that, see the Can Vela be used on a network without IPv6 support? question.

Vela uses two types of network structures: a peer-to-peer network used to handle peer resolution from UPNs, and a friend-to-friend network used for everything else.

Security (= authentication and encryption) is not part of any of these networks, but is handled through UPNs and digital identities.

A peer-to-peer network is used (only) to publish UPNs and resolve them to IP addresses.

Peers don't store any data in the name of other peers, as is the case for feature-rich peer-to-peer networks (like torrents).

By purpose, this is a public network and although it's anonymous, it's trackable, that is, UPNs can be associated by anyone to IP addresses.

This network has a limited type of centralization in the form of bootstrap servers, servers which are used to ensure that no islands of peers remain isolated from the whole network.

This network isn't necessary for Vela to work at full capacity, but it makes peer resolution an automatic process. Without it, the users would have to manually deal with IP addresses or domain names.

This network is handled by the PNRP Windows service.

A friend-to-friend network is used for everything other than peer resolution, like: messaging, file transfers.

This network uses only direct IP addresses for communication, that is, there are no intermediaries outside the fundamental infrastructure of the network.

This network is handled by Vela.

The defaults are:

• Rijndael 256.
• SHA 512.
• RSA 2048.
• Fortuna, for entropy.
• A memory effort and PBKDF2 (2^14 iterations), for password blending.

Weaker algorithms are not even included / implemented.

A UPN contains the following information:

• Algorithm name.
• Network port where action requests are received (by an action service) for processing.
• Body. This is a (part of the) hash of the following information: the seeds of the UPN properties (= fingerprint, long and short host labels, classifier, symmetric encryption key) and the public parameters of the cryptographic algorithms used for asymmetric encryption and signing, parameters which are contained by the vault identified by the UPN.
• Checksum.

When Alice creates an account with Bob's UPN, Alice first resolves Bob's UPN to an IP address with the help of the PNRP. Then, it sends an action request to Bob and receives an action response.

Since when the action request is sent, Alice doesn't know Bob's public identity, it can only encrypt the request with the symmetric encryption key of Bob's UPN.

When the response is received, Alice verifies that the UPN of the received identity is the same as the one used to create the account, and also that the response was signed with the received identity.

Because the request was symmetrically encrypted with the symmetric encryption key of Bob's UPN, an attacker who knows Bob's UPN can find out the symmetric encryption key of the response (and can therefore forge it).

However, since Alice verifies the UPN of the received identity, and since the UPN is generated from Bob's public information of the received identity, the attacker can't put in the response any public identity (since its UPN would be different), and so any man-in-the-middle attack is blocked. This is all done automatically by Vela once you give it an UPN.

The level of security of this mechanism is proportional with the length of the UPN body.

This mechanism guarantees that the security level of Vela doesn't depend (in any way) on the security of the network (including the security of the PNRP). The only thing that an attacker can do is replace Bob's response with a forged one which will be rejected by Alice (because the UPN will not match).

A vault generated with the normal / default security level produces a UPN body with a length of 128 bits, one generated with the "stronger" security level produces a length of 256 bits, and one generated with the "strongest" security level produces a length of 512 bits (but the symmetric encryption algorithm only provides 256 bits of security).

The information that Vela sends among peers is encrypted in an envelope which exposes various locators and MACs; this is done for performance and management reasons.

To send the information through a network, Vela then steganographically secures the encrypted envelope; more clearly, it reencrypts it with the UPN symmetric encryption key of the recipient peer.

This is done in order to make the network traffic look entirely random so that an attacker can't deduce which application is creating the protected information, just as it happens when the information is steganographically hidden.

The security of the steganographic process depends on the privacy of your UPN (and on the privacy of the UPNs of your contacts). If your UPN (or the UPNs of your contacts) is known to "them", "they" know (that you are using Vela).

Vela's network traffic is formed by normal TCP traffic where the payload is made of 4 bytes representing the size of the data, followed by the (random-looking) data itself (of a random-looking size).

The service communication port is randomly created when a storehouse is created, and is contained in UPNs.

The client communication port is randomly created for each action request, that is, there is no session (in Vela) for multiple action requests. Even file transfer is realized during a single action request. However, note that a TCP session is still created by the underlying infrastructure for each action request.

Yes, to some extent. There are two layers which protect the actual size.

The size of any encrypted document (like the container of an action request) is aligned to (multiple of) 1024 bytes; the final size will also include 1 extra padding block due to the used symmetric encryption algorithm.

This means, for example, that a letter which contains a message whose size is up to the alignment size will not reveal its actual size, whether it's sent from Vela over the network, or it's exported in a file.

Also, the size of the steganographically secured information which is actually transferred over the network is disaligned, that is, a block of a random number (up to 1024) of random bytes is added to each transferred block of bytes.

For the files attached to a letter, the transferred files appear as a single file to someone who is monitoring your network traffic. Also, the size of each sent block of data is randomized within [50'000...200'000] bytes.

For example, if you send a file which contains a single character, the spy will see a single block of random bytes (with a size within the specified range).

Block timing analysis might be able to reveal the number of files and their approximate sizes, due to the time required to actually read the file data from the harddrive, but this would be a massive effort with no clear benefit.

No. Once a vault is compromised, anything encrypted and signed with it (in the past) is compromised as well.

Some online services now advertise that they use "(perfect) forward secrecy". In their case this is useful because a user's message goes through their servers in order to reach its intended recipient. Still, keep in mind that the user doesn't control the code which implements this feature, so it remains just a vague promise that a user is not specifically targeted.

However, in Vela's case, a user's message goes directly to the intended recipient. Even more, Vela has no centralized authentication service, is open source and can be run entirely from the user's computer. Hence, the two cases have fundamentally different trust requirements.

The lack of backward secrecy means that Vela:

• Can store letters.
• Guarantees that in case Vela or your computer crashes when you are not at your computer, you will see after a restart if you have received letters while you were away; you will not have to wonder if you have lost your contacts' letters. Also, your contacts know exactly when you actually receive the letters, due to the digitally signed receipt confirmations.
• Can retry to send the letters which were not sent, even after a restart.
• Can resume file transfers, even after a restart.
• Can be sessionless, which in turn means that Vela works offline as well as online, that is, for example, letters can be transferred offline peer-to-peer (that is, even when their computers are not connected to the Internet).

The advantages of backward secrecy are also debatable.

Some people like to point out that if Alice's vault is stolen by an attacker, the attacker can see all her past messages. Firstly, this is incorrect. If an attacker gets a hold of Alice's vault, the attacker can only see the messages received, not sent, by Alice. To see the messages sent by Alice, the attacker needs the vaults of the recipients of Alice's messages. This is how asymmetric cryptography works.

Secondly, if an attacker can steal Alice's vault, what exactly stops the attacker to steal everything else from Alice's computer, including everything that she types? Nothing. In practice, Alice is fully exposed. If people can be hurt because of the messages that they have sent in the past, they can also be hurt by all the (other) information from their computers.

An argument in support of backward secrecy is that even if a provider of encrypted communication (which Vela isn't, it works peer-to-peer) is forced by an attacker to allow access to a user's future messages (by altering the client application), the user's past messages would remain unknown.

But what exactly is supposed to make the future messages less damaging (to the user's life) than the past messages? In practice, the attackers would monitor the user's communication for a long time, until the user's messages are damaging enough.

There is also a legal argument to be made. Some people like that backward secrecy provides plausible deniability, but there is something else that is plausible: proof.

In order to convict someone, a legal system doesn't require irrefutable / cryptographic proof (= proof beyond a shadow of a doubt), but proof beyond reasonable doubt. And this is only for criminal cases. For civil ones, the strictness may drop considerably to "balance of probabilities".

Hence, if the messages of Alice are found on Bob's computer, it doesn't matter if Bob could theoretically forge Alice's messages. It's most likely that Bob is the average computer user who couldn't forge the messages even if his life depended on it.

If backward secrecy were available and Alice were to defend herself by claiming that Bob has forged her messages, the judge would assimilate that claim to the claim that physical evidence has been forged (like planted papers or fingerprints), and would throw out the argument.

No. Once a vault is compromised, anything encrypted and signed with it (in the future) is compromised as well.

Clarity of language brings clarity of thought, so let's clarify the language in order to clarify this issue.

In order to be able to speak about backward or forward in time, a time reference is needed.

The moment when the (root) encryption key is created, or the actual moment when the encryption is performed can't be used as time reference because all encryption algorithms have to be secure both in the past and in the future of these moments, but not all algorithms are secure in the past or in the future of the moment when the (root) encryption key is compromised.

This leaves only the moment when the (root) encryption key is compromised to be used as time reference. Applying the dictionary definition of "forward" onto this time reference, "forward secrecy" means that the messages which are encrypted with the (root) encryption key are still secure even after the moment when the (root) encryption key is compromised.

Conversely, "backward secrecy" means that the messages which were encrypted before the moment when the (root) encryption key is compromised, are still secure at the moment when the key is compromised.

If you are still in doubt, read "Forward vs. backward" in the RFC 2828. Also read "Forward versus backward" in Ross Anderson's "Two Remarks on Public Key Cryptology" (Ross Anderson, 2002).

Alice = Our beloved neighbor who communicates with Bob, her business partner.

Bob = Alice's business partner. We don't like him much, but hey, Alice is an independent woman...

Tom = The tomcat, the thief in this story.

Programmer = The lazy programmer who developed Vela. He's of no importance in this story, but he's the nosy type, so he's in.

Asymmetric encryption is useful when Alice and Bob need to exchange documents which are authentic and private.

"Authentic" means that Bob must somehow be sure that Alice is the one sending documents to him, and that Alice must somehow be sure that Bob is the one sending documents to her. Authenticating a digital document is similar to signing a paper document.

"Private" means that the documents exchanged by Alice and Bob can't be read by someone else. This means that the documents must be placed in an envelope in which Tom can't look. To make a digital document private is similar to putting a paper document in a paper envelope.

In order to fulfill the needs for the exchange of documents, a mathematical process called "asymmetric encryption" is used. Both Alice and Bob have an "asymmetric key pair", that is, two keys, one private and one public, with which they must garble their documents before they are sent to the other and restore them after they are received from the other.

An asymmetric key pair has a special mathematical property which allows someone to garble a document with one key and restore it only with the other key.

Before Alice and Bob can exchange documents, they must each generate a key pair. They have to keep the private key for themselves and send the public key to the other.

When Alice wants to send a document to Bob, she processes the document with her private key in order to authenticate it, then she garbles the document with Bob's public key in order to make readable only by Bob.

Since the document was garbled with Bob's public key and since asymmetric encryption allows a document to be restored only with the other key, Alice is certain that only Bob can restore the document with his private key.

When Bob receives the document, he restores it with his private key and obtains the document which was authenticated with Alice's private key.

Since the document was processed with Alice's private key and since asymmetric encryption allows a document to be restored only with the other key, Bob is certain that only Alice could have processed the document with her private key.

At this point, Bob is certain that the document was sent to him by Alice and that only the two of them saw the document.

Vela is built, hashed and attested on a computer which is used only for this purpose. The source code is manually synchronized there with the code from the development computers.

If that were true, the NSA would not need to go to all the trouble (that was revealed) that they go through to get the information that they want.

Note that the cryptographic algorithms used by Vela are not those from Windows, but are open source.

Encrypt your entire storage memory with a full drive encryption (= FDE) application, like VeraCrypt and CipherShed, both based on TrueCrypt.

With the same application, create encrypted containers for the information that you can (and should) back up frequently. Use these containers for your regular work, but don't install programs on them. Back up the containers outside your computer, for example on memory sticks or external harddrives.

Create a password as shown in the How can I have a strong password? question. Use this password for (offline) logging into the operating system, and for the full drive encryption application. Do not use this password anywhere else.

Deactivate the paging file of the operating system. Do this only if your computer has at least 8 GB of working memory (/ RAM).

Deactivate the hibernation mode of the operating system.

Set the "User Access Control" (/ UAC) to maximum.

Disable the "Connected User Experiences and Telemetry" / "DiagTrack" Windows service.

From Vela's installation folder, run the "Scripts\WinCustomization.reg" script in order to disable various Windows features which leak information outside your computer. The script was written only for the newest version of Windows. View the file and read the description of each item in order to see if you want to do that.

Cover the (notebook) videocamera with adhesive tape.

Disable the microphones and speakers of the computer, in the properties of the operating system. If you want to tape a microphone, you have to first cover the microphone with something soft and thick (which absorbs the sound). If you tape the microphone, also tape the speakers because they can be used as microphones.

Disable "Wake on LAN" from your computer's BIOS.

Always treat the intranet / LAN as any other insecure network, that is, as the Internet.

Treat networking equipment (like routers) and devices with GSM capabilities (like phones) as if they are compromised.

You might want to use Vela in offline mode. See the How can I use Vela only offline? question for details. If you want to use it in online mode but want to avoid the slightest chance of being tracked through the PNRP and UPNs, uncheck the "Use UPN resolvers" check-box from the "Application Configuration" window. In this case you will have to use the alternative peer address.

If you want to use a security oriented Linux distro, use Qubes.

If you want to use a security oriented notebook and smartphone, use Purism. These come with Intel Management Engine disabled.

The network traffic has to be blocked in its entirety, by default. Then, firewall rules must allow network traffic only to / from specific programs (like an Internet browser).

Windows comes with a firewall which is enabled by default. Open the "Windows Firewall with Advanced Security". To do this, type "firewall" in the Windows search bar and select the full name from there.

Open the properties of the top node (= "Windows Firewall with Advanced Security on Local Computer").

In the "Domain Profile", "Private Profile" and "Public Profile" tabs, in the "Inbound connections" combo-box select "Block (default)", while in the "Outbound connections" combo-box select "Block". Click "OK" to save the new configuration.

Now, you can delete all the existing inbound and outbound rules, except the ones whose names start with "Core Networking". However, be very careful what rules you delete because you may have some programs which may need some of those rules. You can later add rules for those programs, if you know what the programs need. You can restore the rules to the default state by using the context menu of the top node, but the program rules will not be restored.

Run the firewall configuration utility from Vela's "Application" tab. If you need to know low-level details about the firewall configuration, see the How should the firewall be configured in order to be able to use Vela? question.

Vela's firewall configuration utility creates the firewall rules described below, but they are disabled by default. So, instead of manually creating the rules described below, you can enable the ones created by Vela.

You should now create a custom outbound rule which allows your computer to keep Windows updated. Such a rule doesn't come with the firewall by default.

Select the "Outbound Rules" node / list and create a new rule (from the context menu). A window will open.

Select "Custom" and click "Next".

In the "This program path" edit-box paste "%SystemRoot%\System32\svchost.exe" (without the quotes).

Requiring a rule for "svchost.exe" is a bizarre and insecure choice of Microsoft.

Click the "Next" button.

Windows will warn you about a conflict with service hardening because it sees that you give network access to "svchost", but by default this has access anyway (because all programs have outbound access).

In the "Protocol type" combo-box choose "TCP", and in the "Remote port" combo-box choose "Specific ports" and type "80,443" in the edit-box below it.

You now have a firewall custom rule for the "svchost" services container.

Click "Next" until the end, but make sure to select the "Allow the connection" radio-box.

You can do the same for the "Windows Time" service, which updates the computer's time from the Internet, but instead of adding the "svchost" file path to the rule, in the "Services" section click the "Settings" button and select the "Apply to this service" radio-box and then select the "Windows Time" service from the list. The used port is UDP 123.

Note that even with a firewall lockdown, an application can still indirectly send information outside your computer. This can, for example, be done by an application which creates a local webpage and opens it in a browser, webpage which makes a request to a website.

You should periodically check if there is any new firewall rule, because Windows updates break user mandated security by adding firewall rules and enabling those that are disabled, in particular for apps (not for desktop applications). The easiest way to deal with this is to install a proper firewall. Alternatively, you can create one inbound and one outbound rule which blocks the traffic of all the application packages (select "Apply to application packages only"); for the rest of the unwanted rules, create a new rule for each unwanted rule, for the same application file, and select "Block the connection".

If you want to hide some digital information from attackers, here are a few steps that you can take.

It would be best to use a live operating system, that is, an operating system which runs from a DVD.

Encrypt your computer's entire internal entire storage memory with a full drive encryption (= FDE) application, like like VeraCrypt and CipherShed, both based on TrueCrypt.

Get a number of external drives; these can be thumbdrives.

Encrypt the external drives in their entirety, using random passwords; for VeraCrypt and CipherShed it's easiest done at partition level. For some of these drives, use passwords that you remember, and copy on them the sensitive information that you have on your computer's internal storage memory.

The external drives now appear unused (and not formatted), with their previous content wiped for security / privacy reasons. You can say, to anyone asking, that you have wiped these external drives with a full drive encryption application, using a random password.

The password was random so that you wouldn't be able to remember it, so that the information can't be retrieved and remain "wiped". With a password that you can remember, the information would not be wiped but merely encrypted.

Note that the performance of an external drive is limited when compared with that of an internal drive.

Vela is an enterprise level framework designed for reliability, efficiency, scalability, flexibility of the stored data, independence from the storage engine.

Vela is designed to withstand several decades of future technological changes. Even if quantum computers become a reality, Vela can be effortlessly extended with an asymmetric encryption algorithm that can provide security in a quantum era.

All these have acceptable trade-offs: performance and memory usage.

The payment service test application, for example, could scale linearly because there is no write lock on shared documents and it can process in parallel a number of transactions equal with the number of processors.

However, the application can't provide a true representation of this linear scalability because only two accounts are being used, whereas in a real environment, payments are made from an account to any other out of any number of accounts.

No. The Vela framework could work on Mono, but some of Vela's modules don't. Mono is the non-Windows port of .Net (= Vela's interface with the operating system).

If you want to use Vela on non-Windows operating systems, you have to convince the Mono developers to add support for WPF (and perhaps for the PNRP as well).

Vela uses only a small part of WPF and PNRP, so these don't have to be fully supported.

Also, someone has to port the MS SQL Server scripts to SQLite (or something similar).

Yes. You can modify Vela, or you can build your own application from scratch (on other platforms).

So long as you use the Vela protocol, your application will be able to talk to any other application which uses the same protocol, while maintaining the same level of security.

To make changes and to build Vela, you should use a development environment like: VisualStudio, SharpDevelop, XamarinStudio (has issues recognizing some of Vela's UI projects).

Vela uses Microsoft's SQL Server CE (= Compact Edition) database. This is distributed with the source code, but you may want to use a different version of it.

See the How can I use the emoticons from Vela in my own work? question for a way to get the emoticons. Alternatively, you can use your own images or a generic placeholder.

You will not be able to immediately make a build because the emoticon images are not included in the source code, due to licensing terms. To be able to make the build, copy the "Vela\Dependencies\Emoticon placeholders\Dependencies" folder (with its entire content) outside the "Vela" folder; this contains a generic emoticon for each required emoticon image file.

You can also use any images that you want, but the height of those from the "FullSized" folder has to be 192 pixels, while the height of those from the "ThumbSized" folder has to be 64 pixels.

This section refers to the source code distributed separately from Vela, because it's the most up to date, meaning that it may include small changes compared to the source code which is included in the official build.

First, you have to install the Microsoft Build Tools (MS Build).

If you want to be able to build the firewall configuration utility, you have to install the Windows SDK (or VisualStudio), and must change the path from the "TlbImp.exe" command line from the pre-build event of the "Vela.ConfigureFirewall.csproj" file, with the path from the SDK.

To build, use this command line:

"[MsBuild folder]\MSBuild.exe" "[Vela root source code folder]\Vela\Code\Guis\Vela.Im\Vela.Im.sln" /property:Configuration=Release /property:Deterministic=True /t:rebuild /consoleloggerparameters:ErrorsOnly;WarningsOnly

Common folders for MsBuild:

• C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\
• C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\
• C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\
• C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\amd64\
• C:\Program Files (x86)\MSBuild\14.0\Bin\

To manually build "NetFwTypeLib.dll", for the firewall utility, use the command line: "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\TlbImp.exe" "%SystemRoot%\System32\FirewallAPI.dll"

By design, the C# compiler produces different binary outputs. Normally, the differences should be very small, and located at the beginning and at end of the output files.

For details, read this and this.

Microsoft has finally introduced, in the Roslyn compiler, an option for deterministic output. This option can be used by adding "/property:Deterministic=True" to the build command line. Only Vela versions starting with 2.0.1 are compiled with this option. However, fully reproducible builds require building on the same environment.

No.

The debug version exposes (= stores in a clear text form) secret information. This is meant to be used strictly for debugging.

"Vela.Im" shows a permanent warning message if it was compiled in debug mode.

There are two main applications that you can debug: the tester ("Vela.Tester") and the messenger ("Vela.Im").

First, see the I want to build Vela myself from the source code. Is there anything special that I should know? question for what development tool to use.

If you use VisualStudio (Express should work, but doesn't save executable files), you will not have to separately install the Windows SDK. When you install VisualStudio, choose the C# development profile. This lets you use the F5 key to run an application with the debugger attached, and the F9 key to set a breakpoint.

For the tester application, open the "Vela\Code\Guis\Vela.Tester\Vela.Tester.sln" file in the development tool. The application entry point is the "Main" method (from the "App" class) from the "App.xaml.cs" file from the "Vela.Tester" project. The main window is in the "MainWindow.xaml.cs" file.

Note that the dynamic nature (= code reflection) of .Net is used in key points, so you would have difficulties in directly debugging the code flow. However, all the performed test are located in the "Tests" folder from the "Vela.TesterBackend" project, so it's recommend to put breakpoints in each of those files.

For the Vela application, open the "Vela\Code\Guis\Vela.Im\Vela.Im.sln" file in the development tool. The application entry point is the "Main" method (from the "App" class) from the "App.xaml.cs" file from the "Vela.Im" project. The main window is in the "Windows\MainWindow.xaml.cs" file.

If you want to see how an action request is effectively sent, put a breakpoint in the "ResolveUpnAndProcessRequest" method (from the "ActionClientChannel" class) from the "ActionClientChannel.cs" file from the "Vela.ActionClient" project. Note that this method may be called from a (10 seconds) timer, in a background thread; you can see this in the "ProcessingThreadHandler" method from the "ActionClientManager" class.

If you want to see how an action request is effectively received, put a breakpoint in the "ProcessRequest" method (from the "ActionServiceListenerWorker" class) from the "ActionServiceListenerWorker.cs" file from the "Vela.ActionService" project.

To see and change the default used algorithms, see the "AlgorithmPool.cs" file from the "Vela.ApplicationBackend" project.

Each instance should be compiled with a different value of the "Vela.ImBackend.ImBuildInfo.ProductFullNameDef" constant. This makes it possible to use different configuration files.

Each instance must be compiled with a different GUID value of the "Vela.Im" project (in order to be able to start multiple application instances). This can be changed in the "Vela\Code\Guis\Vela.Im\Vela.Im\Properties\AssemblyInfo.cs" file.

The Vela documents may be in binary or XML format.

Here is an example of a vault. This contains the unencrypted data so that you can see what is actually stored. This can be obtained by declaring the "SERIALIZEEXPOSEDATTRIBUTE" conditional compilation symbol and running "Vela.Tester" in debug mode.

Yes, but you have to perform some manual steps. You should do this only if you have enterprise level requirements.

You need at least MS SQL Server 2012.

Start and close Vela.

Edit Vela's configuration file. The path of this file is "[AppData]\Vela.Im", where "[AppData]" is the application data folder path of the user who is currently logged on. An example of this path is "C:\Users\JohnDoe\AppData\Roaming\Vela.Im".

In this file:

• Set the value of the "StorehouseProviderTypeName" setting with "Vela.MsSqlFeDatabase.MsSqlFeDatabaseProvider".
• Set the value of the "ConnectionStringTemplate" setting with "Server=(local); Database={ServerStorehouseName}; Persist security info=False; User Id={ServerStorehouseName}; Password={StorehouseAttachmentsPassword}; Enlist=False;".

From now on, Vela will create and open your storehouses using SQL Server FE.

Vela will not overwrite existing (SQL Server FE) databases, so make sure that you choose unique names every time you create a new storehouse.

MS SQL Server must have the right to read from and write to the folder where the storehouse is located.

If you have just installed the MS SQL Server and you get an error saying "Login failed for user", most likely you have to enable the mixed authentication (SQL Server and Windows Authentication) in the server instance properties. You also have to enable the "TCP/IP" protocol from the server configuration manager, for the used server instance.

The most important reason is that an SQL database isn't designed to work with object-oriented programming patterns, fact which makes the developement of a consumer application very difficult.

The Vela Framework makes heavy use of object-oriented documents. For example, there are several levels of inheritance in action requests. With a normal SQL developement pattern, complex joins would be needed, and a small change would require the alteration of the structure of the database, but with Vela's developement pattern, alterations of the structure are not necessary even if large changes in document inheritance are made.

Another reason is that when Vela was started, there was no Entity Framework, so developement would have been even more difficult.

But the critical (technical) reason for the performance issue is that there are no dedicated SQL scripts to perform the involved operations, like when, for example, deleting letters.

Whenever a sheaf is added to or updated in the storehouse, it's also reloaded to check that it can be deserialized.

To improve the storehouse performance, comment the content of the "VerifyReloadSheaf" method (from the "DatabaseTransaction" class) from the "DatabaseTransaction.cs" file from the "Vela.DatabaseStorehouse" project.

A storehouse is made a of header file (which is managed by Vela), and at least one other file (which is managed by the underlying storehouse provider, like a database server engine) attached to the header.

The storehouse header is symmetrically encrypted with the user typed password. The files attached to the header are symmetrically encrypted with a random key which is stored in the header.

The documents which are stored in the storehouse are symmetrically encrypted with the document-specific key derived from the random root key which is stored in the header.

Some information related to the stored documents is stored outside the documents, in the attached files, and is encrypted by the underlying storehouse provider. This information is used to quickly perform certain operations. This information is called "storehouse search filters".

The storehouse search filters include information like: class type names, (randomly generated) locators, creation and update times, states of objects (like letter state), entity names, up to 500 characters from the beginning of letters.

Yes.

Vela doesn't use HTTP, HTTPS or public key infrastructure (= PKI and X509 certificates).

Vela accesses network sockets directly.

The data sent by Vela on the network is already encrypted, so it literally looks gibberish outside Vela.

No. The extra security that this feature would achieve is marginal, yet doing so would obliterate the current advantages due to the tremendous added complexity to the source code.

Besides, if an attacker has a malicious application on a user's computer, capable of reading your computer's working memory, he / she is first going read what the user types (passwords, messages, documents).

The few users who need this extra security, must instead physically secure their computers, fact which would automatically make this feature irrelevant. See the Can you provide some system security tips? question.

A computer contains all kinds of sensitive information, and that information isn't wiped from the working memory by the operating system (specifically, in the windows where the user writes text), by the text-editor that the user uses to write documents, or by other applications which access the user's files.

Rather than asking every software developer to implement highly expensive (in terms of time and money) security features (which are also unlikely to be complete), you should ask the developers of the operating system to provide a secure mode (for the entire operating system) which, when activated, would not store the working memory in the storage memory, would forbid running applications to peek in the memory of other running applications, would forbid running applications to intercept keystrokes, would wipe the released working memory (or would periodically wipe the unallocated working memory), would perhaps encrypt the heap memory, and so on.

No. There are no plans to develop one in the foreseeable future.

You should start with the entropy generator (called "Mash", see the "Mash.cs" file). This is an implementation of Fortuna.

Another custom implementation is the asymmetric padding (called "Vsh", see the "Vsh.cs" file). This is OAEP with binary encoding (not ASN1), with included algorithm names (instead of numeric identifiers), and an extra hash. The implementation is custom because more information had to be included.

Account = An account contains information which uniquely associates a peer's vault with another peer's presenter (and implicitly with that peer's vault).

Contact = A remote peer for whom you have an account in your Vela, and who has an account linked to you in his / her Vela.

Private digital identity = A private digital identity contains information which a peer can use to decrypt documents that someone has encrypted for that peer (with the peer's public digital identity), or to digitally sign documents whose signature can be verified by someone (with the peer's public digital identity).

Private key = A component of a private identity

Public digital identity = A public digital identity contains information which someone can use to encrypt documents that only the peer who owns the identity can decrypt (with the associated private digital identity), or to verify documents which were digitally signed by the peer (with the associated private digital identity).

Public key = A component of a public identity

Intimate information = The intimate information is made from the: virtual identity, physical address. The virtual identity contains, for example: email address, phone number, website URL, birth date, intimate note, gender, sentimental relationship.

Letter = A letter is a textual message sent from one peer to another.

Local = Local is something which is on the local / your computer.

Peer = A peer is a person, or a person's Vela / computer. A peer is an entity which may publish various services and may access the services published by other peers. A peer may register itself to a network in order to interact with other peers.

PNRP = "Peer Name Resolution Protocol" (PNRP) is used to resolve UPNs to IP addresses. This is a Windows service and accesses Microsoft's bootstrap servers.

Presenter = A presenter contains public information about a peer, like the peer's public digital identity (from which the peer's UPN can be generated).

Remote = Remote is something which is on a remote computer, someone else's.

Storehouse = A storehouse is a set of files which contain various information, like vaults, tallies, accounts, letters. See the Where is all the information stored? question for details.

Tally = A tally contains information which uniquely represents a remote peer on the local / your computer.

UPN = A "Universal Peer Name" (UPN) is a random-looking text which provides name resolution, encryption and authentication between peers. Two people can communicate securely if they exchange their UPNs.

Vault = A vault contains private information which uniquely represents a peer. A vault contains a private digital identity (from which the peer's UPN can be generated).

Your computer = Your computer is the computer where your UPN is registered on the network, the computer where you use your Vela.

Registered UPN = A registered UPN is a UPN whose classifier is registered on the network. The UPN itself (including its other properties) is not exposed on the network.