David's blog

To content | To menu | To search

Wednesday, July 21 2010

A small idea to securely store votes in a voting machine

By d. on Wednesday, July 21 2010, 13:00 - Vote électronique / demexp

I recently reviewed the French requirements for (electronic) voting machines. Amongst the 114 requirements, two of them seem a bit difficult to satisfy simultaneously:

Requirement 65: If a voting machine should be stoped during a vote, no indication of the choice made by the voter should be visible.

and

Requirement 69: If a voting machine should be stoped during a vote, it should be possible to recover vote information by vote pool members without any modification, while still following requirement 65.

Thus those two requirements simultaneously request that votes should be recovered in case of crashes but at the same time it should not be possible to read them!

In the following I propose a design to fulfil those two requirements. The main idea of this design is to have two separate kind of machines:

  1. the voting machines themselves, used in the voting booth,
  2. and a centralised controller, used to initialise voting machines, read final votes and when needed re-initialise a voting machine.

Moreover, within voting machines, the recorded votes are stored in a writeable and removable media (like a Flash memory) but they are encrypted. The encryption material should be kept in volatile memory, i.e. in RAM, so that in case of power failure it is lost, making impossible to read the recorded votes on the writeable media. When the voting machine (or a new voting machine) is restarted after a failure, the encryption material is reloaded from the centralised controller, allowing to store new votes next to the previous ones. At the end of the voting period, the votes are read and tallied by the central controller, which has access to the encryption material.

More specifically, here is how a typical vote would be done:

  1. The centralised controller is started and it generates the encryption/decryption material for each voting machine;
  2. Each voting machine is connected to the centralised controller and receives the encryption/decryption material, that is stored in RAM;
  3. The voting machines are then put in their voting booth and set into voting mode (i.e. they accept and store votes);
  4. After also being put in voting mode, the centralised controller can no longer generate new encryption/decryption material;
  5. When each vote on a voting machine is made, it is encrypted and stored on the flash memory of the machine;
  6. If a voting machine crashes, it is connected to the centralised controller and the encryption/decryption material is reloaded, so the voting machine can continue to store votes after the previous one;
  7. At the end of the voting period, all the Flash memories of voting machines are removed and put into the centralised controller. The centralised controller decrypts the votes (it has the encryption/decryption material) and tallies the votes.

As encryption procedure, one could use a One Time Pad but, as there are in practice difficult to generate correctly, we could use instead a stream cipher to generate a "random" stream that would be XORed with the information to store, like AES in counter mode. In the latter case, only the encryption/decryption key would be transferred from the centralised controller to the voting machine and stored in RAM.

The requirement 69 also mandates that vote information should be recovered without any modification. This could be easily done by adding a cryptographic signature on the whole set of recorded votes on the removable media, using as signing key the same material as encryption/decryption material.

The main advantage of this design is its simplicity. If a One Time Pad is used in a voting machines, there is no need to use complex cryptographic code in the voting machines. A simple XOR operation can be used. And even if an AES block is used, it is relatively simple to use. The complex generation of random numbers needed for the generation of encryption/decryption material is only done in the centralised controller.

Another advantage is that votes stored on the removable media can be re-read in case a re-counting is needed, provided that the encryption/decryption material of the centralised controller is securely stored somewhere at the end of the voting period.

One weak point of this approach is during the transfer of the encryption/decryption material from the centralised controller to the voting machines, where the encryption/decryption material could be intercepted by an attacker. A solution would be to authorise this transfer only after proper authentication of a voting authority, limiting the ability to intercept it.

What do you think of this design? Do you see any major weak point or security defect?

no comment no trackback

Friday, July 16 2010

A modification proposal to Frédéric Connes' voting protocol

By d. on Friday, July 16 2010, 13:00 - Vote électronique / demexp

A recently presented the very interesting electronic voting protocol of Frédéric Connes. This protocol has some issues, most notably that is does not work for the first voter and an attack is possible, knowing the paper receipt of previous voters. https://bentobako.org/david/blog/admin/post.php?id=75&upd=1# I would like to present a modification proposal on Connes' protocol. The main idea of this proposal is to let memorize by the voting machine a pool of random numbers, use them for the first voter so that they will be correctly associated to the choice of future voters. That way, the main property of the protocol is kept, even for the first voter:

  • All vote choices on a receipt are associated to a valid vote;
  • All votes are available on the web site and can be checked.

Moreover, one should notice that if this approach is applied not only for the first voter but for latter voters, this approach could be a counter-measure against the attack that try to guess votes, knowing the paper receipt of voters.

Of course, this proposal is just an idea and a detailed analysis would be necessary to see if it really brings additional security. The probably most difficult point is that the initial pool should be empty at the end of the vote, i.e. all random numbers printed on a paper receipt should be used as a choice by other voters. Otherwise it might be possible to guess some votes. And pre-generating and storing some random numbers add some security issues that must taken into account.

Proposal details

Here is an hopefully more detailed presentation of the proposal. We assume an election amongst three people, A, B and C.

During the vote initialisation phase, three series of 10 random numbers are generated, IA1..IA10, IB1..IB10, IC1..IC10. Each one of these random number is associated to a state. Three states are possible:

  • Unused;
  • Assigned-to-vote-choice;
  • Assigned-to-other-choice.

Initially, all random numbers have state Unused.

When a new voter votes, supposing that he/her wants to vote for option A:

  • For option A, a number is chosen:
    • Either a new random number (which is stored to be reused by further voters);
    • Or either a previously generated number in IA1..IA10 in the state Assigned-to-other-choice. This number is put into the state Assigned-to-vote-choice;
  • For each option B and C, a number is chosen:
    • Either a previously used and stored number for votes B and C;
    • Or either a previously generated number in IB1..IB10 and IC1..IC10 and with the state Assigned-to-vote-choice;
    • Or either a previously generated number in IB1..IB10 and IC1..IC10 and with the state Unused. The state is put to state Assigned-to-other-choice.

Then the receipt is given to the voter as usual and the chosen option and associated number is stored for final counting.

For an initial voter, it is always possible to have random number, either a new one for his/her option A and a previously generated one for options B and C. As those two numbers are associated to state Assigned-to-other-choice, at one point in the future another voter is going to select those numbers and use it as his/her vote option, thus publishing it on the final web site and making the receipt of the initial voter perfectly valid.

In the above algorithm, the probability of selection between the different options might be not equal. The size 10 of the initial pool is chosen so that the probability of having the pool empty at the end of the vote is high. This remains to be verified.

It now remains to make a detailed presentation and analysis of the protocol and to implement it.

no comment no trackback

Thursday, July 15 2010

An interesting new electronic voting protocol by Frédéric Connes

By d. on Thursday, July 15 2010, 13:00 - Vote électronique / demexp

I recently stumbled on this presentation at SSTIC 2010 on the Security of voting systems. Beyond the usual presentation on the lack of security in current electronic voting systems, Frédéric Connes presents an interesting new electronic voting protocol.

This protocol has been firstly draft in a first paper in 2008 and then in an updated second French paper for SSTIC 2010. The French slides of the SSTIC 2010 presentation are also available.

Very roughly, the main idea of this protocol is to associate a randomly generated number to each new vote. For example, if in a election amongst three people A, B, and C I vote for A, a random number 23482 is generated and associated to my vote A. Just after leaving the voting both, I also receive a paper receipt where my choice is displayed ("A 23482"). To keep the anonymity of my vote, for other options B and C a number is also printed, number chosen so that it corresponds to the choice of a previous voter. At the end of the vote, the results are published on a web site. Everybody can verify that his/her vote is correctly taken into account by checking that the random number is correctly displayed with the correct choice. One can also verify other options on the receipt. And one can also recount the tally the displayed votes and verify the election result.

This protocol ensures the good properties of a voting protocol:

  • My vote is anonymous because there is no way to associate my identity to the random number;
  • I have no way to prove that I vote for a given person because all the votes on the receipt are valid and displayed on the web site;
  • The whole vote can be audited because everybody can check that the content of his receipt is correctly displayed on the web site and recount the whole vote.

This protocol is relatively simple to understand, with no complex cryptography and with simple procedures. Of course, this protocol is far from being perfect and its author present some weak points and counter-measures:

  • the random number should be really chosen at random. The author presents two procedures to ensure this randomness. One of them is to let both the voter and the voting machine participate in the generation of the random number, but this seems very complicated to me;
  • For the first voters, there is no or few previous random numbers for the choices different that his/her choice. The author propose to generate false votes for the first voter. This has strong implication, most notably that the vote of the first voter is not really taken into account;
  • It is possible to guess the vote by knowing the receipt of one or more voters before a given voter. The author proposes the ability to generate a "completely anonymous" receipt, where the random number generated for the vote is not displayed on the receipt. This breaks the nice property to check the receipt content on the final web site;
  • The receipt should signed to ensure its integrity, so one can go into a Court to defend ones vote in case an error is detected. This signing procedure complicates a lot the voting procedure.

Another issue that the author does not mention:

  • What happens if all voters vote for the same option? Are their vote still guaranteed to be anonymous?

Overall, this voting protocol is currently not perfect but it offers very interesting ideas and properties. Probably the most interesting of it is that the protocol is "Software independent" as defined by Ronald Rivest, meaning that the correct working of the vote procedure does not need a correct software, any (or most) errors in the software can be detected.

A lot of work would be needed on this protocol:

  • An attack tree to find the possible attacks and way to counter them;
  • A probability analysis of the protocol, especially in the attack scenario where an attacker knows one or more paper receipt;
  • A detailed description of the voting procedure, giving the rationale of each step and giving actions to take in case of errors (one or more receipt is not valid, the voter does not like the random number, etc.);
  • A formal description of all the properties and invariants of the protocol.

I would like to thank Frédéric Connes for his very stimulating paper. :-)

no comment no trackback

Thursday, April 1 2010

Pourquoi je quitte l'expérience démocratique

By d. on Thursday, April 1 2010, 13:00 - Vote électronique / demexp

demexp On m'a récemment contacté à propos de l'expérience démocratique. J'avais déjà annoncé que je quittais le projet mais j'ai fini par élaborer une réponse plus précise. Il me semble intéressant de la rendre publique, non pas pour étaler mes états d'âmes mais comme une réflexion a posteriori sur un engagement et sur un projet de logiciel Libre qui n'a pas marché (et accessoirement pour l'« histoire » du projet ;-).

Si on retourne en 2003, je venais surtout pour l'aspect informatique du projet. Faire un logiciel de débat et de vote électronique original, c'était intéressant et très motivant. Mais après plusieurs années de développement je n'ai toujours pas un logiciel utilisable et je me suis retrouvé tout seul à le faire (ou quasiment). La lassitude a fait le reste du travail. ;-)

Par ailleurs, certains choix technologiques ont limité le développement du projet (client lourd en Gtk+, pas d'interface web), même si cela était dû à des contraintes quand j'ai commencé (Ocsigen n'existait pas à l'époque). Pour d'autres choix comme utiliser le langage OCaml, ça a très certainement limité l'arrivée de nouveaux développeurs. Mais je n'en aurais pas fait autant dans des langages plus classiques comme PHP ou Python. D'ailleurs d'autres ont proposé des morceaux de logiciel, en repartant de zéro comme Jean-Marc Fauché ou Lyu Abe. Mais ces propositions ne m'ont jamais emballé.

Plus sur le fond, je m'interroge pas mal sur le sens du projet. La démocratie ne se limite pas au vote, le débat et la formation des citoyens sont tout aussi important. Après quelques années, j'ai eu l'impression qu'on se concentrait uniquement sur l'aspect vote et pas assez sur les autres aspects. Pour le dire autrement, c'était peut-être plus important de faire un serveur de listes de diffusion, un service web pour synthétiser les débats et puis finalement voter en Condorcet avec du papier et du crayon que de faire un logiciel de vote électronique. On avait dit qu'on ferait des « soirées Condorcet » dans un bar, pour mettre en œuvre de manière concrète et ludique les idées du projet : cela ne s'est jamais fait.

Pour le logiciel, je suis parti sans réellement de spécifications, quasiment par le codage. Ce n'est pas comme ça que l'on fait un bon logiciel. ;-) Évidemment, quand on a démarré, on ne savait pas trop où on allait. Maintenant je pense que j'aurais des idées plus claires.

Informatiquement parlant, l'amplitude du projet est très vaste. Cela va des bases de données aux interfaces graphiques en passant par la cryptographie ou le réseau. C'est très stimulant sur le plan intellectuel, on apprend pleins de choses mais on n'est pas forcément bon partout.

Sur un plan plus pratique et citoyen, le vote électronique est très polémique (voir par exemple ordinateurs-de-vote.org). Je suis moi même contre les machines de votes actuelles[1] ! Il est quasiment impossible de faire un logiciel de vote aussi transparent qu'une urne en plexiglas. La recherche dans le domaine des protocoles de vote avance mais il faudra encore probablement de nombreuses années avant d'avoir quelque chose d'utilisable. Et ce sera très vraisemblablement plus compliqué qu'un bulletin dans une urne.

Sur le plan plus humain, on a démarré à quatre sur le projet, puis à trois au cœur. J'ai trouvé sur le long terme que j'étais un peu seul à faire la gestion de tâches informatiques (mise à jour du serveur, répondre sur les listes, le développement, etc.), malgré le soutien de mes deux compères. Ils ont beau être les pères de l'idée, j'ai trouvé que leur implication n'y était plus.

Enfin et surtout, après plusieurs années, j'ai envie de m'attaquer à d'autres défis, dans des domaines totalement différent et cela ne se fera pas sans dégager du temps libre. J'ai donc arrếté mon implication dans des projets non « productifs ».

Voilà, c'est probablement trop long et un peu confus, mais c'est dur de résumer plusieurs années de projet en quelques mots.

Je considère toujours que la thématique du projet, la réflexion sur la démocratie et le rôle du politique, est cruciale. Peut-être juste que l'angle n'était pas le bon, je ne sais pas. Apparemment, d'autres on des idées similaires et très intéressantes.

Et l'expérience a été pour moi enrichissante. Je ne regrette rien ! :-)

Notes

[1] Vous avez dit schizophrène ? ;-)

2 comments

Wednesday, March 31 2010

Gagner du temps n°2 : se désinscrire des listes de diffusion et flux RSS qu'on ne lit pas

By d. on Wednesday, March 31 2010, 13:00

Dans un billet précédent, j'avais indiqué comment j'essayais d'avoir une boite de courrier entrante vide pour être réactif et ne pas perdre trop de temps.

Le deuxième conseil d'organisation du jour : se désinscrire des listes de diffusion et flux RSS qu'on ne lit pas ou très rarement.

Comme on les lit très rarement, on a bien souvent trop de messages ou billets en retard, les réponses qu'on aurait éventuellement pu faire sont obsolètes et cela prend tout simplement trop de temps de tout lire. Et même s'il y a peu de trafic ou qu'on ne lit pas les messages, on perd juste du temps à marquer les messages comme lu.

J'ai trouvé une solution simple : je me désabonne de ces flux RSS et listes de diffusions. J'ai l'impression d'avoir des journées plus longues. ;-)

one comment

Monday, March 29 2010

Status of OCaml packages on Ubuntu Lucid Lynx (10.04 LTS): transition to OCaml 3.11.2 finished

By d. on Monday, March 29 2010, 13:00 - Free Software / Libre

I don't know who are responsible for this but the OCaml packages of Ubuntu Lucid Lynx 10.04 LTS have all transitioned to OCaml 3.11.2 on main architectures (amd64 and i386). A big thank to the mysterious developer(s)! Even for secondary architectures, all packages have transitioned to 3.11.2 except 3 packages on armel: coq, ssreflect and why.

Of course, having a source OCaml package compiled with the correct version of the OCaml compiler does not make it automatically working so I encourage you to test your preferred Ubuntu OCaml packages in Lucid.

If we now compare the set of source packages available respectively on Debian Unstable and Ubuntu Lucid, the situation is not so perfect. On the 145 OCaml packages available in Unstable, 21 are not at the same stage in Lucid.

There are 5 packages simply not available in Ubuntu:

  • clang 2.6-3
  • llvm 2.6-8
  • llvm-snapshot 20100312-1
  • obrowser 1.1+dfsg-4
  • unison2.27.57 2.27.57-2

There are 11 packages that have been updated in Unstable but not upgraded in Lucid:

  • Package Unstable-version Lucid-Version
  • approx 4.2-1 4.1-1
  • camlpdf 0.5-1 0.4-4
  • coccinelle 0.2.2.deb-1 0.2.0.deb-1ubuntu2
  • graphviz 2.26.3-3 2.20.2-8ubuntu3
  • ocaml-csv 1.2.0-1 1.1.7-2
  • ocaml-ssl 0.4.4-1 0.4.3-3
  • ocaml-text 0.3-1 0.2-3
  • ocsigen 1.3.0-4 1.2.2-1
  • pgocaml 1.4-1 1.3-3
  • postgresql-ocaml 1.12.4-1 1.12.1-2
  • unison 2.32.52-1 2.27.57-2ubuntu2

And lastly there are 5 packages that had minor updates or packaging bug fix in Unstable but not in Lucid:

  • Package Unstable-version Lucid-Version
  • nurpawiki 1.2.3-4 1.2.3-3
  • frama-c 20090902+beryllium+dfsg-5 20090902+beryllium+dfsg-4
  • ocamlgraph 1.3+debian-2 1.3+debian-1
  • sks 1.1.1-2 1.1.1-1ubuntu2
  • ssreflect 1.2+dfsg-4 1.2+dfsg-3

I don't know what to do about those packages or if I can even do anything. According to Ubuntu Lucid release schedule, we are reaching Beta 2 Freeze (on April the 1st) where uploads for packages in main and restricted are held in the queue and are subject to manual approval of the release team.

Do you have any advice?

Beside that, we still have 124 OCaml source packages in good shape in Lucid!

6 comments

Thursday, March 18 2010

Looking for a C software for Formal Verification

By d. on Thursday, March 18 2010, 13:00 - Software Verification / Vérification de logiciel

As you probably know, I'm a huge fan of Formal Methods: use appropriate Mathematics and tools to ensure a program is correct in all possible situations. In other words, bug free software... well, sort of. :-)

The interesting side of this is that tools to apply Formal Methods have improved a lot and most of them are now Free Software. I'm maintaining a list of Free Software tools for Formal Methods (it is a wiki, you can update it!).

I would like to make an experiment with Frama-C and its plugins, especially Jessie. Frama-C is a framework for static analysis of C programs developed at CEA. Combined with the Why and Alt-Ergo tools, you can prove some properties on real C code (absence of integer underflow or overflow, absence of out-of-bound accesses, absence of NULL pointer de-referencing, program's specific properties, etc.). All those tools are Free Software and are developed in OCaml. And they now are available in Debian and Ubuntu!

I made a simple experiment last year but I would like to make a more elaborated one.

Therefore, I'm looking for a piece of C code with following criteria:

  • Free Software: I'm interested in improving software for the whole humankind; ;-)
  • Pure C code, no C++. If there is some assembly, I could work around for example by re-writting corresponding C function;
  • Code of moderate size, a few thousands line at most. It could be a sub-module or subset of a bigger code;
  • Code using mostly integers and pointers, few strings (aka char *)[1];
  • Verifying some properties on this code would be "interesting". Several possible reasons: for security or safety reasons, because the code is used in an embedded platform on which modifications are difficult once in production or simply because this code is used a lot.

If you know some software that fills those criteria, let me know through a comment or at dmentre@linux-france.org!

Notes

[1] Frama-C is a bit slow to handle strings and it can become cumbersome.

3 comments

Wednesday, March 10 2010

Standing on the shoulders of giants: MapOSMatic in a sea of Free Software

By d. on Wednesday, March 10 2010, 13:00 - Open Street Map

One thing that stroked me after the two hackfests we made to develop MapOSMatic: the little amount of code we really developed! In fact, we are re-using a lot of other Free Software.

Using the excellent sloccount, I tried to get some figures. MapOSMatic is about 3150 lines of code, 90% made of Python. MapOSMatic dependencies count for more than 600,000 lines of code, counting PostgreSQL, PostGIS, Apache 2 httpd, Django framework and some small libraries.[1] So we only developed about 0.5% of the code needed to run the MapOSMatic service. And I obviously do not count the OpenStreetMap data itself, which is about 70 GB!

That's why we can say, as most of software developers, that we are standing on the shoulders of giants: we are re-using knowledge, hard-work and polishing of a lot of other people. MapOSMatic is a glaring example of this fact and of the power of Free Software.

Notes

[1] Counting all MapOSMatic dependencies is nearly impossible: it is hard to draw a line between what is part of the system and what is a specific dependency of MapOSMatic (e.g. Python).

Thursday, January 14 2010

Quick news: OCaml on Ubuntu Lucid and MapOSMatic

By d. on Thursday, January 14 2010, 13:00 - Free Software / Libre

OCaml on Ubuntu Lucid

I have updated my scripts to compare Ubuntu OCaml packages to Debian ones. This time, I'm comparing Ubuntu Lucid against Debian testing, as for Lucid packages are imported from Debian testing (because Lucid is a Long Term Support release).

You'll find all the generated files here: http://bentobako.org/ubuntu-ocaml-status/raw/

MapOSMatic

As you have probably seen, we have done major improvements to MapOSMatic during Christmas, at both the web site level and the rendering level. I won't go into details, just read our initial announcement. Since then, we are continuing our improvements on maposmatic web front-end and ocitysmap back-end, with a new web site layout, translation of web site and maps in many languages (Arabic, Brazilian Portuguese, Catalan, Dutch, French, German, Italian and Russian). Many thanks to the numerous contributors!

We still have a lot of things to do or bugs to fix but the feedback is very positive and rewarding! Many thanks!

one comment

Thursday, December 3 2009

Installation of Linux Ubuntu Karmic Koala (9.10) on an ASUS UL30A-QX090V laptop

By d. on Thursday, December 3 2009, 13:00 - Free Software / Libre

ASUS UL30A -- © 2009 David Mentré, license CC-BY-SA I recently installed an Ubuntu Karmic Koala (9.10) Linux distribution on an ASUS UL30A-QX090V laptop. The installation went rather smoothly. You'll find below the useful details.

Despite being in favour of reimbursement of software bundled with hardware, I decided to keep the pre-installed proprietary Windows 7 64 bits. It will allow me to test Windows 7, compare it with my Ubuntu system and test Free Software on Windows.

Under Windows 7: make room for Linux

One needs to make room for the Linux system on the 320 Gb hard disk. Fortunately, Windows is installed in a 74 GB partition and there is one 208 GB empty partition.

So, go to Windows icon -> Computer -> Right-click -> Manage -> Storage -> Disk Management. Three partitions are available:

  • 14,65 GB: no name and not mounted, probably for system re-installation;
  • 74,52 GB (C:) : Windows 7;
  • 208,92 GB (D:) : DATA, empty partition.

One needs to remove DATA partition. Right-click on this partition and choose Remove volume.

If you have a different laptop with no free partition, it might be useful to know that Windows Vista and Windows 7 can resize partitions using the same pre-installed program.

Under my current Ubuntu computer: prepare the USB installation key

I download the ISO image of the latest Ubuntu Karmic Koala 9.10 in 64 bits version: the machine has 4 GB of RAM and you can only access 3 GB with a 32 bits system.

After download, I checked that the MD5 checksum is correct. In a terminal, do "md5sum ubuntu-9.10-desktop-amd64.iso" and search for the result in the UbuntuHashes web page.

I then use usb-creator to setup an USB key with this dowloaded image. Plug in your USB key. Start usb-creator from System -> Administration -> USB Boot Disk Creator. Select the ISO image you have just downloaded and chose the USB key you have just plugged in. Then press Create button. I chose to not use an area where data can be saved on the USB key.

By the way, usb-creator installs what is needed on the USB key and makes it bootable, but it keeps the FAT32 file system so the key can still be used as a regular USB key to share documents.

On the ASUS UL30A-QX090V Laptop: install Ubuntu

Plug in the USB key and power on the laptop.

By pressing F2 when the ASUS logo is displayed, go to the BIOS and configure it to boot on the USB key. The magic trick: the USB key is seen as a hard drive! So you must go to the hard drive boot order sub-menu to put the USB key in first position, before the real hard drive. Save and exit from the BIOS through F10.

The machine then reboots and should boot on the USB key (or do a cold start by powering off then powering on the laptop).

Install Ubuntu as usual. I used the biggest free space, letting Ubuntu chose the partitioning. As this is a laptop, I also chose to encrypt the user's home folder.

After a reboot, you now have a shiny new Linux system on your laptop! Enjoy! :-)

What's working

I haven't tested everything yet. Right now:

  • Working: wired and wireless network (WiFi tested using WPA2), sound output, display at native screen resolution, extended touchpad (emulation of mouse scroll wheel and right-click), processor frequency scaling according to actual use, SDHC card reader;
  • Not tested: sound input, webcam, battery autonomy, 3D acceleration[1], hibernation, external display output (VGA and HDMI);
  • Not woking: nothing yet! ;-)

Notes

[1] But special effects are available on the desktop, so I assume 3D acceleration can be used

11 comments

- page 1 of 8