• :O (unregistered)

    Whoa, wait, am I frist?

  • anon (unregistered)

    They even sorted the byte indices asciibetically! Just in case some silly human wanted to read them out in numerical order.

  • Svenson (unregistered)

    I don't know what you're complaining about. It's XML, so not only is it human readable, but it is also self-documenting!

  • z00n!sys (unregistered)
    Comment held for moderation.
  • airdrik (unregistered)
    Comment held for moderation.
  • Bradley (unregistered)

    They should wrap the XML in inside another XML envelope for even more readability.

  • Daniel Migowski (unregistered)
    <?xml encoding="UTF-8_Human-Readable_Letters"?> <comment> <letter id="1">F</letter> <letter id="10">K</letter> <letter id="11">,</letter> <letter id="12"> </letter> <letter id="13">n</letter> <letter id="14">o</letter> <letter id="15">t</letter> <letter id="16"> </letter> <letter id="17">e</letter> <letter id="18">v</letter> <letter id="19">e</letter> <letter id="2">I</letter> <letter id="20">n</letter> <letter id="21"> </letter> <letter id="22">c</letter> <letter id="23">l</letter> <letter id="24">o</letter> <letter id="25">s</letter> <letter id="26">e</letter> <letter id="27"> </letter> <letter id="28">t</letter> <letter id="29">o</letter> <letter id="3">R</letter> <letter id="30">!</letter> <letter id="4">S</letter> <letter id="5">T</letter> <letter id="6">!</letter> <letter id="7">!</letter> <letter id="8"> </letter> <letter id="9">O</letter> </comment>
  • Jeff Olson (unregistered)

    My eyes, the goggles do nothing!

  • Migala (unregistered) in reply to :O
    :O:
    Whoa, wait, am I frist?

    You were, but comments will be alphabetically ordered in the future, and yours will be almost last.

  • balrogbeard (unregistered)

    No WTF unless someone actually claimed it was human-readable. XML is not just for human-readability.

    This just looks like someone passed a byte array to a generic xml-serializer. An easy way to save config. Who cares?

  • AP² (unregistered)

    The WTF is an XML serializer which stores a byte array with dozens of elements instead of storing it as a single base64 encoded string.

  • hatterson (cs) in reply to balrogbeard
    balrogbeard:
    No WTF unless someone actually claimed it was human-readable. XML is not just for human-readability.

    This just looks like someone passed a byte array to a generic xml-serializer. An easy way to save config. Who cares?

    Anyone who has a preference for non-retarded design patterns should care.

    "Well it's easy and it works" should never be the only justification for using a specific method.

  • James (unregistered)

    That's the problem with encryption in general. It just makes everything unreadable. rimshot

  • kktkkr (unregistered) in reply to Migala
    Migala:
    :O:
    Whoa, wait, am I frist?

    You were, but comments will be alphabetically ordered in the future, and yours will be almost last.

    So Arist will be the new Frist? Aristotle will be so proud.

    Captcha: damnum, those guys who didn't put the IDs in binary before sorting.

  • Ungegistered (unregistered) in reply to hatterson

    Why not? If its easy and it works...

  • David (unregistered)

    Wow, that has got to be the dumbest thing I've seen in a long time. Actually, perhaps this is too hard to read.

    H o w

    i s

    t h i s ?

  • frits (cs)
    Steve:
    ...humans can't read bytes...
    Steve:
    While one could certainly represent those bytes with a hexadecimal string, or even a little base64, it still looks like machine-language gobbledygook.
    Steve:
    (sarcastically) Behold the encryptionKey and its simple, human-readable XML representation.
    Steve:
    ...power of XML...
    Steve is one hell of a question beggar.
  • z00n!sys (unregistered) in reply to James
    James:
    That's the problem with encryption in general. It just makes everything unreadable. *rimjob*
    ftfy

    I'm just dying to stay relevant!!!

  • Yazeran (cs)

    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

  • Petr V. (unregistered) in reply to :O

    Whoa you're fast! I only just finished reading the whole damn thing.

  • Sutherlands (cs) in reply to Yazeran
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    Yes. Also, you apparently think dictionaries collide on values and not keys.
  • OldCoder (unregistered) in reply to Yazeran
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?

    captcha: illum. I feel illum after reading that...

  • @Deprecated (unregistered) in reply to Ungegistered
    Ungegistered:
    Why not? If its easy and it works...

    Byte array size: 876 bytes. Document size: ~22,000 bytes

    But, if you compress it, then it's only ~3600 bytes! And probably just as informative.

  • aguy (unregistered)

    All your encryption key belongs to us

  • frits (cs)

    Don't they have JSON utilities for this?

  • balrogbeard (unregistered) in reply to @Deprecated

    A 22KB config file on a machine that runs VMWare? That's outrageous!

  • cobru (unregistered)

    The real WTF is that the whole thing fitted in the body of the WTF article. :)

  • Yazeran (cs) in reply to OldCoder
    OldCoder:
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?

    captcha: illum. I feel illum after reading that...

    I'm perfectly aware that the keys are unique, but by fear is that somewhare in the application/use of the application the VALUES are used and compared against each other, hence my comment about collisions.

    Yazeran

    Plan: To go to Mars one day with a hammer

  • Coyne (cs) in reply to Bradley
    Bradley:
    They should wrap the XML in inside another XML envelope for even more readability.

    That's SO right! And then they should use encryptStr() on it just to be extra sure it's secure.

  • Sutherlands (cs) in reply to Yazeran
    Yazeran:
    OldCoder:
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?

    captcha: illum. I feel illum after reading that...

    I'm perfectly aware that the keys are unique, but by fear is that somewhare in the application/use of the application the VALUES are used and compared against each other, hence my comment about collisions.

    Yazeran

    Plan: To go to Mars one day with a hammer

    You don't think that it, oh I don't know.... uses them as the byte value input for creating a key?

  • DescentJS (cs) in reply to Sutherlands
    Sutherlands:
    Yazeran:
    OldCoder:
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?

    captcha: illum. I feel illum after reading that...

    I'm perfectly aware that the keys are unique, but by fear is that somewhare in the application/use of the application the VALUES are used and compared against each other, hence my comment about collisions.

    Yazeran

    Plan: To go to Mars one day with a hammer

    You don't think that it, oh I don't know.... uses them as the byte value input for creating a key?

    I wouldn't make any assumptions about how the sort of people responsible for making something like this would wind up using it.

  • Yazeran (cs) in reply to Sutherlands
    Sutherlands:
    Yazeran:
    OldCoder:
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?

    captcha: illum. I feel illum after reading that...

    I'm perfectly aware that the keys are unique, but by fear is that somewhare in the application/use of the application the VALUES are used and compared against each other, hence my comment about collisions.

    Yazeran

    Plan: To go to Mars one day with a hammer

    You don't think that it, oh I don't know.... uses them as the byte value input for creating a key?

    Well The way I read th article, then the whole point about this list is to used for human readability, and in that case, why do that if not to let humans view / compare the resulting strings manually????

    Yazeran

  • Sutherlands (cs) in reply to Yazeran
    Yazeran:
    Well The way I read th article, then the whole point about this list is to used for human readability
    You're right! WTF?! You should find a site that takes horrible code snippets and posts them for the community to see.
  • Ken B. (unregistered) in reply to DescentJS
    DescentJS:
    Sutherlands:
    Yazeran:
    OldCoder:
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?
    I'm perfectly aware that the keys are unique, but by fear is that somewhare in the application/use of the application the VALUES are used and compared against each other, hence my comment about collisions.
    You don't think that it, oh I don't know.... uses them as the byte value input for creating a key?
    I wouldn't make any assumptions about how the sort of people responsible for making something like this would wind up using it.
    However, I think we can assume that even they would know that there must be "collisions" if you are selecting 877 values from a set of 256.

  • squat (unregistered) in reply to Yazeran
    Yazeran:
    OldCoder:
    Yazeran:
    Am I the only one who spotted collisions??

    <e id="186">42</e> <e id="187">-122</e> <e id="188">72</e> <e id="189">-122</e> <e id="19">48</e>

    I sincerely hope that the representation is ONLY used for human readability, and not used in any form of identification / sanity check....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

    They are not collisions. The ID is the array offset, the value is the data. You don't think that every encrypted byte in the world is unique, do you?

    captcha: illum. I feel illum after reading that...

    I'm perfectly aware that the keys are unique, but by fear is that somewhare in the application/use of the application the VALUES are used and compared against each other, hence my comment about collisions.

    Yazeran

    Plan: To go to Mars one day with a hammer

    STOP!

    Hammertime!

  • PedanticCurmudgeon (cs) in reply to frits
    frits:
    Steve is one hell of a question beggar.
    I thought correct use of idioms wasn't allowed here. Guess you learn something new every day...
  • Nagesh (unregistered)
    TFA:
    "One of the problems with encryption keys," notes Steve, "is that they're generally just a set of bytes, and humans can't read bytes.
    Steve, this not is to being a problem encryption keys are having. XML can also be significant convenience for transmit encryption keys by HTTP.
  • Art (unregistered)

    I don't think this was the encryption key. No, that's the actual encrypted data. It is transmitted in a non-sequential fashion precisely so you can't read it.

  • TTWTF (unregistered)

    TTWTF: Someone posted their company's encryption key?

  • XMLParser (unregistered) in reply to TTWTF

    That's okay, no one can read it anyway

  • Gunslinger (unregistered)

    What is this, I don't even...

  • BentFranklin (cs)

    Doesn't it seem odd that there are twice as many positive values (575) as there are negative (294)?

    They should either be roughly equal, if the data is pure binary, or 100% positive, if the key is all ASCII.

  • burp (unregistered)

    FYI, the encoded data is an X509 certificate.

  • Shankar (unregistered)

    OK, before everyone laughs themselves to death - this is the raw dump of a SOAP-encoded byte array.

  • Jaime (cs) in reply to burp
    burp:
    FYI, the encoded data is an X509 certificate.
    Or, more specifically, this is the value of "e" -- the public key of an RSA key pair. e is not simply a random number, so its bytes shouldn't be expected to be evenly distributed.
  • lyates (cs)

    The real WTF is XML. amirite?

  • burp (unregistered) in reply to Jaime
    Jaime:
    burp:
    FYI, the encoded data is an X509 certificate.
    Or, more specifically, this is the value of "e" -- the public key of an RSA key pair. e is not simply a random number, so its bytes shouldn't be expected to be evenly distributed.
    There's also a bunch of other crap in an X509 certificate.
  • paul (unregistered) in reply to Coyne

    rot13 will beat the NSA any day

  • Matt Westwood (cs) in reply to z00n!sys
    z00n!sys:
    Now THIS is hot!

    Both my grandmothers are dead, you insensitive clod. Have a bit of respect.

  • method1 (cs) in reply to DescentJS
    DescentJS:
    I wouldn't make any assumptions about how the sort of people responsible for making something like this would wind up using it.

    Good one.

Leave a comment on “The Human-Readable Encryption Key”

Log In or post as a guest

Replying to comment #:

« Return to Article