Slashdot Mirror
Domain: brics.dk
Stories and comments across the archive that link to brics.dk.
Comments · 10
-
Re:Worthless
According to my 'fessor, here's The One True Way for grading multiple-choice tests (with proofs and all):
http://www.brics.dk/~mis/multiple.pdf
(yours is not the One True Way)
Ugly as it is, you may want to use the google html as the pdf seems to have permission issues: http://www.google.com/search?q=cache:0BahY4i6HLkJ: www.brics.dk/~mis/multiple.pdf+multiple.pdf+site:b rics.dk&hl=en&ct=clnk&cd=1&gl=dk&client=firefox-a -
Re:TrueCrypt is not for USB sticks
For example CBC with fixed IV leaks more, possibly even a file fingerprint.
Indeed, it is easy to construct a file which is easilly recognized after being encrypted with such a scheme. In fact I constructed one a long time ago, it is here. (OK this file only applies to some of the weakest IVs, but you get the point). However LRW also allows fingerprinting, but only if you can get two versions of the encrypted sectors, one version with the file, and another version with zeros.
Personally I would be content with only having leak out when a sector holds identical data as before.
Might be acceptable for most users, but as I pointed out earlier, the algorithms I know for this have a significant CPU overhead. If you know a solution for this without the performance penalty, I'd very much like to hear about it.
Either you sacrifice atomicity. Or you do a 2-phase commit or the like and risk a major performaance impact. Or you sacrifice sector size (and store the extra data in there)
Or you come up with a clever combination of the different algorithms. Actually I don't know exactly what a 2-phase commit is, but a possible approach goes as follows. You consider the disk as a number of regions where each region consist of 200 data sectors and a metadata sector at each end. The metadata contains a 16 byte tweak common to all sectors in the region and a 16 bit counter per sector. The two are concatenated with the sector number to construct a unique tweak.
Now you can update the first metadata sector, then update any subset of the data sectors, and finally update the second metadata sector. You get two extra writes no matter how many of the sectors you updated, and you essentially don't get any extra seeks. And for each sector at least one of the two metadata sectors will be usable. You will have to duplicate the least significant bit of the counter into the data sector so you will know which meta data sector to use. That lost bit will easilly fit in the meta data sector. And there is enough space left over in the meta data sector to do a probablistic encryption of the meta data sector.
There are a few drawbacks, for example you need to reencrypt the entire region each time a counter wraps, but the ammortized time required for that is insignificant. You can do the structure kind of recursively to avoid most of the full region reeencryption. The only problem left which I don't have a complete solution for yet is, that each write operation would have to start by comparing the two metadata sectors to know if a recovery is required.
There, now also shown independently by Gweihir.I never said the proof was complicated. -
When speed matters
there were libraries like ORO that would provide regex support, but it wasn't built in and not many companies allow the use of 3rd party libraries
For those who can utilize third-party libs, consider evaluating this DFA/NFA automaton, a regexp package that is significantly faster than java.util.regex.
However, like many things in computer science, speed gains come at a price. In this case, the regular expression language supported is not quite as rich as the JDK implementation. -
Re:Totally true!
I know exactly why nobody uses XML and everyone uses PDF.
XML has absolutely NO software support. I can painstakingly write this great XML file by hand, using either a long, complex Tutorial which I can hopefully bend to my needs, or by reading the several pages of specification packed with technical garbage. Fine. Now what the fuck do I view it in? What do my recipients view it in?
On the other hand, to create a PDF, I can create the content with my application of choice and print to a PDF distiller (of which there's a bunch of free ones, mostly relying on GhostScript). A PDF viewer is already installed on almost every user's machine, and are available in any size (from minimal to bloated) for any platform.
When XML becomes just as easy to use (create document, export / print, e-mail) then it has a small, tiny chance to become relevant in the document space. -
Re:what's icfp????
The ICFP is the International Conference on Functional Programming, and the ICFP programming contest is (not surprisingly) a programming contest held in conjunction with the ICFP (the contest specs are usually announced around June -- look for a story on slashdot next summer). However, despite the connection to the ICFP, the contest places no restriction on the languages you can use. Well, I assume they require that your language produce a result that they can run on their testing machines, but that's it.
-
Also announced by Adi Shamir in February
During the Cryptographer's Panel at the RSA conference, Adi Shamir made a short reference to this vulnerability. He confirmed in subsequent e-mail that of course he had a working implementation, or he wouldn't have mentioned it in public, and that a presentation would be forthcoming at the Eurocrypt 2005 rump session next week in Denmark.
I was sore disappointed that the press didn't pick it up then, because I thought it was the most interesting item in any of the keynote talks at RSA (although the hash function flaw announcements came a close second).
Cache contention as a covert timing channel has been explored at least since 1983/84 (when I encountered an instance of it during a TCSEC project and was gently shooed away from exploring such a "sensitive" topic). The precision targeting of this particular attack is really slick. -
The article shows a big lack of insight!The article says it's impossible because alot of different things can't be satisfied:
- Anonymity/Privacy
- Infrastructure
- Vote buying/Should "surfing"
- Vulnerability to hackers
Most of these are easy to solve with trivial teqniques, and really
shows that the article shows that it is a restriction of peoples minds
and not the e-voting as such. It's easy to argument against everything
if you use the old way of thinking, and don't do the necessary research
into what is possible. I'll try and address the points and show that
there are teqniques to make them atleast as good as todays normal elections
and maybe even better.
A note I would like to make before embarking on this journey is that
elections should atleast until a certain amount of trust is gotten be
combined with normal election, so that people who doesn't feel confident
in the new system can always use the old. This is also due to all the
script kiddies out there who pose a major problem in terms of DOS attacks.
Anonymity/Privacy:
This is the point that is the most important about
democracy and therefore also the one that should be stressed the most.
The funny part about this is that it has been known how to do this for
the last 5 years following a paper by R. Cramer, R. Gennaro and
B. Schoenmakers: A
Secure and Optimally Efficient Multi-Authority Election Scheme and
probably before that by others. This is done with homomorphic encryption
which can be compared to putting your vote into a box and locking it.
Then you can take all the locked boxes and combine them into 1 big
(without opening them) and then open the big box and get the result, which
will tell nothing about what each person voted (unless they all voted the
same). And there are alot of other schemes that improve this in certain
ways or make voting in other ways. An example that improves the above
(from exponential decryption to polynomial) is by M. Jurik and I. Damgaard:
A Generalisation, a Simplification
and some Applications of Paillier's Probabilistic Public-Key System.
Infrastructure:
This is probably the thing they're most right about. The problem is that
to make something sufficiently secure you need digital signatures and
that means you need a PKI (public key infrastructure). There are different
ways to do this. First you could require everyone that want's to use
the internet voting to register a public key. Secondly you could distribute
key cards. These 2 are both cumbersome and expensive, which is why I
tend to agree with the article on this point. But there are products out
there that can solve this easily eg.
Cryptomathic which has a
product named easy sign (got to products->Trust Products->easy Sign). In
short this sets up a server that has all the secret keys stored in a
secure way and users can the get the server to sign for them by using
a password system. This is not optimal in terms of security but it is
very close and it grants an very cheap PKI.
Vote buying/Should "surfing":
This is a real problem to e-vote, since you can't really see the person
doing this, but it is also one that with just a little bit of thought
can be done pretty easily. To avoid that anyone gives away their chip
card, password etc. you just bind it to the government information, so
that you can always go to a web site and get your health record, IRS
numbers and stuff like that with the same means of authentication. That
means that if you give it away you will not only give your vote away, but
also alot of personal information. To avoid that you have someone stand
behind you and make sure you vote the right thing, you can introduce
regret offices, where you on the election day can come down and get you
vote changed (getting your signature and the election offices signature)
and then this will override votes that was made over the internet.
As a last point I would like to make is that today it is also possible to
buy votes, either with fake IDs (which might not even be need in certain
places) or give the vote a micro camera and make them take a picture
that they have voted what you wanted.
Vulnerability to hackers:
This I'll only briefly discuss since the 2 papers mentioned in the
anynomity/privacy section actually provide threshold decryption,
which means that if a certain fractions of the servers (>50%) is online
and non-hacked then the correct result can be found. If the servers
is running different hardware and software configurations, it would
take a _extremly_ good hacker to accomplish this in 1 day.
As for DOS there isn't much you can do, but you can always distribute
things which means that the attack will have to be larger to accomplish
total breakdown.
These are my views and I don't say that they are flawless, but they do
give a fair amount of security. There is 1 more point I'll like to
stress which was not in the article since this might actually be an
improvement. The 2 articles mentioned above provides what is known as
universal verifiability, which means that it gives any person the
possibility of checking that the result is correct (given enough
computing power). Now that would be something most americans
would have liked in Florida ? - Anonymity/Privacy
-
Re:Small IE rant
PS: Thanks for the reminder about SOAP. I remember hearing the name, but never got around to looking into it until now.
-
Witness the revolution: <bigwig> is here!I have seen the future and it's bright. Instead of messing with low-level languages, trying to make them generate correct HTML, maintain persistent state through hack, etc. <bigwig> provides for a real refreshingly sane approach. Better than reading my ramplings, read the snippet below (copied without authorization) and visit the <bigwig> web site:
<bigwig> is a research project under BRICS. We are constructing a high-level programming language for developing interactive web services. Complete specifications are compiled into a conglomerate of lower-level technologies such as CGI, HTML, and JavaScript.
Our goal is to remove many of the obstacles that face current developers of web services to lower cost while increasing functionality and reliability. The <bigwig> language is an intellectual descendant of the MAWL project.
Among the issues we address are:
- persistent data
- sequential threads
- safe and dynamic construction of html documents
- concurrency control
- databases
- cryptologic security
- applet integration
- interaction with external services
- management of services
- monitoring of processes and data
-
Witness the revolution: <bigwig> is here!I have seen the future and it's bright. Instead of messing with low-level languages, trying to make them generate correct HTML, maintain persistent state through hack, etc. <bigwig> provides for a real refreshingly sane approach. Better than reading my ramplings, read the snippet below (copied without authorization) and visit the <bigwig> web site:
<bigwig> is a research project under BRICS. We are constructing a high-level programming language for developing interactive web services. Complete specifications are compiled into a conglomerate of lower-level technologies such as CGI, HTML, and JavaScript.
Our goal is to remove many of the obstacles that face current developers of web services to lower cost while increasing functionality and reliability. The <bigwig> language is an intellectual descendant of the MAWL project.
Among the issues we address are:
- persistent data
- sequential threads
- safe and dynamic construction of html documents
- concurrency control
- databases
- cryptologic security
- applet integration
- interaction with external services
- management of services
- monitoring of processes and data