Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!



Sequencing a Human Genome In a Week

bogado Re:Here's what I want to know... (101 comments)

Each person have a different sequence, while the first time they sequenced one of the billions "human genomes". Doing different people could help finding what makes one person different from another and on the other hand what make us similar. :-)

more than 5 years ago

Sequencing a Human Genome In a Week

bogado Diff? (101 comments)

While a single human genome is a lot of information, storing thousands shouldn't add much requirements, one can simply store a diff from the first.

more than 5 years ago

How Do You Greet an Extraterrestrial?

bogado Re:Squids (803 comments)

Also, if they show interest in contacting us in the first place, they would probably value us as a source of information, so destroying earth would be counter-productive. Think on how much money is spent on making sure that our probes would not contaminate with earth life the places that it visits.

more than 5 years ago

Flaw Made Public In OpenSSH Encryption

bogado Re:Good Thing (231 comments)

This is probably because no one uses it or care for it. Encryption is not a matter of simply slapping an encrypted channel on top of something and that something is magically secure.

Just on the top of my head I could bet that this telnet is vulnerable to timing attacks that ssh were once vulnerable. you see, telnet usually sends keys as fast as it can, so when you're typing your password the timing between the keys-down events are reflected on the timing of packages that go trough the net, with those timings you can narrow down the brute force password search.

SSH is more smart then telnet, so first it has a initial handshake that is not part of the session, so the first password, the login password, is sent in a single packet. But even for other password prompts that are asked during the session, openssh notice that the no-echo mode is activated and uses a timeout to join together more then one key on a single packet, since there is no echo this does not compromise the responsiveness of the session.

more than 5 years ago

Miscalculation Invalidates LHC Safety Assurances

bogado Re:My first thought from reading this (684 comments)

People used to believe that incantations could summon gods or demons (or what ever) that were able to destroy the world. The fact that those people believed that didn't make it more real.

The main argument to why the LHC will not destroy anything is very simple indeed. No machine human made collisions with that amount of energy don't mean that those don't happen naturally.

In fact collisions with even more energy happen naturally and frequently, it just happen that we don't have huge detectors to measure them when they happen.

more than 5 years ago

US-CERT Says Microsoft's Advice On Downadup Worm Bogus

bogado Re:Non-Windows User Here (290 comments)

No that is still windows fault, the user is used to click thousands of those cryptic little windows that appear whenever he has to do something. He doesn't even read them anymore.

A better solution is to ask the users password before installing stuff, those prompts are rare and give the user the impression that something potentially harmful is about to happen.

On the other hand, the system can not over use it, some versions of linux require that you enter your password even to change the system time for instance. This abuse of the password prompt can make users get used to them, and just like the warning dialogs they will get trained to enter the password on demand, without thinking.

more than 5 years ago

Will People Really Boycott Apple Over DRM?

bogado Re:It's optional! (664 comments)

I have never actually used itunes (I use linux), but every time I have to interact with it it only gave me head aches or stood in the way of doing something.

I use mainly ogg, not because I am an audiophilie, but because I believe in open source and free from patent formats. So maybe I am a "technology zealot" as the troll bellow ( said. But I am not a radical, I don't re-encode mp3s into ogg, nor I want to turn my ogg permanently into mp3, I am studding an alternate solution, I want to make the daapd server reencode on the fly when serving itunes and serve ogg streams to everyone else.

more than 5 years ago

Will People Really Boycott Apple Over DRM?

bogado Re:It's optional! (664 comments)

ITunes sucks it don't play ogg by default and it refuses to play ogg from the network even after the quicktime coded is installed. I have setted up a daap for my home and itunes simply does not work, while rythmbox work perfectly.

I also tried to configure songbird to see my daap, but had no luck, and my wife want something that is as easy as itunes.

Also I loved the "Dr. Horrible sing along blog" I tryed to buy the files from itunes, it is impossible, because you know you have to have a itunes installed, so one less sell.

ARGH I really hate itunes.

more than 5 years ago

Linux-Based E-Voting In Brazil

bogado Re:Science Fiction! (302 comments)

While I agree that our election is far from perfect, I don't think that pen & paper is the best solution. It introduces many more places where it can be frauded, the accounting, false ballots and much more. A unified electronic voting has many advantages and can be made more safe by adding cryptographic receipts, for instance.

I know that electronic voting can be hacked, but if you raise the bar too high it start to get impractical hacking. Compromising single units can be easy, but if it can be detected later the votes from that machine could be eliminated, so the roms would have to be swapped out after wise also, unless your objective is to create a dos on some ballots.

I trust the system now because of the results it have shown, not because of the system it self, I know it can be hacked, I don't know what the heck is running there, what I know is that it has been shown by the results.

more than 5 years ago

Linux-Based E-Voting In Brazil

bogado Re:The source code *is* available (302 comments)

The problem is that the system is not open. The more people have access to the source sode more secure it will be. The way it is today very few people have access to it and many if not all the people who have access to it have a direct interest in the result and by consequence in defrauding it.

If the code is secure why can't we look at it?

more than 5 years ago


bogado hasn't submitted any stories.



Variable length hashes

bogado bogado writes  |  more than 9 years ago

I propose a variable length hash, this would have an advantage over the current fixed sizes hash functions used today. As I see it the problem with fixed sized hashes is that the larger the size of the file the larger is the probability of a collision. Getting a lager hash for larger files reduces the possibility on this happening by making the number of possible hashes bigger for larger sets. Also since the growth of the hash size is variable, this makes it even harder to find a collision, since the data set would have to match not only the data but also the size of the hash.

How can we do it?

I am sure there is a number of ways of creating those variable length hashes, but I will describe here a simple idea I have, that can have holes but for a start I will shoot it here so the cryptographic community could check it out and scrutinize it, and maybe come with new ideas.

The principle is simple, I think that simplicity is very important since the most people that can understand something the more people can question and find problems with it. We start with a known secure hash function, after a predefined number of bits we would freeze a random number of bits of the internal state of the function, all of this would be in function of the internal state it self, so it could be repeated easily. The final hash would be simple all of the frozen bits collected during all stops appended with the usual hash. This approach would guaranty at least the same level of security of the original hash.

Other ways could be arranged so the methd could get somewhat stronger, for instance one could start two diferent hash functions one for the "extra bits" and the other for the finalization. But this would add some computation time.

Possible problems

The extra bits taken from the hash could help a attacker figure out the original message, in a password like environment for instance. For this hash to be really secure for cryptography uses the way the extra bits are chosen and how many of them must be carefully studied so that those do not give any tips on how they were chosen.

For this reason I would suggest that the internal state of the hashing function should be divided in two sets of bits, both with the same amount of information attached to them. So if some of the bits are more random then others in this particular hash, those bit should be divided by the two sets so the two final sets have the same amount of information in them. One of this set generates a number and the other generates the bits that would be frozen.

The other problem I can see is that the current protocols can have a fixed space for signatures and hashes. Those protocols should have to be adapted for using those hashes (if this proves to be actually secure). Also one could think in a way to summarize the extra bits and the size in a fixed sized, but this could make the hashes once again weak for larger data.

Also for this to be really secure at a higher size data, the amount of growth of the hash should be approximately linear. But this clearly would be too much since the hash would become too large and would hinder the transfer. So a rate of growth should be carefully chosen so the hashes don't get too big too soon, but they would also give enough security.

Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>