• (disco)

    Most crypto discussions give me a headache, and this one certainly does.

  • (disco) in reply to JBert

    I love crypto discussions! :smile:

    This one has good advice -- namely, "devs shouldn't do crypto on their own." Unless they have a degree in it, just use the built-in functions or something like OpenSSL. Nobody gets in trouble for that. Usually.

  • (disco)

    Would using the right kind of transaction (I'd guess SERIALIZABLE) prevent the concurrency problem? Or does MySQL's suck in that area overwhelm that?

  • (disco)

    The standard whcih defines

  • (disco) in reply to LB_
    LB_:
    > The standard **whcih** defines

    You summoned me, and so i appear

  • (disco)

    Everything in cryptography depends upon “high quality” random numbers, and lots of them.

    And none of it depends on, say, avoiding circumstances where side channel attacks are possible?

  • (disco)

    Looks like a certain editor forget to run the spell-check.

  • (disco)

    The real WTF is to use SQL for doing crypto

  • (disco) in reply to tom103
    tom103:
    The real WTF TRWTF is to use SQL for doing crypto anything but queries

    FTFY

    YMBNH

  • (disco) in reply to PJH
    PJH:
    > Everything in cryptography depends upon “high quality” random numbers, and lots of them.

    And none of it depends on, say, avoiding circumstances where side channel attacks are possible?

    Well, strictly speaking, he didn't say that everything depends ***only*** on high quality random numbers, so he didn't exclude the possibility of everything depending on ***both*** having access to high quality random numbers ***and*** avoiding circumstances where side channel attacks are possible.

    And of course the moment-to-moment operation of a Feisel-type symmetric cipher doesn't depend on random numbers at all, but definitely carries a risk of side channel attacks.

  • (disco) in reply to dkf
    dkf:
    Would using the right kind of transaction (I'd guess `SERIALIZABLE`) prevent the concurrency problem? Or does MySQL's suck in that area overwhelm that?

    I can only imagine the increasing delays and eventual deadlocks of trying to serialize this extra-slow encryption.

  • (disco) in reply to foxyshadis
    foxyshadis:
    I can only imagine the increasing delays and eventual deadlocks of trying to serialize this extra-slow encryption.

    Woah there! Nobody said that going fast was part of the specification!

  • (disco)

    But it is Open Source! Everybody can verify that it works! Closed source code would be compromised once a bad one would find out how it works!

  • (disco) in reply to Steve_The_Cynic

    Cryptography depends on access to sufficient quantities of high quality random numbers, and protection against side channel attacks. Cryptography depends on two things: high quality random numbers and protection against side channel attacks. And sufficient key length. Cryptography depends on three things: random numbers, protection against side channel attacks and sufficient key length... and proper distribution of keys.

  • (disco) in reply to RichP
    RichP:
    Cryptography depends on access to sufficient quantities of high quality random numbers,

    How long until someone uses Discourse as an RNG? The response rates and various "504 OK" and "You don't have permission to view the requested resource" seem to have pretty high entropy.

  • (disco) in reply to PWolff
    PWolff:
    But it is Open Source! Everybody can verify that it works! Closed source code would be compromised once a bad one would find out how it works!

    Filed Under: Security by obscurity, etc

  • (disco) in reply to mott555

    In approximately 200 Internal Server Error

  • (disco) in reply to RichP
    RichP:
    Cryptography depends on three things: random numbers, protection against side channel attacks and sufficient key length... and proper distribution of keys.

    Don't come in again.

  • (disco) in reply to RichP
    RichP:
    Cryptography depends on access to sufficient quantities of high quality random numbers, and protection against side channel attacks. Cryptography depends on **two** things: high quality random numbers and protection against side channel attacks. And sufficient key length. Cryptography depends on **three** things: random numbers, protection against side channel attacks and sufficient key length... and proper distribution of keys.

    And this lamp... all I need is this random number generator and this lamp... and this one-time paddle-board....

  • (disco) in reply to FrostCat
    FrostCat:
    RichP:
    Cryptography depends on three things: random numbers, protection against side channel attacks and sufficient key length... and proper distribution of keys.

    Don't come in again.

    I didn't expect a kind of Spanish Inquisition.

  • (disco) in reply to tom103

    Crypto (or non queries) with SQL? Look, to a DBA, everything is SQL.

  • (disco) in reply to Eldelshell

    YMBNH

    No, I'm just not too fond of using acronyms for everything...

  • (disco) in reply to LB_

    The standard whcih defines

    Intentional use of transposition cipher. This is, after all about cryptography.

  • (disco)
    Oops- looks like two concurrent callerts to hex_prng_generate_block can get the same entropy
    So - where's the problem? Or does entropy mean something very different than what I learned it meant meanwhile?

    tah ^ p_dah

    I like those variable names, they sound a bit like nasty words to me.

  • (disco) in reply to PWolff
    PWolff:
    But it is Open Source! Everybody can verify that it works! Closed source code would be compromised once a bad one would find out how it works!

    Well, in this particular case, everyone can verify that it doesn't. It probably won't stop some cryptonoob from finding this on google and trying to use it -- because he got told not to roll his own, so he got something from the Interwebz.

  • (disco) in reply to Lawrence

    Or his/her boss is as avaricious as mine - "Write it yourself, or get something from teh Intarwebbz, for FREE!!!111oneeleven"

    (And the words "that stuff will cost ..." crashes the reason module of boss' brain, so the subsequent "but in the long run it will save us about 5,000 times that amount" will be forwarded to /dev/null without any prior processing.)

    Btw, welcome to TD of WTF.

  • (disco) in reply to PWolff
    PWolff:
    in the long run

    Remember, in the long run we're all dead.

    Or, less optimistically, there's no point optimising for the long run if it means that you never make it there. You've got to navigate the short run and the medium term first.

  • (disco) in reply to dkf

    So better do nothing.

    After some (binary) 1,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000 Planck times (long run) the universe as we know it won't be anymore, and within some (binary)1,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000 Planck times (short run) I can't fix it. Edit: Besides that, five years count as an eternity in business. We have experienced that with some global player (no name given, just a hint about effing obviously retarded ...) - they rotate all of their staff every three years, so they keep them not only from fraternizing but also from getting really effective at their places, and very effectively from making any decision that won't pay off before they're moved.

  • (disco) in reply to PWolff
    PWolff:
    they rotate all of their staff every three years

    Sounds like something you'd do when gardening, giving everything a good forking over with some manure every few years.

  • (disco) in reply to dkf
    dkf:
    forking over with some manure

    Some companies do that to their employees, yes.

  • (disco) in reply to dkf
    dkf:
    giving everything a good forking over with some manure

    :giggity: Scatophilia!

  • (disco) in reply to dkf
    dkf:
    Sounds like something you'd do when gardening, giving everything a good forking over with some manure every few years.

    With gardening in this context, I'd rather associate this with a tree farm, but the forking over with manure experience seems more apt if applied to employees.

    When we moved last year, we took our little apple tree (in a bucket) to our new location. It didn't grow any fruit this year. Maybe in this respect the unrooting picture works quite well.

    (Maybe we should discuss this further over there)

  • (disco) in reply to another_sam
    another_sam:
    Scatophilia

    Whatever rocks your boat.

  • (disco) in reply to PleegWat
    PleegWat:
    another_sam:
    Scatophilia

    Whatever rocks your boat.

    Only insofar as the idea of the former produces a sensation not entirely unlike violent seasickness.

  • (disco) in reply to PleegWat
    PleegWat:
    Whatever rocks your boat.

    https://www.youtube.com/watch?v=94NYWy_W9YI

  • (disco) in reply to PJH

    Author here, sorry to be late to the party. Almost everything in cryptography has good entropy has a necessary precondition. It is not a sufficient precondition. There's any number of other necessary preconditions, starting with "don't write code with buffer overflows" and continuing on.

    Timing attacks are certainly issues for online channel-based cryptographic security, which is not all crypto, just a very public face of it. In fairness, if making that distinction, then I was overbroad: decent hashes don't require entropy, until you try to use them in anything larger (signatures, HMAC constructions etc) but I decided to simplify for a WTF article down to "everything". It's glib, which is the tone I was aiming for with the article.

    Everything depends upon secure coding techniques and correct implementation. Almost everything depends upon decent entropy. Quite a lot depends upon other factors, such as side-channel concerns in some deployment scenarios, or the Adversary not having quantum computers for many other crypto-systems.

  • (disco) in reply to PWolff

    If you want a formal academic paper, with footnotes and every noun qualified with three adjectives for precision, my rates start at $astronomical and go upwards depending upon my mood. :moneybag: In the meantime, I take it as given that in the context of cryptography, there's a common understanding that entropy sources are used for providing unpredictability in randomness and that predictability has Very Negative Consequences. :)

  • eric bloedow (unregistered)

    this reminded me of an old book, "cloak and cipher", about the history of cryptography and code-breaking...some people got the "bright" idea of using the message as it's own key...there were 2 versions of this, BOTH stupid: one version made it impossible to decode the message unless you knew EXACTLY what the message WAS, the other was as insecure as using a 1-digit key, it was possible to DECODE the message with itself!

Leave a comment on “Elliptical Curveball”

Log In or post as a guest

Replying to comment #:

« Return to Article