Slashdot Mirror
Domain: tugraz.at
Stories and comments across the archive that link to tugraz.at.
Comments · 20
-
Re:"Slightly slower"?
The sad part really is that I don't think that going through that many iterations is going to anything but drive people away because of the performance impact. While I know RIPEMD160 is considered strong I don't think it's stronger than Keccak which is the SHA-3 winner.
-
Re:Skein
I've been following the progress on the SHA-3 Zoo and I haven't seen anything indicating Skein is broken. I've been following Skein with particular interest because I like how it can be tweaked in various ways to serve particular needs.
-
Elephant's memory
The most beautiful iconic language ever designed. Unfortunately, it didn't catch up. A quick intro. The official page (it's an authentic webpage from 1994, be indulgent with the formating!).
-
Re:Because it's painfully limited?
I've not used the SSL/TLS functionality in Java/Android yet. But I remember skimming over it and reading clearly that you CAN use self signed certificates with no problem at all.
Remember that it's Java, isn't there a library you can download somewhere that can handle user certificates?
With a bit of google I found: http://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/jca_jceI wasn't a Java programmer, so I'm used to doing things, like, oh you know, programming. I don't miss any JRE or libraries. And when I do, I've found that there is a Java library for what I need. If not, I program it.
What non-sense.
-
I was a little worried
I was a little worried by the plethora of submissions. I was worried it would take them forever to decide. But luckily they've been rather ruthless in culling for the third round. Given the data available on the The SHA-3 Zoo they chose wisely.
Personally, I think Skein is interestingly feature rich, which both worries and intrigues me. Looking it appears that all the features are built on a core in which the real security lies, so I'm not too worried. Skein's core in fact appears to be extremely simple.
-
Re:Disclaimer
...the people (whoever they are) who are actually evaluating the algorithms themselves.
I figured out who they are.
-
Re:Indeed ...
An real world example of the power of metadata is Google. Basicly, the ranking works because of metadata, originating as metadata or derived from the content of the page.
While probably correct, there really isn't much substance to your comment, so I decided to add some links to one of the best examples of exploiting metadata: network analysis (or applied graph theory, depending on your bent). It's been applied to webpages, phone call records (using just who calls whom), scientific collaboration networks, social networks, and a whole bunch more. The following links make for some interesting reading about the scope and power of exploiting metadata (at least the introductions):
PageRank, HITS: rank webpages as authoritative based on the links between them (i.e. assume that good pages link to good pages, etc.) PageRank Analyzing the web web communities based on link structure analyzing scientific collaborations based only on patterns of co-authorship and co-citation another one like the previous (although as a computer scientist, i don't think much of mark newman, he writes well).
Remember kids, it's popular because it works!
-
Re:Wait... what?
There is no such thing as trusted private encryption. Effective secure encryption is astoundingly complicated and you can not devise effective encryption in a vacuum. Lots of companies show us ineffective untrustworthy encryption which they develop in secret and which fail in short order... like CSS which is used on DVDs or the DRM in popular games and other digital media. Haven't you read folks on Slashdot mocking them for it?
So the best way is do everything out in the open and have people find the weakness in it before it goes into production. Because once it goes into production you don't need to be code breaker to enjoy the stunning stupidity of the fools that rely on private encryption... you only need to be able to find the app with google and download it.
Have a look at look at the ongoing contest for SHA-3. It's been reported here I think. Or you could the about how they came up with AES.
Here's the zoo: http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
As a side note: Contests and prizes are remarkably effective method of spending the public's money for public good... as long as the results are open and patent free.
-
Article is out of date
The article is already out of date. The round 1 candidates were announced back on December 11. Since that time, 11 candidates have been broken. For the latest information, I recommend visiting the SHA-3 Zoo.
Also, the article suggests that candidates will continue to be broken quickly, but I doubt this will happen. The weak hashes will be broken quickly, but there are likely to be many strong candidates which will not be broken during the contest. Other factors (speed, simplicity, etc.) will determine the ultimate winner.
-
Re:My favorites: Keccak and Skein
A better overview: The SHA-3 Zoo. Did you look at Edon-R? It is not be the most flexible, but it's the fastest one. Followed by Skein. I agree to what Bruce Schneier wrote: sort the algorithms based on performance and features, and then focus on the top 12.
-
Re:My favorites: Keccak and Skein
A better overview: The SHA-3 Zoo. Did you look at Edon-R? It is not be the most flexible, but it's the fastest one. Followed by Skein. I agree to what Bruce Schneier wrote: sort the algorithms based on performance and features, and then focus on the top 12.
-
My favorites: Keccak and Skein
I spent a few hours the other day looking over all of the submissions; Keccak and Skein are my favorite contributions. My criteria was "does the hash generate a fixed-length output, or is the hash capable of also being used as a stream cipher".
There are only four unbroken contributions that can generate arbitrarily long streams of numbers: Keccak, LUX, MeshHash, and Skein. Of these contributions, LUX and MeshHash, while not broken, already have cryptanalysis done against them that make me a little uneasy using them.
I prefer Keccak over Skein, for the simple reason there is a bonda-fide 32-bit variant of Keccak that can run quickly on 32-bit systems. Skein is designed to run well only on 64-bit systems. Part 5.4 of the Skein paper talks about the possibility of making a 32-bit variant of Skein but that they need to come up with rotation and permutation constants, and figure out how many rounds a 32-bit Skein variant would need. I would like to see Schneier, et al (the team responsible for Skein) actually do this. Skein is more flexible that Keccak (I think threefish is the first tweakable block cipher since the somewhat broken Hasty Pudding Cipher), and is faster on 64-bit systems, but I would like to see it run on embedded and legacy systems better. -
My favorites: Keccak and Skein
I spent a few hours the other day looking over all of the submissions; Keccak and Skein are my favorite contributions. My criteria was "does the hash generate a fixed-length output, or is the hash capable of also being used as a stream cipher".
There are only four unbroken contributions that can generate arbitrarily long streams of numbers: Keccak, LUX, MeshHash, and Skein. Of these contributions, LUX and MeshHash, while not broken, already have cryptanalysis done against them that make me a little uneasy using them.
I prefer Keccak over Skein, for the simple reason there is a bonda-fide 32-bit variant of Keccak that can run quickly on 32-bit systems. Skein is designed to run well only on 64-bit systems. Part 5.4 of the Skein paper talks about the possibility of making a 32-bit variant of Skein but that they need to come up with rotation and permutation constants, and figure out how many rounds a 32-bit Skein variant would need. I would like to see Schneier, et al (the team responsible for Skein) actually do this. Skein is more flexible that Keccak (I think threefish is the first tweakable block cipher since the somewhat broken Hasty Pudding Cipher), and is faster on 64-bit systems, but I would like to see it run on embedded and legacy systems better. -
Re:Where have all the good people gone?
http://www.nsti.org/Nanotech2008/symposia/Nanotech_Neurology.html
http://www.bci-info.tugraz.at/bibliography_view
http://www.wtec.org/bci/workshop/01_Berger_Intro.pdf
Required steps:
Manufacture a micro-electrode array (pretty easy at this point)
Culture neurons (also doable)
Get the neurons to stick to the array in an orderly manner (this part is tricky: either they don't adhere, they adhere and die, too many adhere to one electrode and the clumps give a messy signal, etc.)
Wait a couple days and the neurons start firing (a crap shoot, sometimes they croak, get a bio guy to nurture them good)
Make sense out of the noisy signal (tough, the time scales on the signals is pretty quick)
Stimulate some neurons, see what the network response is (doable if all the previous steps worked perfectly)
Problems:
Power (TFA used 110V out of the wall and a robot battery; not as useful for inside a patient's skull)Communications (RF-MEMS is still a work in progress)
A useful product would be a network of invasive implants that don't cause (much) damage at the implant site and don't lose function over time. Link these to a logic module (outside the brain, but maybe inside the body or skull) that makes sense of the input and can tell the actuators what to stimulate. I think you'll need the logic module outside the invasive implant because you just don't have that much volume to play with in the implant.
I hope this leads to fruitful stuff. I wasn't very successful at it because my EE wasn't good enough to do the signal processing, my bio wasn't good enough to keep neurons happy or even alive, and I didn't much like working 80 hours/week for $12k/yr. I was good at the wet bench fab and wiring though...
-
They used to say the same about darkness
Bah. They used to say the same about darkness, before the Universal Theory of Dark
-
BOINC Project to Find SHA-1 Collision(s)
The linked NIST report mentions only the work of Prof. Yang with which no one has yet found a collision, but a team from Graz University of Technology (Austria) has proposed a significantly faster algorithm for producing SHA-1 collisions and is running a BOINC project to find one.
-
Re:You're out to lunchThe MEG (Motionless Electromagnetic Generator) has a patent filed which you can read all about yourself [...] his multiple attempts to patent the device were refused by the US patent office [...] The fact that the US patented office has refused patents because they do not understand them is enough for me to realize that revealing an invention is not enough to have it reproduced and used I am amused but somewhat puzzled by your seeming faith in the importance of patents. Whether a patent is awarded, in the USA at least, has nothing whatsoever to do with whether the device works or is even possible. The criteria for patents to be accepted are novelty, originality , and usefullness. Whether it works or not is utterly irrelevent. Take the following patent as a stark example: "A pulsed gravitational wave wormhole generator system that teleports a human being through hyperspace from one location to another". Scientists in particular pay not the slightest attention to patents in the context you're talking about: if an experiment is described that purports to demonstrate an exception to the first law of thermodynamics, whether the device in question has been patented in the United States is a question of absolutely no importance whatsoever. much of our current technology was the result of "lone inventors" like Tesla, Edison, and Jefferson who among them there is one university degree and it's not in science or engineering. I'm not sure if you're being deliberately misleading or whether you've been mislead, but Tesla -- who is in reality the only one out of the three you mention who actually significantly changed our understanding of Physics -- studied electrical engineering at the Austrian Polytechnic in Graz. He was apparently discharged without a degree for non-payment of tuition fees, though some sources disagree on the reason. But if you look at lone inventors you can look at Newman, who did supply his machine for testing and it was determined to be a highly efficient AC converter Don't know what source you have on that, but the NBS test gave the Newman machine as 27 to 67 percent efficient; commercial devices at the time already operated in excess of 90%. but when asked to rerun the test with the machine "correctly" set up, the testing agency refused. I'm not saying that Newman's machine works, but that he did at least attempt to have it scrutinized. It would be very simple for him to demonstrate over-unity: connect the output to the input and have it run by itself with no external input. He has consistently refused to do this. The one time he permitted an outside agency to test the device, it performed exactly as you would expect it to (i.e. not over-unity); so of course he's going to claim it "wasn't set up correctly". No I am not trying to support Free Energy Suppression conspiracies, just saying it takes a lot more than revealing an invention to have it seem production and use, and that rejecting the possibility that a device is usefully simply because the inventory claims Over Unity is doing a great injustice to the world If any of the free energy crowd did uncover a previously unknown scientific principle in their free time between coming up with ever more imaginitive twists on Stevin's ball-ramp; it would be absurdly simple to reveal details of an experiment that demonstrated the principle. Patents are supremely irrelevent if you have a repeatable experiment. None have done so.
-
Re:Epically bad.However, compositing two algorithms that work on different principles does protect you if cryptanalysis reveals weakness in one method but not the other. Most block ciphers do encryption in "rounds" where the output is fed back as input a certain number of times (called "rounds"). For AES/Rijndael, see this page for the names of papers/research which have made theoretical (this is important!) attacks on Rijndael by reducing the number of rounds needed to crack the encryption scheme. By "theoretical", a lot of these attacks are based on computing power which is silly/uneconomical to even the largest government efforts.
Therefore it is obvious to see that encrypting data twice doesn't always mean you get double the level of protection as encrypting it once. The choice of encryption key for the 2nd round of encryption is also likely to be important.
You seem to be making the assumption that the output of an encryption cipher has unlimited entropy (100% random), when in fact this is not the case. Cipher output is not as good as random data, and there may be certain predictions that can be made on the data.
To think about this in the simplest terms, if your encryption scheme is just doing a plain XOR of the plaintext with a random number, the output is nowhere near random. If "e" is the most popular character used in the plaintext, you can see this in the ciphertext output quite clearly as well. This ciphertext has very low entropy, as the character distribution in the ciphertext is the same as the plaintext. Applying another round of XOR encryption will not help, as the same flaw is carried through into the output of the 2nd round of encryption.
Rijndael/Serpent/Twofish are far more complicated and don't suffer to the same extent as basic ciphers such as XOR/ROT13, but there are most certainly attacks on these ciphers which can reduce the amount of cracking time from 2^256 down to a smaller number. The output of a cipher hasn't got unlimited entropy and therefore attacks try to find patterns and similarities between plaintext input and ciphertext output. Encrypting with AES twice won't mean you have double the security. In a worst case scenario (such as with XOR/ROT13 encryption), you are not achieving anything by doubling the rounds.
Encrypting with multiple different ciphers is a slightly different topic. If you use two totally isolated random keys for each level of encryption, then your security is going to be maximized. If you derive the two keys from the same password/master key, you have serious problems. Imagine you have a passphrase where the entropy is extremely low ("e" is the most common character, first character is uppercase, last character is a period, etc). You use this passphrase for the first round of AES encryption, and then you take that ciphertext and re-encrypt it this time using XOR (based on the passphrase). By re-encrypting with XOR, you are leaking your passphrase to the attacker through the 2nd layer of encryption.
Again, that is a very basic example, but the same theory applies to combining complex ciphers such as Rijndael/Serpent/etc.
The weakest link in all crypto systems is the implementation of the ciphers and the key management - not the cipher itself. -
Re:Static analysis unnecessary!
Static analysis becomes virtually unnecessary when you use a proper, statically-typed language like Haskell, Standard ML or OCaml. Furthermore, the use of garbage collection eliminates many of the buffer overruns that plague C and C++ software. Add in proper unit testing, and you're almost guaranteed to have a rock-solid system, developed very economically and often with extremely clean code.
As nice as that is it runs into the difficulty that there are already millions of lines of code in Java and rewriting them in ML or Haskell just isn't feasible. If you want a good intermediary position then using JML to specify the existing Java code and jmlunit and ESC/Java2 to do unit testing and static analysis based on the specification can get you a long way. -
Re:Two words: closed architecture
Not necessarily. You really don't have to have the lowest level understanding/knowledge of the GPU to do interesting work.
I saw a nice presentation at the IABEM conference in Graz this Summer from a researcher writing BEM-based Laplace-equation solvers on GPU units.
GPGPU for BEM -- By T. TAKAHASHI
http://www.igte.tugraz.at/guest/iabem2006/printpdf .php?paperid=17697&type=fullpaper&preview=1
There are some links, and even some code in that paper (PDF)
Essentially all he had to do was map his mathematical operations (e.g. vector-matrix-multiplications) onto equivalent graphical operations. At that point you need only the same access to the GPU as a games programmer.
Now, for the protein folding, you may need more elaborate access to the GPU internals (I don't know what mathematical operations are involved). However, I think for the operations where the GPU offers the best speed-up, the published interfaces provided by the drivers will be sufficient (the GPU hardware is optimised for certain operations, and these are precisely the operations that you get easiest access to).