I was wondering, how safe are HUBfiles? Say, if I wanted to have a certian file put on the HUB(Lets say, a sword piece or something) so a user could load it when they wanted.
Is it not possible for them just to make duplicates?
ID:136583
 Jul 30 2002, 12:29 pm
|
|
Sariat wrote:
And I'm supposed to do that with my 0% Knowledge of HUBfiles. Yes, of course. I have no knowledge of them either. =P | |
I doubt you have to be a million-dollar company to decrypt the file. Just a hacker with a lot of time on his hands *cough* me *cough*.
I've never tried Hubfiles. So I'm probably talking junk here, but surely you could just edit the hubfile if you had enough access to copy it in the first place. All this conversation reminds me to get the hubfiles demo/libary for my new game... Da_Very_Bored_Rushyo | |
I have a feeling you're not really familiar with encryption in any way.. Mathematically speaking, you have to (on average) have several months of time to break any decent encryption, and that's on rather fast computers.
-AbyssDragon | |
Da_Rushyo wrote:
I doubt you have to be a million-dollar company to decrypt the file. Just a hacker with a lot of time on his hands *cough* me *cough*. Lol, I bet, i bet. I've never tried Hubfiles. So I'm probably talking junk here, but surely you could just edit the hubfile if you had enough access to copy it in the first place. Lol All this conversation reminds me to get the hubfiles demo/libary for my new game... You's a funny person there. RaeKwon | |
AbyssDragon wrote:
I have a feeling you're not really familiar with encryption in any way.. Mathematically speaking, you have to (on average) have several months of time to break any decent encryption, and that's on rather fast computers. ...And when your budget gets really big, it's not only fast computers, it's footwork. Air Mapster: "Hello?" Agent: "FBI! Put your hands above your head!" Air Mapster: "Agh! Ah! OK! Don't shoot me!" Agent: "Now! Answer me! What is the encryption code for ShapeShifter?!" Air Mapster: "...Er, what?! Why on Earth do you want to know that?!" Agent: "I ask the questions around here! Don't make me pull the trigger!" | |
Depends on how you encrypt it :p. I can't see ingenious encryptions coming from most of the coders on BYOND (the very same people whos skills are limited to DBZ game rips).
| |
Spuzzum wrote:
AbyssDragon wrote: LOL! | |
I believe AirMapster's encryption demo uses RC5 encryption (something like that, anyway. :P ) If memory serves, that's the same kind of encryption which is used for credit card transactions online. Trust me, it's secure! :P
| |
Crispy wrote:
I believe AirMapster's encryption demo uses RC5 encryption (something like that, anyway. :P ) If memory serves, that's the same kind of encryption which is used for credit card transactions online. Trust me, it's secure! :P It is actually quite secure. The problem is people who use dirty tricks, like having promiscuous programs that sniff out the encryption key for a particular session, or full-fledged programs that hijack a connection and force all data going through it to run through a packet sniffer, or even just faked front-ends where people enter their credit card information into an irreputable site. The encryption algorithm is nearly impossible to break (at 128-bit, we're talking literally thousands of years for a single person), but the encryption code has to be sent on its own, or hard-coded into the protocol or program. It's a lot easier to reverse engineer a program or protocol to find the encryption code than it is to break an encryption outright. | |
Yep, quite literally. And, by that time, the information would be obsolete and useless (although maybe some future historians would find intrigue in learning about 21st century tax records).
Technically, it wouldn't take thousands of years because technology is constantly improving, but as technology constantly improves, the number of bits used for encryption steadily increases. There's already 256 bit and even 512 bit encryption, with some government applications done in 1024 bit encryption. In a few more decades, I wouldn't doubt if there were megabit or even gigabit encryptions, which would take billions upon billions of years to decrypt. | |
Spuzzum wrote:
In a few more decades, I wouldn't doubt if there were megabit or even gigabit encryptions, which would take billions upon billions of years to decrypt. Now THAT is just over the top. :) Isn't 128 bit good enough for you people? :P | |
Spuzzum wrote:
In a few more decades, I wouldn't doubt if there were megabit or even gigabit encryptions, which would take billions upon billions of years to decrypt. Actually, with current hardware, it would take a single processor in the neighborhood of a few hundred trillion years or more to recover a 128-bit key for a good symmetric encryption algorithm. A random brute force attack is about the most ideal algorithm for parallelization, but even if we put every computer on the planet to work at the problem, it will be at least a few hundred thousand years (assuming several hundred million computers on the planet). Now there are hardware-based machines that can try keys at least a few orders of magnitude faster than a general purpose CPU, but these are very expensive and generally only available to such agencies as the NSA (and nobody outside that organization really knows what they are capable of). And of course progress will march on, delivering more powerful computers, but generally not at nearly a rate needed to attack such encryption in any reasonable time. Remember, each added bit effectively doubles the available key space, and therefore doubles the average time to recover a key by brute force. With current mathematics and electronics, I'm guessing anything above 256 bits is complete overkill for symmetric encryption. 128 is likely to be far more than enough in most cases as it is. Of course, if someone comes up with a brilliant new mathematical solution that recovers any key length in constant time, then it's back to the drawing board for encryption as we know it! Or if quantum computing ever becomes a reality and delivers on some of its predicted (or hoped?) promises. One last point - asymmetric, or public key encryption uses different key lengths. In general (but this is always specific to each algorithm) a 2048 bit key is desirable for asymmetric encryption and offers roughly the same level of security as a 128 bit key does in symmetric encryption. The rest depends on how vigilant you and your associates are about protecting the key(s), and how much time and resources your attacker has to brute force keys. At the rate I'm going, I'll have my second BYONDscape encryption article ready about the time someone brute forces my contest from the first. ;-) | |
Technically, it wouldn't take thousands of years because technology is constantly improving, but as technology constantly improves, the number of bits used for encryption steadily increases. There's an algorithm (I believe its called Shor's algorithm, but I might be thinking of something else) for quantum computers that can factor numbers into primes in polynomial-time*. Once sufficiently large quantum computers are built (largest so far is 3 bits... yes, bits), breaking most standard encryption types won't take too long. * Kinda. It takes advantage of the parallel nature of quantum computers, so it's not polynomial-time in the typical sense. -AbyssDragon | |
It's possible -- the key, however, is to make sure you do three things:
1) authenticate
2) encrypt
3) keep records
Authentication is important -- basically, it means that you force each hubfile to have an authorisation key. When the server receives a hubfile, it will check to see if the authentication key matches the current authorisation codes. If so, glory be -- if not, it refuses it.
Encryption (see Air Mapster's article at BYONDscape) is also a viable and powerful deterrent -- encrypt all of the data in the hubfile, then decrypt all of the data on the other side. Unless your players are government agencies with a million-dollar budget, there's next to no way they'll crack your code any time quickly.
And, finally, you need to keep records -- that is, if someone sends you a file, then you need to have the server ignore all future duplicates of that file.