• neel (unregistered) in reply to aguy

    This is grammatically incorrect.The correct version is

    All your encryption key are belongs to us

    captcha: praesent . This article was praesented very well

  • (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, and in that case, why do that if not to let humans view / compare the resulting strings manually????

    Yazeran

    At risk of killing the joke stone dead, I believe the comment about "human readability" was an ironic poke. It wasn't ncessarily meant to be human readable, that's just the way SOAP (?) vomits XML.

    So the real WTF is using a tool to translate an encryption algorithm into a format which displays that encryption for the whole wide world to see.

    Have I finally got one right, you bunch of COBOL-sniffers?

  • Mr.'; Drop Database -- (unregistered) in reply to @Deprecated
    @Deprecated:
    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.

    But that compressed format must be hard to read. You should serialize it in some sort of human-readable format.

  • vanElden (unregistered)

    [guru@ice ~]$ file wtf.txt wtf.txt: data [guru@ice ~]$ strings wtf.txt VMware Installer0 110715074041Z 210712074041Z0v1 VMware, Inc.1 VMware, Inc.1#0! VMware default certificate1!0 [email protected] >J* ^VO# Z0X0 icvdivcs.cc.ic.ac.uk0 NjX8

  • Martin Tournoij (unregistered) in reply to Coyne

    Only after using rot13 of course!

  • Ian Yates (unregistered)

    It's at least obscured a little - the IDs are sorted by string rather than numerically :D

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    So the real WTF is using a tool to translate an encryption algorithm into a format which displays that encryption for the whole wide world to see.

    Have I finally got one right, you bunch of COBOL-sniffers?

    Not even close. *world-weary sigh*
  • Gary Olson (unregistered) in reply to Shankar
    Shankar:
    OK, before everyone laughs themselves to death - this is the raw dump of a SOAP-encoded byte array.
    No, this is a thin=provisioned, virtualized key. The real key will be transmitted after you attach the SAN volume and power up the virtualized key.
  • armand (unregistered) in reply to Coyne

    and they should do it twice!

  • armand (unregistered) in reply to Coyne
    Coyne:
    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.

    and they should do it twice!

  • visualbasucks (unregistered) in reply to Coyne

    Adding compression would be fine. Maybe some sort of container file, perhaps zip. XML requires a lot of space after all. There's transparent .zip in filesystems anyway, nowadays.

  • random (unregistered)

    That's amazing. I've got the same combination on my luggage.

  • (cs)

    Ahem, I have to admit that this one should be blamed on me.

    They see me codin', they hatin'...

  • (cs) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    @Deprecated:
    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.

    But that compressed format must be hard to read. You should serialize it in some sort of human-readable format.
    Good point.... I know! We'll use that byte array -> XML document conversion routine we already have. That would work easily enough.

  • The poop... of DOOM! (unregistered) in reply to Shankar
    Shankar:
    OK, before everyone laughs themselves to death - this is the raw dump of a SOAP-encoded byte array.
    And that's less bad why?
  • The poop... of DOOM! (unregistered) in reply to hatterson
    hatterson:
    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.

    "Well it's easy and it works... and if we have to do maintenance in five months time, we'll have no way of figuring this thing out anymore." Oh, the fun! The horrid, horrid fun!

    Captcha: Eros, what XML is to a good programmer

  • coldcut (unregistered) in reply to Bradley

    An XML within an XML? X-Ception!

  • doctor_of_common_sense (unregistered) in reply to Jeff Olson
    Jeff Olson:
    My eyes, the goggles do nothing!

    They stopped working ever since they got the opportunity to admire the brilliance of a certain Paula Bean.

  • QJo (unregistered) in reply to doctor_of_common_sense
    doctor_of_common_sense:
    Jeff Olson:
    My eyes, the goggles do nothing!

    They stopped working ever since they got the opportunity to admire the brillance of a certain Paula Bean.

    FTFY

  • Fran (unregistered)

    And notice how few of the "bytes" in that key have values above 127. What kind of key fails to exhibit even the appearance of randomness?

  • (cs) in reply to Fran

    There are also multiple keys that resolve to the same value. Can't tell if that is a WTF or deliberately designed that way.

    Either way it is a WTF

  • (cs) in reply to Fran
    Fran:
    What kind of key fails to exhibit even the appearance of randomness?
    An RSA public key. It's one of a pair of coprime numbers, not simply a randomly chosen number. That's why RSA keys have many more bits than seems necessary.
  • (cs) in reply to Silfax
    Silfax:
    There are also multiple keys that resolve to the same value. Can't tell if that is a WTF or deliberately designed that way.

    Either way it is a WTF

    There is only one key encoded in the XML document.

    Besides, did you really expect an array of 877 bytes to not contain duplicates?

  • Bert (unregistered) in reply to Bradley

    You do know about RFC 3252, no?

    Captcha: dolor. Dolor? up here we spell that dolour!

  • Josh (unregistered) in reply to Coyne

    But then it wouldn't be not readable not anymore. It's perfect for me like it is. Never have been clearer to me!

  • tehR (unregistered)

    <computer engineer>TRWTF is humans who can't read binary.</computer engineer>

  • Ralph (unregistered) in reply to Fran

    The bytes are encoded as -127 -> 127, so looks like the XML encoder treated them as signed.

  • (cs) in reply to The poop... of DOOM!
    The poop... of DOOM!:
    Shankar:
    OK, before everyone laughs themselves to death - this is the raw dump of a SOAP-encoded byte array.
    And that's less bad why?
    SOAP is inherently cleaner.
  • Hortical (unregistered) in reply to tehR
    tehR:
    <computer_engineer>TRWTF is humans who can't read binary.</computer_engineer>
    FTFY...

    TRWTF, AMIRITE?

  • Rogers (unregistered)

    Truely human readable:

    b0282938683d5848a938cd6cd81f7e1f2e5aca0c9eee3ae82b195b0938683d5848b93828cd6cdf7e1f2e5aca0c984eee3aeb1a3b0a18683d52f8483939ad6cdf7e1f2e55ea0e4e5e6e1f5ecf4a0e392e5f2f4e9e6e9e3e1f4e5c8b1a1b09f8689aa6c86b0778d8189819692f3f5f0838df0eff2f4c0f6edf7e1f286e5aee3efedb0281a2b0898d8689aa6c86778d81aa81818580832818f80b062818a822818180493ec8f021a9f5d75e90ef4cf64e20787c183c7a1fcee577108481711899f514b4a8dec315319d924f43f653181c66f45653ab77b5cb63e98193e5d051f625ed5198855a95e2757fd36b199962858ec23c5284dcbecaaa3a80d94d4e892b87

    None of the XML nonsense :)

  • Nagesh (unregistered) in reply to Hortical
    Hortical:
    tehR:
    <computer_engineer>TRWTF is humans who can't read binary.</computer_engineer>
    FTFY...

    TRWTF, AMIRITE?

    Mosting humans are not being necesary to read the binary number format. Of which use is it using modurn PC computer systems?

  • Domingo (unregistered) in reply to Rogers
    Truely human readable:

    b00283e9b00282d1208382818282842f5e92c8b08d8689aa06c806778d8181858580b09bb199b0978683d5848a9390d6cdf7e1f2e5a0c9eef3f4e1ecece5f2b09e978db1b1b0b7b1b5b0b7b4b0b4b1da978db2b1b0b7b1b2b0b7b4b0b4b1dab0f6b195b0938683d5848a938cd6cdf7e1f2e5aca0c9eee3aeb195b0938683d5848b938cd6cdf7e1f2e5aca0c9eee3aeb1a3b0a18683d58483939ad6cdf7e1f2e5a0e4e5e6e1f5ecf4a0e3e5f2f4e9e6e9e3e1f4e5b1a1b09f8689aa06c806778d8189819692f3f5f0f0eff2f4c0f6edf7e1f2e5aee3efedb00281a2b08d8689aa06c806778d81818185808302818f80b002818a8202818180493ef021a9f5d75e90ef04cf4e20787c183c7a1fcee51084817101899f514b4aec315319d924f43f6531c66f045653ab77b5cb6393e5d051f6025e0d51985a95e2757fd36b1999628ec23c5284dcbecaaa3ad94d4e0892b873335cfb0d37b18787bdb486e49f37e9b10c2da33a526e04ef221b3425dc0bc82775268df96d69a04cc243eafed00495a5226e60840c3fed5dca5373e7d95881737e3bded6cfa3212e539d15f3bb22b5ab6a99bfdfaf750be72399ec72daa3a15e366309697e7f1f73327f7c97cf5958aa093f4404910175797b448c18af1a62c95d3a1aa7a43c345d5d67d7ed1e52c4dcf295056fa9ebb54b55aee3f572a57ef14bbdc8e3695ee7828381808123dab0d8b0898683d59d938482b080b08b8683d59d8f848483828430b09d8683d59da58496b0948688ab868185858783818688ab86818585878382b09f8683d59d918498b0960294e9e3f6e4e9f6e3f3aee3e3aee9e3aee1e3aef5ebb08d8689aa06c806778d818185858083028181801d12eeb05ca003c4d2823b2f9b70514c6a0295c06ea7a5d21ae237602d90792516829b298d40a90824703b50081642c43a0227e298654c74efef16e9f2a98a1b8e64f8f66907aaf101e50c1b1fb9f6da63b9de022592dcd32fa5dd2c4f1ddd37962fe43ec9507e5c71d3dc29c8711da25151aaaa784e1ba3bf4183facda55ef7564bb3b43dfee3f31c41f4d085ceead8b899a8cf2ffc362444dc5d26c55d8d1fc66b97b5fd8b8613abbb8b58aa9483773a0f63f4a30d7cf68a1f2561e9cdd22c5207bc01e2f40cf707db82e9a56443357788fff88208f44546147cdf3f8918b71acf014fec31b9dadc7f1ab7df7f8410247e7850d977bd34c032917dc769f97b

    None of the XML nonsense :)

    FTFY

  • (cs) in reply to vanElden
    vanElden:
    [guru@ice ~]$ file wtf.txt wtf.txt: data [guru@ice ~]$ strings wtf.txt VMware Installer0 110715074041Z 210712074041Z0v1 VMware, Inc.1 VMware, Inc.1#0! VMware default certificate1!0 [email protected] \>J* ^VO# Z0X0 icvdivcs.cc.ic.ac.uk0 NjX8

    Dude, you were so close...

    bash$ openssl x509 -in wtf.txt -inform der -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: -1344400824 (-0x5021edb8)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=VMware Installer
        Validity
            Not Before: Jul 15 07:40:41 2011 GMT
            Not After : Jul 12 07:40:41 2021 GMT
        Subject: O=VMware, Inc., OU=VMware, Inc., CN=VMware default certificate/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c9:be:70:a1:29:75:57:de:10:6f:84:4f:ce:a0:
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
                DNS:redacted.redacted.re.re
    Signature Algorithm: sha1WithRSAEncryption
        9d:92:6e:30:dc:20:83:44:52:02:bb:af:1b:f0:d1:cc:ea:82:
  • vanElden (unregistered) in reply to random_garbage
    Dude, you were so close...

    Actually, the comment was supposed to address two things: a) an explanation for the superior amount of positive numbers. And b) that this WTF is far less caring about disclosing it's original source than usual on tdwtf. It being a certificate had been instated quite clearly by that time.

    Granted, it wasn't really making clear either intention :-)

  • The poop... of DOOM! (unregistered) in reply to frits
    frits:
    The poop... of DOOM!:
    Shankar:
    OK, before everyone laughs themselves to death - this is the raw dump of a SOAP-encoded byte array.
    And that's less bad why?
    SOAP is inherently cleaner.
    Thank god I just finished my coffee, or I'd have a screen to clean :D
  • Definiendum (unregistered)

    TRWTF is signed bytes

  • (cs) in reply to OldCoder
    OldCoder:
    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 do. Every person is unique, and every encrypted byte is unique.

  • lolcat (unregistered)

    Wouldnt that be inception?

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

    It's XML all the way down.

  • Thorbjørn Ravn Andersen (unregistered)

    This approach would actually make sense if the XML generation mechanism could not guarantee the ordering of identical tags inside the XML (which clearly appears to happen as the id's are sorted) and that you could not manipulate the restored values before seen by the application (like dehexing a string).

    So I think this might actually be a quite clever hack.

  • Brian (unregistered)

    I saw this amazing piece of work and thought "that's awful long for just a key, I bet it's actually a certificate of some kind"...

    % grep "e id" key.txt | sed 's/">/ /g' | sed 's/."//' | sed 's/<.//' | sort -n | awk '{ printf "%02x\n", and($2 ,255); }' | xxd -r -p | openssl x509 -text -noout -inform der

    Certificate: Data: Version: 3 (0x2) Serial Number: -1344400824 (-0x5021edb8) Signature Algorithm: sha1WithRSAEncryption Issuer: O=VMware Installer Validity Not Before: Jul 15 07:40:41 2011 GMT Not After : Jul 12 07:40:41 2021 GMT Subject: O=VMware, Inc., OU=VMware, Inc., CN=VMware default certificate/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c9:be:70:a1:29:75:57:de:10:6f:84:4f:ce:a0: f8:fc:98:bc:fa:9f:4e:65:90:04:01:f1:81:09:1f: d1:cb:ca:6c:b1:d3:99:59:a4:74:bf:e5:b1:46:ef: 84:d6:d3:2b:f7:35:4b:e3:13:65:50:d1:76:82:de: 8d:d1:18:da:15:62:f5:ff:53:eb:99:19:e2:0e:42: bc:d2:04:5c:3e:4a:2a:ba:59:cd:ce:88:12:38:f3: b3:dc:7b:8d:b7:31:07:07:3d:34:06:64:1f:b7:69: 31:8c:ad:23:ba:d2:ee:84:6f:a2:9b:b4:a5:5c:8b: 48:a7:f5:a6:0d:79:ed:e9:20:cc:42:c3:6a:7e:50: 84:15:25:a2:ee:e0:04:8c:bf:6d:dd:4a:d3:f3:67: 59:d8:01:f3:fe:bb:5e:56:4f:23:a1:ae:d3:1d:95: 73:3b:a2:35:2b:ea:19:3f:5f:2f:f5:8b:67:a3:19: 6c:f2:5a:23:21:de:b6:e3:89:e9:fe:ff:9f:f3:b2: ff:fc:17:4f:d9:d8:2a:89:bf:c4:84:11:81:f5:f9: fb:c4:0c:98:2f:9a:e2:49:dd:ba:9a:27:24:bc:b4: dd:dd:e7:57:6d:9e:d2:44:5c:72:15:85:ef:29:6b: 35:cb:d5:2e:63:75:f2:25:fe:71:cb:3d:48:63:e9: de:67 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Alternative Name: DNS:icvdivcs.cc.ic.ac.uk Signature Algorithm: sha1WithRSAEncryption 9d:92:6e:30:dc:20:83:44:52:02:bb:af:1b:f0:d1:cc:ea:82: 15:40:ee:27:25:52:9a:62:b7:e0:ad:10:f9:a5:96:02:1b:a9: 0d:c0:29:88:a4:f0:bb:d0:88:96:c2:44:ba:82:a7:62:18:e5: cc:f4:6f:6f:96:69:72:29:0a:9b:0e:e4:78:76:e9:87:2a:71: 81:65:8c:9b:9f:39:76:5a:e3:39:5e:82:a5:12:5c:53:af:25: 5d:ac:cf:9d:5d:b7:16:af:64:be:49:d0:fe:dc:f1:53:5c:a9: 48:f1:9d:22:d1:d1:2a:2a:f8:ce:9b:23:3f:c1:03:7a:4d:25: de:77:d6:cb:33:34:bd:7e:63:73:9c:c1:74:50:05:4e:6a:58: 38:19:28:4f:af:7c:b6:a4:c4:5c:dd:a6:45:dd:0d:9f:46:eb: 17:35:7d:0b:06:93:2b:3b:0b:d8:2a:14:03:f7:ba:8f:e3:74: 23:8d:fc:76:0a:9f:a5:e1:69:4d:52:ac:d2:87:3c:81:62:74: 8c:77:87:5b:02:69:25:e4:c3:b5:f7:08:7f:78:02:88:74:c5: c6:94:fc:5f:bf:09:98:37:9a:4f:81:cf:6c:b1:39:5a:5c:ff: 9a:37:5f:ff:04:90:a4:fe:f8:d0:59:f7:3d:b4:40:b2:11:fd: 47:e9:79:fb

    Now, given that it's a standard x509 cert, one MIGHT encode ascii-armor it in the typical PEM style:

    -----BEGIN CERTIFICATE----- MIIDaTCCAlGgAwIBAgIEr94SSDANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQKExBW TXdhcmUgSW5zdGFsbGVyMB4XDTExMDcxNTA3NDA0MVoXDTIxMDcxMjA3NDA0MVow djEVMBMGA1UEChMMVk13YXJlLCBJbmMuMRUwEwYDVQQLEwxWTXdhcmUsIEluYy4x IzAhBgNVBAMTGlZNd2FyZSBkZWZhdWx0IGNlcnRpZmljYXRlMSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QHZtd2FyZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDJvnChKXVX3hBvhE/OoPj8mLz6n05lkAQB8YEJH9HLymyx05lZpHS/ 5bFG74TW0yv3NUvjE2VQ0XaC3o3RGNoVYvX/U+uZGeIOQrzSBFw+Siq6Wc3OiBI4 87Pce423MQcHPTQGZB+3aTGMrSO60u6Eb6KbtKVci0in9aYNee3pIMxCw2p+UIQV JaLu4ASMv23dStPzZ1nYAfP+u15WTyOhrtMdlXM7ojUr6hk/Xy/1i2ejGWzyWiMh 3rbjien+/5/zsv/8F0/Z2CqJv8SEEYH1+fvEDJgvmuJJ3bqaJyS8tN3d51dtntJE XHIVhe8pazXL1S5jdfIl/nHLPUhj6d5nAgMBAAGjWjBYMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAfBgNVHREE GDAWghRpY3ZkaXZjcy5jYy5pYy5hYy51azANBgkqhkiG9w0BAQUFAAOCAQEAnZJu MNwgg0RSAruvG/DRzOqCFUDuJyVSmmK34K0Q+aWWAhupDcApiKTwu9CIlsJEuoKn YhjlzPRvb5ZpcikKmw7keHbphypxgWWMm585dlrjOV6CpRJcU68lXazPnV23Fq9k vknQ/tzxU1ypSPGdItHRKir4zpsjP8EDek0l3nfWyzM0vX5jc5zBdFAFTmpYOBko T698tqTEXN2mRd0Nn0brFzV9CwaTKzsL2CoUA/e6j+N0I438dgqfpeFpTVKs0oc8 gWJ0jHeHWwJpJeTDtfcIf3gCiHTFxpT8X78JmDeaT4HPbLE5Wlz/mjdf/wSQpP74 0Fn3PbRAshH9R+l5+w== -----END CERTIFICATE-----

    Which is clearly inferior to the "Human Readable" XML encoding they chose.

  • (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?

    We should just nuke our planet. Thoroughly. Would save all the human pain and suffering. Nobody would be left to care afterwards. Right?
  • rlemon (unregistered)

    I also loved the alphabetical sorting of the id's

    Makes me rethink my own data.

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article