• (cs)

    It is sort of obvious who the vendor is from performing a seach on FieldSmartConfiguration. I won't repeat it here but you can look it up if you want.

    Looking at the pages returned by the search, I found this bit of text:

    "(vendor's name) compression algorithm converts your GIS, customer, and various other data sets into the FieldSmart format, increasing the speed at which you can navigate, search and route around your mapping data."

    Looks like a really high tech compression algorithm to me... ;-)

  • CDave (unregistered) in reply to BSDGeek
    BSDGeek:
    SSBwcmVmZXIgdXNpbmcgJ2I2NGRlY29kZSAtcHIgL2Rldi9zdGRpbicK=

    No use this ClVzZSBmaXJlZm94IGFuZCBpbnN0YWxsIHRoZSAiTGVldCBrZXkiIGFkZG9uLiBJdCBhbGxvd3Mg aW5saW5lIGRlY29kaW5nIGFuZCBlbmNvZGluZyBvZiBiYXNlNjQgd2l0aCBhIHNpbXBsZSByaWdo dCBjbGljayBtZW51Lg==

  • Really??? (unregistered) in reply to mah bonez

    I believe by this definition, English is an encryption scheme as you clearly need the special knowledge of "reading English" to understand it.

    I'm pretty sure that using general language definitions for technical terminology on a technical site could be your error.

    I'm pretty sure we're about to invoke Godwin's Law though.

  • (cs) in reply to Really???
    Really???:
    I believe by this definition, English is an encryption scheme as you clearly need the special knowledge of "reading English" to understand it.

    I'm pretty sure that using general language definitions for technical terminology on a technical site could be your error.

    I'm pretty sure we're about to invoke Godwin's Law though.

    And I say it depends on intent. When two Mexicans are speaking spanish to each other, it's an encoding. When they're doing it to make fun of their gringo customers without getting deported, it's encryption.

  • (cs) in reply to Really???
    Really???:
    I believe by this definition, English is an encryption scheme as you clearly need the special knowledge of "reading English" to understand it.

    I'm pretty sure that using general language definitions for technical terminology on a technical site could be your error.

    I'm pretty sure we're about to invoke Godwin's Law though.

    That definition doesn't do anything to distinguish it from encoding. This makes your definition of poorer quality than others. At a minimum, definitions should let you tell words apart.

  • immitto (unregistered) in reply to AP²
    AP²:
    validus:
    AP²:
    The table used in base64 is *part of the algorithm*, therefore it's not encryption. Could you write an algorithm based on base64 which used any combination of 64 characters, making it encryption? Sure. But that wouldn't be base64, just something based on it.
    And the method has us chopping 8 bit strings into 6 bit strings. What if we chopped 8 bit strings into strings of length 5 or 6? What if we chopped 10 bit strings into 8? Can you see how these magic numbers 8 and 6 are a bit like having a key?

    If you chopped into strings of different length, it wouldn't be the same algorithm, because that algorithm specifies a certain length.

    Again, you could write an algorithm which received the length as a "key", but it wouldn't be base64.

    It wouldn't be base64, but I feel we're getting inot semantics a bit. So you agree that ROT13 is not encryption (because we can't specify the 'hard coded' key 13 - it's defined in the name). What if I chose to encrypt using RSA<insert private Key>? Does this cease to be encryption simply because we hard code the key? Doubtless it becomes very insecure but the key still exists....

    The point is (WRT Base64), that by changing the values 6,8 the algorithm remains the same - irrespective of whether we are still encoding base64 (that's just our name for the algorithm). Similarly, in ROT13 we simply shift 13 characters - in the Caeser Cipher we shift 3 characters - it's still the same algorithm, just with a different key.

    I find it hard to distinguish between algorithm and key in this situation. by defining an algorithm, we are in affect defining a key - because there will always be some fixed value (possibly 1) in that algorithm that can be changed, thus I reject the claim that the distinction between Encryption and Encoding is the presence (or lack thereof) of a key...

    I think the problem is that Encryption and Encoding have different contexts. Encryption is the act of trying to hide something by changing it into an unrecognizable form (that still has sufficient pattern to be restored to it's former glory). Encoding is the act of trying to change something to guarantee that it can reliably be stored/sent (with the obvious requirement that it can still be restored). So it seems that it's all intent-dependent. Encoding can be Encryption, and Encryption can be Encoding - it's all in the eye of the beerholder (though as someone before me points out, you wouldn't exactly encode using RSA if you were keen on efficiency, nonetheless it is an approach that people could take).

    Put simply, people here are arguing at a technical level, concepts which really differ on a non-technical level. But I'm sure I won't convince them any different

  • Really??? (unregistered) in reply to immitto
    immitto:
    Put simply, people here are arguing at a technical level, concepts which really differ on a non-technical level. But I'm sure I won't convince them any different

    Arguing the semantics that the two terms are essentially the same is to remove all purpose in having specific words at all.

    For example, FindLaw defines encryption as "the conversion of data into a form not readily understood by unauthorized people, called cipehertext. Decryption is the conversion of encrypted data back into its original form, so it can be understood. Encryption can be as simple as substituting numbers for letters, or as complex as rearranging data bits using computer algorithms."

    Base64's intent/purpose/use/whatever is not to prevent unauthorized access. Could someone use it for that purpose... if they are stupid...sure... but thats it is not the purpose of Base64.

  • Luiz Felipe (unregistered) in reply to Anon

    [quote user="Anon"][quote user="EvanED"I agree in the sense that there is a very different connotation to each. I disagree in the sense that I think it would be quite hard to come up with a definition that draws a sharp line between the two (or separating out a subset of encodings as "not encryption")[/quote]

    No, it's very easy to come up with a sharp line. If some data is transformed into some other form with the purpose of hiding it, then it's encryption. If data is transformed for the purpose of transporting or storing it, it's encoding. Whether or not an encryption is strong or not is beside the point. Sometimes you might do both to the same set of data.

    XML, ASCII, Unicode are encodings. They are designed for ease and efficiency of storage and transmission of information.

    RSA is encryption, regardless of whether or not it's breakable. Nobody would use RSA just for transporting or storing data unless they also intended to hide it from prying eyes.[/quote]

    Bingo!! +1

  • Luiz Felipe (unregistered) in reply to Matt XIV
    Matt XIV:
    I'm guessing that the objective was to scare off casual editing and the actual protection is a contract. Faking licensing for the company I work at's software is remarkably easy (all you need is to update a table) but unheard of because of:
    1. A contract term allowing us to sue anybody who fakes a license into a fine mist.
    2. The software being sufficiently complicated to configure that it's essentially unusable without a support contract.

    I hasnt license routine because users are so stupid that cannot run the software alone not even one day without support. My software is very complicated to configure also.

    +1

  • Luiz Felipe (unregistered) in reply to Decider
    Decider:
    Hortical:
    C-Octothorpe:
    Encryption is NOT Encoding[/url] Mariam Websters perhaps defines them as interchangeable terms, however in the context of computer science and cryptography specifically (which is what we're talking about, so get over it), they are wholly different things.

    I'd put it this way:

    1. Encryption might be considered a form of Encoding

    ...If we consider Encoding to mean moving data from one representation to another. Encryption in particular is then a way of encoding data such that it will be sufficiently difficult to decode. Decoding may be greatly facilitated by a key, it might even absolutely require it to make sure the data has been properly decoded.

    1. A given Encoding is not necessarily a form of Encryption

    Because encoding is just changing how we represent data. When I convert from Unicode to ASCII, is that encryption? What about when I make a ZIP archive? Or convert from one lossless image/audio format to another? Encryption? Really?

    You could argue, if you wish, that the use of base64 here is encryption, just a really poor one. That discussion would end up mirroring "(Art/Not Art) vs (Good Art/Bad Art)".

    Ladies and Gentlemen, I think we have a winner!

    Encoding is about representation. Encryption is about Secrecy. There is some overlap, Encryption is a form of Encoding, but Encoding is NOT encryption.

    The definitions are unrelated. The problem is when people start insisting that things are one or the other, that is, that we can never be both.

    Let's assert that apples are a food. Does this mean that apples are not fruit? I always thought apples were fruit. Does the assertion that they are in fact food have any influence on my original supposition that they were fruit? Does this mean all food is fruit? No, a fruit is a (reasonably specific) type of food.

    Let's assert that cryptograms are codes. Does this mean that cryptograms are not ciphers? I always thought cryptograms were ciphers. Does the assertion that they are in fact codes have any bearing on my original supposition that they were ciphers? Does this mean all codes are cipher? No, a cipher is a (fairly specific) form of code.

    ingenium: It requried his full ingenium to come up with an analogy like that

    class Crypografy : Enconding class Apple : Food, Fruit why this is very dificult for people understand.

  • Luiz Felipe (unregistered) in reply to excession
    excession:
    Back in the BBS/Fidonet days, our illustrious 'sysop' attempted to gloat about the in-built "super secure" sysop-only communications available in the BBS software he had acquired.

    A few minutes with the encrypted message he included, showed that it was simple ROT15. :rolleyes:. (not ROT13, that would have been just too easy). He also wrote threats of 'suing' me for releasing private internals of software ... the same guy tried to disbar me from the BBS for telling him to 'go stick your head in a pig'.

    True Confessions: I've coded a C++ Base64 implementation that's -still- in production use :/ Please don't ask "why?".

    why? tell it was for fun tell. please!

  • (cs) in reply to e john
    e john:
    haero to all my friends in Tokyo !

    こんにちは。。。

  • BeenThereSeenIt (unregistered)

    Was this an iSoft product?

  • Sir Robin-The-Not-So-Brave (unregistered)

    Thijs is a Dutch form of Matthew, so I'd bet on him being from either the Netherlands, the Dutch speaking part of Belgium (Flanders), or maybe South Africa.

    That tells you nothing about where he works. But if I had to make an educated guess about where I could grab a macchiato with Thijs at his nearest Starbucks, I'd book a plane to Schiphol (Amsterdam airport).

  • UNIX cultist (unregistered) in reply to GFK

    Here's a complete program to decode Base64, if you really need one:

    KGxldCBsb29wICgobmV4dC1jaGFyIChyZWFkLWNoYXIpKQ0KCSAgICAgKHJlc3VsdCAnKCkpKQ0K ICAgIChpZiAoZW9mLW9iamVjdD8gbmV4dC1jaGFyKQ0KCShieXRlcy0+c3RyaW5nL3V0Zi04DQoJ IChiYXNlNjQtZGVjb2RlIChzdHJpbmctPmJ5dGVzL3V0Zi04IChsaXN0LT5zdHJpbmcgKHJldmVy c2UgcmVzdWx0KSkpKSkNCgkobG9vcCAocmVhZC1jaGFyKSAoY29ucyBuZXh0LWNoYXIgcmVzdWx0 KSkpKQ0K

  • Maarten (unregistered) in reply to boog
    boog:
    MadJo (professional software tester):
    boog:
    You left out the part where Thijs B's company gets sued to oblivion for "bypassing security" and "reverse engineering" the software.

    Thijs is clearly not a US-name, and therefor the DMCA doesn't apply, thanks for playing, we have some lovely consolation prices for you backstage.

    Funny, I didn't say anything about copyright in my answer.

    It may be that I wasn't talking about the DMCA at all.

    In many countries, even in the one of the few where ij actually is a valid vowel on it own instead of being pronouced as i-j or i, reverse-engineering for interoperability is actually specifically allowed by law.

  • Sitnik (unregistered)
    That has to be atleast worth $64K
    Hahahahaha awesome!
  • ^W (unregistered) in reply to ^E
    ^E:
    <FieldSmartConfiguration encoding=<b>"basic">

    They were not kidding about using basic "encryption". I wonder if the enterprise version uses an additional layer of triple ROT-13?

    TRWTF is that Thijs B doesn't know about HTTP basic authentication scheme.

  • Purr (unregistered) in reply to ^E

    No the unbreakable quadruple ROT-13

  • Great solution (unregistered)

    any symetric encryption are using a secret. That secret can be found. If the business case is, not a lot of pirated version of the software. The customer will not accept the tool to "phone home" to validate the xml or get a key. Then this is a realy good solution.

  • Crusty (unregistered) in reply to Anon

    Back in the 80's a certain large three-letter-named mainframe manufacturer that is no longer making hardware offered a "software" upgrade for their printers that made them go significantly faster. A UK based engineer reverse engineered the patch from a machine core dump (that ironically came off the printer) and figured out that the "patch" was a bunch of NOPs that overwrote the delay loop that had originally been added to address timing issues between the mainframe and the printer. Said engineer and employer received the attentions of the manufacturer's legal representatives.

  • (cs) in reply to boog

    No doubt management was savvy enough to sign a contract that prevented anyone but the vendor from making any changes to the software. Common, especially in government.

  • (nodebb)

    thanks for info

    Addendum 2024-04-25 09:20: I connected with a team of dedicated software developers on a website, and together, we've successfully launched my trading platform online. Their commitment to excellence and innovative approach to software development sloboda-studio.com have been pivotal in bringing my vision to life. With their expertise, we've built a robust and scalable platform that caters to the diverse needs of traders in today's dynamic market. Thanks to their support, I'm confident that my trading platform is poised for success, empowering users to achieve their financial goals with ease.

Leave a comment on “Encrypted XML”

Log In or post as a guest

Replying to comment #:

« Return to Article