That's funny because I can't stand having to wait for every little thing to load before starting.
That's funny because I can't stand having to click the Start button over and over again, while waiting for every little thing to load before starting. Because, the Start menu bloody disappears before I can navigate to what I want to start.
XP's "fast booting" is nothing more than a trick to make people think that XP is indeed appreciably faster. It's something to help sell more Win XP. I find that between the time XP appears to be ready and when it is finished loading everything at startup, it is mostly useless.
You spend 8 hours or more actually using the computer, who cares whether it takes 15 seconds or 60 seconds to start? XP is for desktops, not flight control computers or some such.
I read in a local PC centric computer mag, that the new sync function requires a.Mac account. This seems absurd to me, especially considering that I and I'd imagine many others, would just want this functionality to sync my data between my Mac's and not a.Mac account. I don't have a.Mac account and I don't want one.
Can someone put my mind to rest on this? This is the biggest feature I am eagerly waiting for. I was going to just use rsync and some scripting, but if Apple has done this, then I imagine it will be much more polished than what I can whip up without a decent effort that results in something which lacks quirks.
The OpenBSD guys response was "Can't you read! I want documentation NOW or I'm going to take my OS and go home."
Documentation alone, should be easy to supply. Especially when it will go towards something so important to some Adaptec RAID users, for very little cost to Adaptec. Register level documentation should not reveal trade secrets. Hell, if it would, then those secrets could be gleaned from reverse engineering drivers and management binaries which are released, in which case Adaptec would be vulnerable any way.
The OpenBSD people have been trying for MONTHS. As far as I am concerned, hardware should always have documentation available to allow programming it. Especially when that hardware is specifically built for protection of data.
I will not buy any more Adaptec products until they release the documentation. It seems to me that other hardware RAID engine makers have an opportunity to "strike while the iron is hot" and milk this current point of contention while it is still news. Release their docs and become the first OSS hardware RAID friendly company. Because, I may have missed something in my use of OpenBSD since 2.5, but I believe that there is NO documentation freely available (non-NDA) for RAID management consoles for ANY of the RAID cards which OpenBSD supports. If this is the case, then I imagine it would also mean that there is NO freely available documentation for Linux use either.
That is pretty sad. What if a companies binary software ceases to work after a major change in some OSS software and that vendor will no longer supply a new updated binary because they have a newer product out? Documentation would not allow this problem. What about use with architectures outside of x86? How supported are these drivers going to be on UltraSPARC or macppc? Will they work under NetBSD or OpenBSD? Documentation would not allow these problems.
Documentation allows the vendors to wash their hands of these issues. It allows them to pass the support buck to someone else. It's a quick small expense to provide documentation which would allow the OSS people to support themselves. What good is the in-BIOS configuration and management software on these cards if I'm not running them in and thus executing them on, an x86. What good are the bootable management CDROM's if they only do x86 and I'm on UltraSPARC or macppc? I shouldn't have to buy a card for a particular arch and OS. Documentation is the key to supporting and thus gaining from this exploding market.
It's not just OpenBSD. It's open source operating systems and software in general which stand to gain from hardware which is open enough to properly program for and thus any hardware vendors smart enough to see this stand to gain also.
driving their formerly faithful resellers out of the market with their well know price fixing strategies (try buying apple hardware at better prices than Apple supply it direct to see what I mean).
I purchased a Mac mini a week or two ago in Sydney Australia. Apple online store quoted about $1560, yet I picked up the same configuration from Nextbyte for $1300. Nextbyte also got it to me in two days, versus Apple's waiting time of nearly two weeks for my configuration.
G4 1.67GHz, 1GB DDR RAM, 80GB HDD, Combo drive, Apple wired mouse and keyboard.
What big corporation are not a bunch of bastards? ; )
I know, that's why I stated "all other things...". To simplify this hypothetical question.
Saving money or putting that money to another area of the machine is what matters to me. Save on CPU, get a better GPU. That's a happier me.
I remember when AMD was crap all because of the shitty available chipsets, but now things seem to be fine. I've never had trouble with nForce chipsets.
I don't argue that Intel has closed the gap, it just seems to me that their latest attempt to perhaps surpass has not been good enough. People will point at benchmarks and say that AMD is still faster and that is what matters. Before Intel can go quicker... AMD will have released their next CPU that raises the bar further out of Intels reach.
For a long while they were neck and neck, leapfrogging each other. But now it seems that they are leapfrogging themselves as they rarely get close enough to overlap. If the trend continues without any major enhancement to Intel's line, I think Intel will lag too much and start to move away from CPU's. As another has stated, Intel gets a good boost from HT, but once real multi-cores are common, that advantage will disappear. Unless of course Intel can make HT and multi-core work at once to their advantage.
If AMD continues to get better and the likes of Dell and Gateway have to switch to AMD, Intel might be in serious danger.
Last time I looked (just now!), Intel processors are only $20-40 more expensive than comparable AMD processors. The big price difference isn't so big anymore.
If the two latest Intel and AMD CPU's are both $100, but the AMD is 10% faster, which are you going to buy? All other things being equal?
Now make that situation worse by making the slower CPU more expensive by ANY amount.
Money is money. Who would knowingly choose less for more?
While I agree with you that Intel is playing catch-up in the desktop 64-bit arena, if you had RTFA then you would have found that it concludes with a performance summary that suggests that Intel's 64-bit CPUs more than hold their own:
You complain that the parent should have RTFA, then you quote a subjective summary.
I did RTFA and found that the AMD was almost always faster. This has been the case for a long time and when Intel does pull ahead, it is short lived. You mention that Intel is just coming to market with these offerings and AMD's comparitive offering has been here for a long while. So why do you not see that even with that being the case, the AMD is still faster! Intel brings out a new CPU, which is mostly slower than an AMD CPU which has been on the market for a while, but you accept that "Intel hold their own"?
Have you not noticed that Intel's speed ramping has slowed terribly over the last few YEARS!?
The parent said, "I wonder how long consumer will pay a premium for slower Intel CPUs". What was wrong with that? Intel CPU's do tend to be slower and more expensive than AMD CPU's. I would also wonder how long people will continue to accept less for more.
Now, I have no doubt that Intel's 64-bit offerings will fall behind their AMD equivalents when it comes to bang-per-buck but that conclusion seems to suggest that Intel's chips will still have plenty of bang, as much as if not more than AMD's chips.
I did not see anywhere in that article, anything that could suggest, outside perhaps of some vague guessing, that Intel will pull ahead of AMD.
If it matters... I run G3, G4, AMDXP, AMD Thunderbird, PIII, PII and UltraSPARC IIi. Soon however, I would also like to run Opteron and G5. As far as I am concerned, Intel is dead in the water. I certainly am avoiding their products because I can do better for whatever money I am willing to put down.
For a router/server machine the firewall effectivly blocks all incoming packets.
If that is how it is configured. Don't you mean incoming packets which are not expected? As in, incoming packets which do not belong in something like a state table, etc? If I want an effective "firewall" that "blocks all incoming packets", I'll just unplug that machine from the network interfaces.
If your users are stupid enough to download and run crapware that is something else.
My curiosity is with you saying that XP's built-in firewall is one of the best.
Being an OpenBSD + pf user and also using various 3rd party software firewalls for MS Windows, where I have to (Windows), I find it a little odd that someone thinks that the built in firewall is "one of the best".
I have no firewall, or router. I'm running XP SP1. And I've never had a single problem
Maybe you have plenty of problems but you are not aware of it? My dedicated OpenBSD pf firewall shows that my IP gets scanned for Windows vulnerabilities at least once every few minutes.
I find your story very hard to believe. You don't have a NAT gateway?
I always build my own home systems, and I refuse to let another company make hardware choices for me.
I've been building PC's for about 15 years. Now though, it is more economical to buy systems which are already built. Unless you are trying to get the absolute fastest PC you can get your hands on, in which case, I find building from parts to often be cheaper.
You do have choice though and as you've stated, you are exercising it. You don't have to buy Apple hardware or their software. Apple gets a lot of stability and excellent interoperability through the fact that they largely control both the software and hardware that makes up their systems.
Apple systems are for people who just want to buy a computer which works very well out of the box. That is why Apple does the "choosing". They deliver on that expectation and that is why Mac users tend to remain Mac users. Who wants to lay down cash on systems which you have to fight with to use (MS)?
You must remember that Apple delivers the whole system. They are not delivering a generic OS to go with someone elses highly variable hardware and drivers. To achieve that, they need to limit what hardware they ship. I don't see that as them controlling you, but rather them controlling the quality of the systems they deliver you.
PS, I am predominently an OpenBSD and NetBSD user who has OSX on an old clamshell iBook. I recently ordered a Mac mini because I love using OSX too. I don't fight with OpenBSD or NetBSD, since once I set them up, they just keep going. They're not as pretty as OSX though. ; ) Microsoft products though, give me no end of grief.
Hopefully, this will mean a lot more people buying one of these and using something like this, this, this, this or this!
Seriously. Why on Earth are people still putting up with these MS fuckers when Mac OSX and Apple hardware is so damn nice? I like a mix of Sun and Apple gear. The thought of actually deciding on MS just makes me shudder. And MS just keeps giving me more and more reason to hate them and the shit they peddle.
The width of hash has little to do with the probability of a collision by an attacker.
If a hash algorithm attains true maximal strength to it's message digest bit depth, then it has everything to do with the probability of finding a collision.
If you can pass an infinite combination of a data set which can have an infinite size, through an algorithm which will reduce that to a fixed message digest, then there will ALWAYS be collisions. An infinite number in fact.
The "probability of a collision" is meaningless in this context. It would be meaningful if you wrote "the probability of finding a collision". The bit depth is meaningful if the algorithm attains maximal strength. Knowing if that is really the case, is very difficult with complex algorithms of any great strength.
It is not possible to uniquely represent the full bit space allowed by 2 bits with a digest of 1 bit. 50% of the values will collide if the algorithm used attains maximal strength.
With modern hashing algorithms and a finite amount of data of sizes typically used, it is not like finding a needle in a haystack. It is like find one of a trillion needles in a haystack the size of our Earth.
This is, for all intents and purposes, "impossible", and thus the hash is effectively collision-free.
From what you have written, I gather you already agree with this. But I'll state this to ellaborate on what you've written and if not maybe it will spark discussion...
Collision-free? No. Not even effectively.
Extremely difficult to infeasible to find any one of the infinite number of possible collisions? Yeah, sure. But this does not make it collision free. A collision does not just suddenly exist once it is found by a human or machine. It always existed within the realm of mathematics. The difficulty is in the finding.
A good hashing algorithm will have maximal strength possible by it's intended design. A weaker one will allow more collisions than the design should have allowed. Regardless of how strong a hashing algorithm is intended to be or is in reality, they ALL will exhibit an infinite number of collisions.
Sorry to be so literal, but I think it is important to adhere to definitions, lest they be forgoten after being loosely used. No hashing algorithm is "effectively collision-free". Effectively impossible to find a collision, maybe.
Taken literally your post is interesting, because the first and second sentence of your second paragraph might have been commonly accepted a few weeks ago if regarding SHA-1. But your third paragraph is closer to the reality today, yet one speaks of thousands of years and the other a reasonable amount of time! The problem here is that people think something like "160 bits", do the quick math and then proclaim of the extreme strength, because they assume maximal strength. The reality is that an error prone human or group of humans designed these algorithms with typical animal creativity. Animal creativity gets further and further from mathematical perfection as complexity becomes greater.
Hashing algorithms are very complex, by typical standards and it took all this time for SHA-1 to be found weaker than first believed. The real weakness, is not the algorithms, it's the people designing them and people relying on them to be maximal strength. It's a difficult situation, because few people are gifted or knowledgable enough to know better, so the common man must reach a point where the line into faith must be crossed. ; )
Creating pseudo-random numbers that hash to the same value != making any arbitrary document hash to the same value.
I agree, however what sort of document are we talking about here?
Plain text? Okay, that would be super difficult to do without padding with gibberish.
A bitmap image of a faxed document? Easy with all those random noise bits.
A document which allows and has embedded images? Easy, make the required changes within the least significant bits of the images.
etc etc etc.
I will stick to signing plain text only thank you very much.
The findings are that SHA-1 is not collision free
on
More on Newly Broken SHA-1
·
· Score: 2, Interesting
The findings are that SHA-1 is not collision free
NO hash algorithm which is capable of reducing an arbitrary number of bits to a smaller message digest, is ever going to be collision free when the input is larger than the digest. Ever.
The difficulty is normally in finding a collision, whether through brute force or algorithmically.
It would be possible to design a hash algorithm to have no collisions with input of a length smaller than or equal to the message digest. But that is of pretty limited use when we're talking about lengths like 160 bits.
Re:Not a problem (yet)
on
SHA-1 Broken
·
· Score: 1
nitpick: You can't get the original back out. Data is lost in the hash function - it's not compression. You can determine a set of possibilities for the original, but never what the actual original was.
I should have been more verbose. I'm well aware that there will be many collisions. I should have added that finding the original is extraordinarily difficult and knowing you have found the original (as opposed to an equivalent) is impossible.
Re:Not a problem (yet)
on
SHA-1 Broken
·
· Score: 4, Insightful
You have a bit of a logic flaw in your comment.
Maybe you don't realise where he is coming from.
With a digital signature, you can easily have knowledge of the signed message (input to message digest function) and thus change the message while retaining the signature.
With a hashed password, you don't have access to the password (input to message digest function).
The hashed password would require figuring out the password so as to allow changing it to make the same hash. This requires going the wrong way against this one way hash algorithm. If you were able to do this, then you would not bother generating an equivalent password, because you would know the original.
I think the point is, that the one way nature of SHA-1 might still be strong. Meaning digital signatures are weak, but hashed passwords are not.
Effective DDoS is going to be machine gunned UDP packets which expect no reply and will typically forge the source IP anyway, from many thousands of machines.
Connection tracking a connectionless protocol?
How do you throttle a single UDP packet that suddenly appears at your external interface?
Think it through please. This is a common trap that people fall into and end up in firewall lists requesting help on doing it, only to be told that it can't be done.
Look...
1. Someone sends a single UDP packet to your IP.
2. It arrives at your external interface, you "track" it.
It wasted a packet of bandwidth, but that's okay because you're tracking it now right?
3. They send another single packet to your IP.
4. It arrives at your external interface, you know it's bogus (because you are tracking it afterall!), so you're firewall/OS drops it.
It got to your external interface again! It wasted another packet of your external pipe to the internet! An external pipe, which I would like to remind you, has a finite width. But you were tracking it! WTF!? Okay, so your firewall/OS may have dropped it this time, instead of politely replying. They still wasted another packet on the way in and there was not a god damned thing you could do about it at your end.
Got the picture now?
Now multiply those packets by a couple of million per second (lots of the smallest UDP packets they can craft) from thousands of hosts which you are never going to be able to respond to.
Good luck. You are going to need it. Because there IS NO OTHER SOLUTION TO THIS PROBLEM other than 1. having a pipe that is fatter than the deluge or 2. going upstream where the pipes are much fatter than yours and dealing with it there.
If I can fully saturate your incoming external bandwidth, you won't be using a whole lot of it or your outgoing. Unless of course you feel the need at that stage to machine gun fire off your own UDP packets (which could be nice, if you knew where the other UDP packets were coming from, but alas, you don't, they're forged.)
If avoiding these DDOS attacks were easy they wouldn't be newsworthy. Unfortunately it's anything but a simple problem.
Exactly. If the internet provider is not willing or sufficiently capable of helping, then it is an impossible problem.
You can't save the incoming bandwidth, because you don't know what a packet is until it has already consumed that bandwidth.
Your upstream provider could help on a short term basis, but it would take a while (longer term) to implement something which works. In which case if it becomes a long term problem for you and your upstream provider, then they will be dealing with much more used bandwidth than you were willing to purchase in the first place. So why should the provider help in the long term?
Copernic's Privacy Policy reveals that, "Copernic Technologies, Inc. works with third parties that transmit advertisements to the Copernic Agent and Copernic Desktop Search product families and Copernic Meta."
Slashdot Mirror
a massive mouse mat.
That's funny because I can't stand having to wait for every little thing to load before starting.
That's funny because I can't stand having to click the Start button over and over again, while waiting for every little thing to load before starting. Because, the Start menu bloody disappears before I can navigate to what I want to start.
XP's "fast booting" is nothing more than a trick to make people think that XP is indeed appreciably faster. It's something to help sell more Win XP. I find that between the time XP appears to be ready and when it is finished loading everything at startup, it is mostly useless.
You spend 8 hours or more actually using the computer, who cares whether it takes 15 seconds or 60 seconds to start? XP is for desktops, not flight control computers or some such.
Its far more than a point release
.Mac account. This seems absurd to me, especially considering that I and I'd imagine many others, would just want this functionality to sync my data between my Mac's and not a .Mac account. I don't have a .Mac account and I don't want one.
I read in a local PC centric computer mag, that the new sync function requires a
Can someone put my mind to rest on this? This is the biggest feature I am eagerly waiting for. I was going to just use rsync and some scripting, but if Apple has done this, then I imagine it will be much more polished than what I can whip up without a decent effort that results in something which lacks quirks.
The OpenBSD guys response was "Can't you read! I want documentation NOW or I'm going to take my OS and go home."
Documentation alone, should be easy to supply. Especially when it will go towards something so important to some Adaptec RAID users, for very little cost to Adaptec. Register level documentation should not reveal trade secrets. Hell, if it would, then those secrets could be gleaned from reverse engineering drivers and management binaries which are released, in which case Adaptec would be vulnerable any way.
The OpenBSD people have been trying for MONTHS. As far as I am concerned, hardware should always have documentation available to allow programming it. Especially when that hardware is specifically built for protection of data.
I will not buy any more Adaptec products until they release the documentation. It seems to me that other hardware RAID engine makers have an opportunity to "strike while the iron is hot" and milk this current point of contention while it is still news. Release their docs and become the first OSS hardware RAID friendly company. Because, I may have missed something in my use of OpenBSD since 2.5, but I believe that there is NO documentation freely available (non-NDA) for RAID management consoles for ANY of the RAID cards which OpenBSD supports. If this is the case, then I imagine it would also mean that there is NO freely available documentation for Linux use either.
That is pretty sad. What if a companies binary software ceases to work after a major change in some OSS software and that vendor will no longer supply a new updated binary because they have a newer product out? Documentation would not allow this problem. What about use with architectures outside of x86? How supported are these drivers going to be on UltraSPARC or macppc? Will they work under NetBSD or OpenBSD? Documentation would not allow these problems.
Documentation allows the vendors to wash their hands of these issues. It allows them to pass the support buck to someone else. It's a quick small expense to provide documentation which would allow the OSS people to support themselves. What good is the in-BIOS configuration and management software on these cards if I'm not running them in and thus executing them on, an x86. What good are the bootable management CDROM's if they only do x86 and I'm on UltraSPARC or macppc? I shouldn't have to buy a card for a particular arch and OS. Documentation is the key to supporting and thus gaining from this exploding market.
It's not just OpenBSD. It's open source operating systems and software in general which stand to gain from hardware which is open enough to properly program for and thus any hardware vendors smart enough to see this stand to gain also.
driving their formerly faithful resellers out of the market with their well know price fixing strategies (try buying apple hardware at better prices than Apple supply it direct to see what I mean).
I purchased a Mac mini a week or two ago in Sydney Australia. Apple online store quoted about $1560, yet I picked up the same configuration from Nextbyte for $1300. Nextbyte also got it to me in two days, versus Apple's waiting time of nearly two weeks for my configuration.
G4 1.67GHz, 1GB DDR RAM, 80GB HDD, Combo drive, Apple wired mouse and keyboard.
What big corporation are not a bunch of bastards? ; )
Good point. But all other things are not equal.
I know, that's why I stated "all other things...". To simplify this hypothetical question.
Saving money or putting that money to another area of the machine is what matters to me. Save on CPU, get a better GPU. That's a happier me.
I remember when AMD was crap all because of the shitty available chipsets, but now things seem to be fine. I've never had trouble with nForce chipsets.
I don't argue that Intel has closed the gap, it just seems to me that their latest attempt to perhaps surpass has not been good enough. People will point at benchmarks and say that AMD is still faster and that is what matters. Before Intel can go quicker... AMD will have released their next CPU that raises the bar further out of Intels reach.
For a long while they were neck and neck, leapfrogging each other. But now it seems that they are leapfrogging themselves as they rarely get close enough to overlap. If the trend continues without any major enhancement to Intel's line, I think Intel will lag too much and start to move away from CPU's. As another has stated, Intel gets a good boost from HT, but once real multi-cores are common, that advantage will disappear. Unless of course Intel can make HT and multi-core work at once to their advantage.
If AMD continues to get better and the likes of Dell and Gateway have to switch to AMD, Intel might be in serious danger.
Last time I looked (just now!), Intel processors are only $20-40 more expensive than comparable AMD processors. The big price difference isn't so big anymore.
If the two latest Intel and AMD CPU's are both $100, but the AMD is 10% faster, which are you going to buy? All other things being equal?
Now make that situation worse by making the slower CPU more expensive by ANY amount.
Money is money. Who would knowingly choose less for more?
While I agree with you that Intel is playing catch-up in the desktop 64-bit arena, if you had RTFA then you would have found that it concludes with a performance summary that suggests that Intel's 64-bit CPUs more than hold their own:
You complain that the parent should have RTFA, then you quote a subjective summary.
I did RTFA and found that the AMD was almost always faster. This has been the case for a long time and when Intel does pull ahead, it is short lived. You mention that Intel is just coming to market with these offerings and AMD's comparitive offering has been here for a long while. So why do you not see that even with that being the case, the AMD is still faster! Intel brings out a new CPU, which is mostly slower than an AMD CPU which has been on the market for a while, but you accept that "Intel hold their own"?
Have you not noticed that Intel's speed ramping has slowed terribly over the last few YEARS!?
The parent said, "I wonder how long consumer will pay a premium for slower Intel CPUs". What was wrong with that? Intel CPU's do tend to be slower and more expensive than AMD CPU's. I would also wonder how long people will continue to accept less for more.
Now, I have no doubt that Intel's 64-bit offerings will fall behind their AMD equivalents when it comes to bang-per-buck but that conclusion seems to suggest that Intel's chips will still have plenty of bang, as much as if not more than AMD's chips.
I did not see anywhere in that article, anything that could suggest, outside perhaps of some vague guessing, that Intel will pull ahead of AMD.
If it matters... I run G3, G4, AMDXP, AMD Thunderbird, PIII, PII and UltraSPARC IIi. Soon however, I would also like to run Opteron and G5. As far as I am concerned, Intel is dead in the water. I certainly am avoiding their products because I can do better for whatever money I am willing to put down.
For a router/server machine the firewall effectivly blocks all incoming packets.
.
If that is how it is configured. Don't you mean incoming packets which are not expected? As in, incoming packets which do not belong in something like a state table, etc? If I want an effective "firewall" that "blocks all incoming packets", I'll just unplug that machine from the network interfaces.
If your users are stupid enough to download and run crapware that is something else.
My curiosity is with you saying that XP's built-in firewall is one of the best
Being an OpenBSD + pf user and also using various 3rd party software firewalls for MS Windows, where I have to (Windows), I find it a little odd that someone thinks that the built in firewall is "one of the best".
I have no firewall, or router. I'm running XP SP1. And I've never had a single problem
Maybe you have plenty of problems but you are not aware of it? My dedicated OpenBSD pf firewall shows that my IP gets scanned for Windows vulnerabilities at least once every few minutes.
I find your story very hard to believe. You don't have a NAT gateway?
There would be nothing wrong if that box was a Windows box. The built-in firewall is one of the best
Are you serious?
Reminds me of starving dogs staring at a cat through a chain-link fence waiting for the gate to open.
You must be refering to OpenBSD! If only those dogs could understand human language, we could tell them that those gates will never be opened. ; )
I always build my own home systems, and I refuse to let another company make hardware choices for me.
I've been building PC's for about 15 years. Now though, it is more economical to buy systems which are already built. Unless you are trying to get the absolute fastest PC you can get your hands on, in which case, I find building from parts to often be cheaper.
You do have choice though and as you've stated, you are exercising it. You don't have to buy Apple hardware or their software. Apple gets a lot of stability and excellent interoperability through the fact that they largely control both the software and hardware that makes up their systems.
Apple systems are for people who just want to buy a computer which works very well out of the box. That is why Apple does the "choosing". They deliver on that expectation and that is why Mac users tend to remain Mac users. Who wants to lay down cash on systems which you have to fight with to use (MS)?
You must remember that Apple delivers the whole system. They are not delivering a generic OS to go with someone elses highly variable hardware and drivers. To achieve that, they need to limit what hardware they ship. I don't see that as them controlling you, but rather them controlling the quality of the systems they deliver you.
PS, I am predominently an OpenBSD and NetBSD user who has OSX on an old clamshell iBook. I recently ordered a Mac mini because I love using OSX too. I don't fight with OpenBSD or NetBSD, since once I set them up, they just keep going. They're not as pretty as OSX though. ; ) Microsoft products though, give me no end of grief.
Hopefully, this will mean a lot more people buying one of these and using something like this, this, this, this or this!
Seriously. Why on Earth are people still putting up with these MS fuckers when Mac OSX and Apple hardware is so damn nice? I like a mix of Sun and Apple gear. The thought of actually deciding on MS just makes me shudder. And MS just keeps giving me more and more reason to hate them and the shit they peddle.
The width of hash has little to do with the probability of a collision by an attacker.
If a hash algorithm attains true maximal strength to it's message digest bit depth, then it has everything to do with the probability of finding a collision.
If you can pass an infinite combination of a data set which can have an infinite size, through an algorithm which will reduce that to a fixed message digest, then there will ALWAYS be collisions. An infinite number in fact.
The "probability of a collision" is meaningless in this context. It would be meaningful if you wrote "the probability of finding a collision". The bit depth is meaningful if the algorithm attains maximal strength. Knowing if that is really the case, is very difficult with complex algorithms of any great strength.
It is not possible to uniquely represent the full bit space allowed by 2 bits with a digest of 1 bit. 50% of the values will collide if the algorithm used attains maximal strength.
With modern hashing algorithms and a finite amount of data of sizes typically used, it is not like finding a needle in a haystack. It is like find one of a trillion needles in a haystack the size of our Earth.
This is, for all intents and purposes, "impossible", and thus the hash is effectively collision-free.
From what you have written, I gather you already agree with this. But I'll state this to ellaborate on what you've written and if not maybe it will spark discussion...
Collision-free? No. Not even effectively.
Extremely difficult to infeasible to find any one of the infinite number of possible collisions? Yeah, sure. But this does not make it collision free. A collision does not just suddenly exist once it is found by a human or machine. It always existed within the realm of mathematics. The difficulty is in the finding.
A good hashing algorithm will have maximal strength possible by it's intended design. A weaker one will allow more collisions than the design should have allowed. Regardless of how strong a hashing algorithm is intended to be or is in reality, they ALL will exhibit an infinite number of collisions.
Sorry to be so literal, but I think it is important to adhere to definitions, lest they be forgoten after being loosely used. No hashing algorithm is "effectively collision-free". Effectively impossible to find a collision, maybe.
Taken literally your post is interesting, because the first and second sentence of your second paragraph might have been commonly accepted a few weeks ago if regarding SHA-1. But your third paragraph is closer to the reality today, yet one speaks of thousands of years and the other a reasonable amount of time! The problem here is that people think something like "160 bits", do the quick math and then proclaim of the extreme strength, because they assume maximal strength. The reality is that an error prone human or group of humans designed these algorithms with typical animal creativity. Animal creativity gets further and further from mathematical perfection as complexity becomes greater.
Hashing algorithms are very complex, by typical standards and it took all this time for SHA-1 to be found weaker than first believed. The real weakness, is not the algorithms, it's the people designing them and people relying on them to be maximal strength. It's a difficult situation, because few people are gifted or knowledgable enough to know better, so the common man must reach a point where the line into faith must be crossed. ; )
Since when is it possible to have a collision free hash when the hashed data has more possibile bit combinations than the hash itself?
Genuine question.
Genuine answer.
But I'll need to slightly modify your question to answer what I think you are really asking...
"Since when is it possible to have a collision free hash algorithm when the hashed data has more possibile bit combinations than the hash itself?
Never, ever. Unless you are considering only a finite list which won't generate any collision and ignoring those that will (an infinite list).
; )
Creating pseudo-random numbers that hash to the same value != making any arbitrary document hash to the same value.
I agree, however what sort of document are we talking about here?
Plain text? Okay, that would be super difficult to do without padding with gibberish.
A bitmap image of a faxed document? Easy with all those random noise bits.
A document which allows and has embedded images? Easy, make the required changes within the least significant bits of the images.
etc etc etc.
I will stick to signing plain text only thank you very much.
The findings are that SHA-1 is not collision free
NO hash algorithm which is capable of reducing an arbitrary number of bits to a smaller message digest, is ever going to be collision free when the input is larger than the digest. Ever.
The difficulty is normally in finding a collision, whether through brute force or algorithmically.
It would be possible to design a hash algorithm to have no collisions with input of a length smaller than or equal to the message digest. But that is of pretty limited use when we're talking about lengths like 160 bits.
nitpick: You can't get the original back out. Data is lost in the hash function - it's not compression. You can determine a set of possibilities for the original, but never what the actual original was.
I should have been more verbose. I'm well aware that there will be many collisions. I should have added that finding the original is extraordinarily difficult and knowing you have found the original (as opposed to an equivalent) is impossible.
You have a bit of a logic flaw in your comment.
Maybe you don't realise where he is coming from.
With a digital signature, you can easily have knowledge of the signed message (input to message digest function) and thus change the message while retaining the signature.
With a hashed password, you don't have access to the password (input to message digest function).
The hashed password would require figuring out the password so as to allow changing it to make the same hash. This requires going the wrong way against this one way hash algorithm. If you were able to do this, then you would not bother generating an equivalent password, because you would know the original.
I think the point is, that the one way nature of SHA-1 might still be strong. Meaning digital signatures are weak, but hashed passwords are not.
There is no logic flaw in his comment.
1 and 2: connection tracking
3: throttling.
simple, uh?
Effective DDoS is going to be machine gunned UDP packets which expect no reply and will typically forge the source IP anyway, from many thousands of machines.
Connection tracking a connectionless protocol?
How do you throttle a single UDP packet that suddenly appears at your external interface?
Think it through please. This is a common trap that people fall into and end up in firewall lists requesting help on doing it, only to be told that it can't be done.
Look...
1. Someone sends a single UDP packet to your IP.
2. It arrives at your external interface, you "track" it.
It wasted a packet of bandwidth, but that's okay because you're tracking it now right?
3. They send another single packet to your IP.
4. It arrives at your external interface, you know it's bogus (because you are tracking it afterall!), so you're firewall/OS drops it.
It got to your external interface again! It wasted another packet of your external pipe to the internet! An external pipe, which I would like to remind you, has a finite width. But you were tracking it! WTF!? Okay, so your firewall/OS may have dropped it this time, instead of politely replying. They still wasted another packet on the way in and there was not a god damned thing you could do about it at your end.
Got the picture now?
Now multiply those packets by a couple of million per second (lots of the smallest UDP packets they can craft) from thousands of hosts which you are never going to be able to respond to.
Good luck. You are going to need it. Because there IS NO OTHER SOLUTION TO THIS PROBLEM other than 1. having a pipe that is fatter than the deluge or 2. going upstream where the pipes are much fatter than yours and dealing with it there.
If I can fully saturate your incoming external bandwidth, you won't be using a whole lot of it or your outgoing. Unless of course you feel the need at that stage to machine gun fire off your own UDP packets (which could be nice, if you knew where the other UDP packets were coming from, but alas, you don't, they're forged.)
If avoiding these DDOS attacks were easy they wouldn't be newsworthy. Unfortunately it's anything but a simple problem.
Exactly. If the internet provider is not willing or sufficiently capable of helping, then it is an impossible problem.
You can't save the incoming bandwidth, because you don't know what a packet is until it has already consumed that bandwidth.
Your upstream provider could help on a short term basis, but it would take a while (longer term) to implement something which works. In which case if it becomes a long term problem for you and your upstream provider, then they will be dealing with much more used bandwidth than you were willing to purchase in the first place. So why should the provider help in the long term?
Copernic's Privacy Policy reveals that, "Copernic Technologies, Inc. works with third parties that transmit advertisements to the Copernic Agent and Copernic Desktop Search product families and Copernic Meta."
It's called Mac OS X Tiger.
Actually, it is called Spotlight.
Which will be a part of Tiger, the latest upcoming version of Mac OSX.