|
This hardly needs an algorithm. It is just a matter of adding up all the points and sorting the drivers and teams into ascending order by points.
|
|
|
|
|
I use Carbonite backup service on my main machine. Carbonite claims that they are able to transmit only changes in a file to their servers so that the whole file needn't be transmitted again when there are changes to that file.
How are they doing this? Wouldn't they need to compare the changed file against a complete copy of the original? And to do this across the net would require transmitting the entire file anyway, right?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Well I guess only Carbonite could give a definitive answer. But, it is possible they are keeping a copy of the file's directory information so they can just compare disk segments, and they backup by copying the segments direct from disk. Then on the next incremental backup they only need to copy any segments that have been added since the previous backup.
|
|
|
|
|
That is likely to miss changes to files that do updates in place with mapped files...
|
|
|
|
|
Which is why I added the initial sentence to my response.
|
|
|
|
|
I developed a lossless, key-based, encryption algorithm that can work in any modern programming language and it has a 1-to-1 relationship between the unencrypted values and the encrypted values as long as the key remains the same and the minimum values and maximum values are known. The key can also be of virtually limitless size or of a very limited size. The algorithm uses carefully calculated mathematics to give the appearance of gibberish until it is decoded with the proper key or combination of keys. Other than that, I cannot reveal anything, lest I lose any intellectual property right opportunities that I have to the algorithm. How much is this encryption algorithm potentially worth if I patent it?
|
|
|
|
|
How many keys are you using? (I mean public/private).
How you exchange keys?
There is default values for key size?
Did you run some performance tests on real life data?
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Daniel Mullarkey wrote: How much is this encryption algorithm potentially worth if I patent it?
Not much, since there are already high quality encryption methods available at no cost.
|
|
|
|
|
Well, to address both replies, the core function headers look something like this:
Public Function Encode(ByVal UnencodedValue As Integer, ByVal KeyValue As Integer, ByVal MinimumValue As Integer, ByVal MaximumValue As Integer) As Integer
Public Function Decode(ByVal EncodedValue As Integer, ByVal KeyValue As Integer, ByVal MinimumValue As Integer, ByVal MaximumValue As Integer) As Integer
Keep in mind that UnencodedValue and EncodedValue can range anywhere from MinimumValue to MaximumValue and that the KeyValue can range anywhere from MinimumValue + 2 to MaximumValue.
|
|
|
|
|
Encryption is not only (and not mainly) about hide your data behind numbers. It can be smart but that's not nearly enough...You have to think about the data exchange between the side encrypting and the other that decrypting the data. For every encryption has helpers - these are the keys - and those helpers are have to pass (or be presented) on both side. You method signatures are telling nothing about that - just from this we can't tell nothing about, how your encryption is good. It also tells nothing about it speed of execution...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
modified 23-Mar-14 10:49am.
|
|
|
|
|
Well, I can say that the core methods involve 10 lines of code, one with a conditional (if...then) recursion that at best only occurs once per original use and the rest involves conditional (if...then) mathematics at three levels, thereby making it very quick and very fast. Besides, ever heard of lossless compression? Well, I might as well have created perpetual lossless, key-based, encryption. Keep in mind that the encryption algorithm is symmetrical, so the very idea of having public keys would be a bad idea. The core of my encryption algorithm is essentially a block cipher in which the unencrypted value does not grow or shrink in size when encrypted. Also, keep in mind that it can not only encrypt bulk data, but it can also use bulk keys. And one day I will show that I can deliver on the goods. I just have to find a way to afford to pay LegalZoom $1,000 to patent it.
"In cryptography, a block cipher is a deterministic algorithm operating on fixed-length groups of bits, called blocks, with an unvarying transformation that is specified by a symmetric key. Block ciphers are important elementary components in the design of many cryptographic protocols, and are widely used to implement encryption of bulk data."
--Quoted from Wikipedia from Block cipher
|
|
|
|
|
I'm not really interested in the details of your code, what I'm trying to tell you that your core methods are just the core...It's a very good thing that it performs well, however the recursion is always turn a red light on with me...That kind of methods need intensive test with different kind of data...
Daniel Mullarkey wrote: encryption algorithm is symmetrical
According your previous post - with the method signatures - it's true only if you have key, min and max values...So still you have to consider how do you share that info between the parties...
So bfore you spend that $1000, try to fill all the gaps (and may be more that I listed). You may look into existing protocols for info how they build...
http://en.wikipedia.org/wiki/Cryptographic_protocol[^]
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
modified 23-Mar-14 11:04am.
|
|
|
|
|
All encryption is lossless? You have to be able to undo it back to the original :P
|
|
|
|
|
I suspect you really need to study the principles of encryption. Any encryption system worth its salt should be language neutral, and able to handle any stream of bytes rather than just integers.
|
|
|
|
|
Bytes can be transformed into integers easily enough using any modern programming language and since I have already succeeded with strings and characters, bytes are on their way. :8)
|
|
|
|
|
Daniel Mullarkey wrote: Bytes can be transformed into integers easily enough using any modern programming language
And how do you decide how many bytes to make up each integer? There is no correspondence between the two types. In reality any encryption/decryption system works purely on a stream of bytes, the actual values of individual groups has no relevance.
|
|
|
|
|
Would you believe that I used conversion type functions?
|
|
|
|
|
I would believe anything, but what does that have to do with producing an efficient and valid encryption algorithm?
|
|
|
|
|
Nothing, in and of itself. What makes my encryption algorithm unique is that unlike other encryption algorithms, the set of all unencrypted values, encrypted values, and key values, are electronically indistinguishable from one another, while the each unencrypted value its corresponding encrypted value are still uniquely different from one another.
modified 5-Apr-14 10:21am.
|
|
|
|
|
So you keep telling us, but that proves nothing. Your algorithm needs to be tested to destruction by experts in the field, before anyone is going to pay you any money for it.
|
|
|
|
|
That point I will concede. Nonetheless, I was planning on licensing it out, rather than selling the patent wholesale.
|
|
|
|
|
Daniel Mullarkey wrote: I was planning on licensing it out
Well you still have the same problem. Who do you think is going to want to licence an encryption system without any evidence of its efficacy?
|
|
|
|
|
It's fine to use int as a shortcode for 'group of 4 bytes' imo, that's what int means in pretty much every modern environment.
|
|
|
|
|
I understand that, I'm not sure that OP does.
|
|
|
|
|
I'd have to agree with the conclusions here and on Google[^] - the description is not enough to evaluate the value of your algorithm, and proprietary closed-source encryption algorithms are never a good idea. Since there are perfectly valid free and open-source algorithms available which have undergone years of intensive analysis, the chances of getting anyone to switch to your new, unproven algorithm are practically zero, even if you gave it away.
Daniel Mullarkey wrote: The algorithm uses carefully calculated mathematics to give the appearance of gibberish until it is decoded with the proper key or combination of keys.
As Arne Vajhøj said in your Google thread[^], that's practically the definition of encryption.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
