Vela is a set of open
source applications developed in C#, which work on any system
with DotNet (at least version 4.0).
Vela doesn't work on Mono
because this doesn't support WPF.
Vela is designed to handle
the work required to implement an action processing service
compatible with Vela. Of course, service providers still need to
develop the code which processes Vela documents inside their
system, but that is all they need to do.
Vela works only with the
little-endian data format.
The Vela libraries can be
The source code is open
source and heavily documented, but given the nature of applied
cryptography, you should try to understand the inner workings
only if you have significant cryptographic experience.
For examples, see the
source code of "Vela.Tester",
from which you can understand the core functionality.
The serializer and
deserializer are custom made, using reflection. This guarantees
the same serialization output, regardless of the platform it runs
on, which is critical for signatures.
The generated pseudo-random
numbers pass the DieHard
batteries of tests. Use the "Work \ Generate entropy file"
menu, from "Vela.Tester",
to generate a test file.
Protection against attacks
signed and encrypted documents is a very slow operation. This
fact exposes an Vela service provider to potential attacks where
someone would try to suffocate the service with many requests for
Using an automated process,
an attacker could succeed to effectively shut down the service
provider's ability to process the documents of legitimate users.
A network traffic filter
integrated in Vela mitigates such an attack.
The following features
are part of the framework but are not exposed by "Vela.Im".
Organizations may get
significant benefits from using group identities. A group
identity simply groups the identities of several people who work
for the same organization.
A group identity allows a service provider to require that in
order to execute an action in a service account, all the members
of the organization (or a minimum number of members) must sign
the request for the execution of the action.
For example, an organization might have an account with a
payment service where it keeps (some of) its money. The
organization would not want any single member to have full access
to this account, but rather request that the payment service
executes only payments which are signed by 3 (out of 5) members
of the organization. Vela can make this happen.
A group identity also allows a user of Vela to encrypt a
document for the organization. It is possible to encrypt the
document so that each member of the organization could decrypt
the document independently, or it's possible to require (with
cryptographic strength) that all members of the group be present
in order to decrypt the document.
Even further, it's possible to encrypt a document in a way
which requires that most members of the group be present in order
to decrypt the document, but some members could miss. Moreover,
it doesn't matter who is present and who misses from the
decryption process. All that matters is that the minimum number
of members is met.
For example, if the board
of directories of the organization has 5 people, but only 3 of
them are required to decrypt documents sent to the organization,
the Vela framework can make this happen.
is a complete log of the tester application, "Vela.Tester".
All tests have been
performed with the GUI edition of the "Vela.Tester"
on a computer with a 1.73 GHz Intel Mobile Core i7 processor,
with the storehouse on a software encrypted SSD, on Windows 8 64
MB = megabyte.
s = seconds.
ms = milliseconds.
The payment service
endurance test, with one tester application instance, has
achieved 0.29 seconds per operation after 6'500 operations.
This test includes local
round-trip processing (= client and service), with local network
communication; the data is encrypted and signed in all relevant
Testing the service
test the payment service which is part of Vela. This service was
designed to be as scalable as the underlying storehouse engine.
operations required in a payment application, both client and
service sides, are being performed.
payment service test is a very harsh one when multiple instances
of the tester are used.
instances compete for the same service resources (= same two
accounts). Since, also, the client and the service both take
processing time from the computer, this test is significantly
slower than a real-life payment service application.
run too many instances, there will be storehouse timeouts. You
should not run more instances than the number of (physical) cores
that your processor has.
what you have to do in order to test the service:
the tester, "Vela.Tester".
the "Do all test" menu.
until all tests have been performed.
the service, "Vela.PaymentServiceOps".
the "Open service vault" button. The service loads the
peer vault generated by the tester and starts.
the tester, double-click the "Service endurance" test.
This will start an infinite test of the service, simulating the
interaction between a user and the service.
want the service to perform a lot of operations, you have to
increase the "FirewallKnownPeerProcessableSizeMax"
value from the service's configuration file. The default value is
sufficient for a few thousands of operations.
tester (and Vela itself) will show deadlocks from time to time,
but it's the kind of deadlock which occurs when two transactions
try to convert an intent exclusive lock to a full exclusive lock
for the same resource, or convert a row lock to a page / table
lock, that is, it's a consequence of the design of the locking
deadlocks are different than the deadlocks which may occur
between two threads where the locking system is far simpler.
Service Compact Edition reports only timeouts, but SQL Service
Full Edition reports deadlocks.
order to see what is happening, create a log file by changing the
configuration file of the service as follows:
logging mechanism uses a global mutex for thread-safety, and all
trace messages are synchronously written in the log file, so
there can be no missing trace message.
(has issues recognizing some Vela projects).