This is a debatable issue. The look-up table itself is hardware, but the masks for the table have been created with a perl script. Someone apparently just wanted to `clean up a minor bug' in that script after validation, without re-testing it. Turns out this minor bug caused the whole fdiv-bug issue. So you could equally well argue that it was a software bug causing a hardware bug.
Its their job to be detailed. You have to infer those reports and draw conclusions.
I disagree. If they call themselves "Security Consultants" they should provide a little more consulting than simply running Nessus and printing a report. Sometimes you have to wonder why companies have no problems doling out money to external consultants, when the quality of the result is questionable at best.
Randomized salt values are not necessary. AES is used in Counter Mode, i.e. acts like a stream cipher. The output of AES (key-stream) is XORed with the plaintext and thus forms the ciphertext.
Therefore, even if you use a lot of "LOL" and "whats up", it will always generate different ciphertexts. Also, if you don't want anybody to know the exact length of your message, simply "fill it up" with zeros. This is described in more detail in "Protocol.txt" on the website, under "OTR Data".
There was an interesting talk by IBM researchers Agrawal, Rao and Rohatgi at the
CHES 2003 workshop two weeks back in Cologne.
They presented multi-channel attacks on just about any computing device that is not properly shielded, simply using an ordinary short wave radio receiver. They recorded the electromagnetic emissions on different frequency bands to determine the internal operations, and hence, bits of a secret encryption key.
For the demonstration they used a Palm handheld computing an Elliptic Curve signature and held the microphone next to the radio receiver. You could easily make out the different bleeps which correspond to the different EC Point operations.
They were also able to listen in on an SSL acceleration chip in one of their servers, from several feet away (outside on the parking lot). What worries me the most is, that they say that proper shielding is non-trivial, since EM escapes along the power lines.
Side-Channel attacks have been at the focus of research in Cryptography since 1996.
The security of ECC-160 is roughly equivalent to that of 1024 bits RSA. Imagine you want to check your bank account from your Palm and have to wait 4 minutes before the session can be established!
Interactive? I don't think so...
Of course: current PDAs are much faster, but still the complexity of RSA is so much higher than that of ECC. So, yes it is necessary.
Gunnar
Oh - and did I mention: RSA-512 was broken in 1999...:)
It turns out that they don't only support C64 and Amiga tunes, but also Atari, MSX, Nintendo, etc. I suppose it would be a little difficult maintaining a player that supports all of these different formats and their correct (!) emulation.
As I understand it, it's difficult enough to write a player for all the different Soundtracker formats, e.g. MOD/S3M/XM/OCT/...
The MP3 format just ensures that the music gets played as intended.
Slashdot Mirror
This is a debatable issue. The look-up table itself is hardware, but the masks for the table have been created with a perl script. Someone apparently just wanted to `clean up a minor bug' in that script after validation, without re-testing it. Turns out this minor bug caused the whole fdiv-bug issue. So you could equally well argue that it was a software bug causing a hardware bug.
Gunnar
Its their job to be detailed. You have to infer those reports and draw conclusions.
I disagree. If they call themselves "Security Consultants" they should provide a little more consulting than simply running Nessus and printing a report. Sometimes you have to wonder why companies have no problems doling out money to external consultants, when the quality of the result is questionable at best.
Randomized salt values are not necessary. AES is used in Counter Mode, i.e. acts like a stream cipher. The output of AES (key-stream) is XORed with the plaintext and thus forms the ciphertext.
Therefore, even if you use a lot of "LOL" and "whats up", it will always generate different ciphertexts. Also, if you don't want anybody to know the exact length of your message, simply "fill it up" with zeros. This is described in more detail in "Protocol.txt" on the website, under "OTR Data".
They presented multi-channel attacks on just about any computing device that is not properly shielded, simply using an ordinary short wave radio receiver. They recorded the electromagnetic emissions on different frequency bands to determine the internal operations, and hence, bits of a secret encryption key.
For the demonstration they used a Palm handheld computing an Elliptic Curve signature and held the microphone next to the radio receiver. You could easily make out the different bleeps which correspond to the different EC Point operations.
They were also able to listen in on an SSL acceleration chip in one of their servers, from several feet away (outside on the parking lot). What worries me the most is, that they say that proper shielding is non-trivial, since EM escapes along the power lines.
Side-Channel attacks have been at the focus of research in Cryptography since 1996.
Gunnar
The reason why it is still necessary can be easily seen from the following performance numbers (Handspring Visor, 16MHz):
RSA-512: ~30 secs/encryption
RSA-1024: ~240 secs/encryption
ECC-160: ~3 secs/encryption
The security of ECC-160 is roughly equivalent to that of 1024 bits RSA. Imagine you want to check your bank account from your Palm and have to wait 4 minutes before the session can be established! Interactive? I don't think so...
Of course: current PDAs are much faster, but still the complexity of RSA is so much higher than that of ECC. So, yes it is necessary.
Gunnar
Oh - and did I mention: RSA-512 was broken in 1999... :)
As I understand it, it's difficult enough to write a player for all the different Soundtracker formats, e.g. MOD/S3M/XM/OCT/... The MP3 format just ensures that the music gets played as intended.
Gunnar