6 ms·

Exactly. its a password limited to 4 digits. And why? That gives you no more than 14 bit security even using a decent system like PBKDF2. Which i see no mention

by mSparks 10y ago

Exactly. its a password limited to 4 digits. And why? That gives you no more than 14 bit security even using a decent system like PBKDF2. Which i see no mention of. secrets are just that - secret. The only reason I know of that secrets need sharing is when you are running a key escrow system. Other than that secrets are locked away and used as rarely as possible. Never ever ever transmitted from machine to machine. Thats the key problem in crypto (pun intended). Stuff you transmit cant and wont stay secret.

moby_click 10y ago
Having read a little further, I think offline attacks are possible and 4 digits alone are useless today but that still does not weaken the security level. You need a key, whether you choose to use a password or not. Correct me if I'm wrong but I don't see secret keys transmitted. The DTAs issue shares of the secret keys that are then combined. Also, transmitting secrets really is a motivating use case for cryptography.
- mSparks 10y ago
  they are creating a secret key by sending chunks of secret keys (with a mention of a blockchain database - not sure why). Or at least thats what i saw in the code comments. secret in cryptography has a very special meaning - it refers to the part of the communication process you dont want visible. encryption is actually mostly a solved problem. There are several good algorithms which are fine with no real problems. The problems are all in establishing keys. For that there are currently only two choices in use. ecdh. which all the standard curves appear to be backdoored. and rsa, which the russians reckon they have broken. the dta is just another key sharing scheme. needed. but not one that gives up on all the comsec we have gained so far. do you not find it dishonest that they claim for example, that the uk government is using it already, but then it turns put it doesn't actually exist beyond a few lines of poc code.
  - chetanahuja 10y ago
    "ecdh. which all the standard curves appear to be backdoored" This is a pretty serious assertion to make as a throwaway comment. You're talking about the NIST sponsored constants suspected of being backdoored. ( https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/ ) That's the reason Curve22519 (defined by djb, completely independent of any NIST involvement) has become popular and is being widely used as default in major ECDH implementations (https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Curve25519 ). As close to a "standard" as you'd find today that nobody believes to have known weaknesses or backdoors.
    - mSparks 10y ago
      im mobile and traveling. tried to find my links to research but not in my mobile bookmarks. there is a great page somewhere that lists each curve --- edit you found it: https://safecurves.cr.yp.to https://safecurves.cr.yp.to for reference google (pdfs so cant get links from google mobile): security dangers of nist curves and also the reasoning behind the curve chosen for bitcoin. so edit 2: just, yes. but note the safecurves quote " The core problem is that if you implement the standard curves, chances are you're doing it wrong:"
      - chetanahuja 10y ago
        Please stop spreading FUD. The quote from safecurves you posted is actually describing the very reason safecurves exists in the first place. And it lists the curves that are safe to use. "Most of these attacks would have been ruled out by better choices of curves that allow simple implementations to be secure implementations. This is the primary motivation for SafeCurves. The SafeCurves criteria are designed to ensure ECC security, not just ECDLP security." Also you completely ignored them main part of my earlier comment. The actually widely adapted, curve25519 by djb (who's also the author of that safecurves page) with no currently known weaknesses (and needless to say, no backdoors either).
        mSparks 10y ago
  - moby_click 10y ago
    I found some mention of a blockchain here: https://github.com/milagro-docs/docs.milagro.io-english/blob/a4d8088150183c48fe7184bb5a59557a965d78d5/milagro-a-case-for-something-new-part-2.md https://github.com/milagro-docs/docs.milagro.io-english/blob... and here: https://github.com/milagro-docs/docs.milagro.io-english/blob/a4d8088150183c48fe7184bb5a59557a965d78d5/milagro-distributed-trust-proposal.md https://github.com/milagro-docs/docs.milagro.io-english/blob... For my taste, that's tying way too many systems and thinking about the operation and how to get a chain of trust out of it boggles the mind. edit: Since you show enthusiasm for the topic, I'd like to share the most reasonable approaches for key distribution I found so far: http://named-data.net/publications/schematizing_trust_ndn/ http://named-data.net/publications/schematizing_trust_ndn/ and http://named-data.net/publications/techreports/ndn-0034-2-nac/ http://named-data.net/publications/techreports/ndn-0034-2-na...
    - mSparks 10y ago
      Nice. I've found openpgp to be fit for purpose, there's even a js version for apps now: https://openpgpjs.org/ https://openpgpjs.org/ But still run into US import/export control problems with decent encryption. IMHO we can never have a standard as long as the US is involved in creating the standard, with obviously something never standing a chance of becoming a standard without the US being involved.

by mSparks 10y ago

moby_click 10y ago

Having read a little further, I think offline attacks are possible and 4 digits alone are useless today but that still does not weaken the security level. You need a key, whether you choose to use a password or not. Correct me if I'm wrong but I don't see secret keys transmitted. The DTAs issue shares of the secret keys that are then combined. Also, transmitting secrets really is a motivating use case for cryptography.

mSparks 10y ago
they are creating a secret key by sending chunks of secret keys (with a mention of a blockchain database - not sure why). Or at least thats what i saw in the code comments. secret in cryptography has a very special meaning - it refers to the part of the communication process you dont want visible. encryption is actually mostly a solved problem. There are several good algorithms which are fine with no real problems. The problems are all in establishing keys. For that there are currently only two choices in use. ecdh. which all the standard curves appear to be backdoored. and rsa, which the russians reckon they have broken. the dta is just another key sharing scheme. needed. but not one that gives up on all the comsec we have gained so far. do you not find it dishonest that they claim for example, that the uk government is using it already, but then it turns put it doesn't actually exist beyond a few lines of poc code.
- chetanahuja 10y ago
  "ecdh. which all the standard curves appear to be backdoored" This is a pretty serious assertion to make as a throwaway comment. You're talking about the NIST sponsored constants suspected of being backdoored. ( https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/ ) That's the reason Curve22519 (defined by djb, completely independent of any NIST involvement) has become popular and is being widely used as default in major ECDH implementations (https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Curve25519 ). As close to a "standard" as you'd find today that nobody believes to have known weaknesses or backdoors.
  - mSparks 10y ago
    im mobile and traveling. tried to find my links to research but not in my mobile bookmarks. there is a great page somewhere that lists each curve --- edit you found it: https://safecurves.cr.yp.to https://safecurves.cr.yp.to for reference google (pdfs so cant get links from google mobile): security dangers of nist curves and also the reasoning behind the curve chosen for bitcoin. so edit 2: just, yes. but note the safecurves quote " The core problem is that if you implement the standard curves, chances are you're doing it wrong:"
    - chetanahuja 10y ago
      Please stop spreading FUD. The quote from safecurves you posted is actually describing the very reason safecurves exists in the first place. And it lists the curves that are safe to use. "Most of these attacks would have been ruled out by better choices of curves that allow simple implementations to be secure implementations. This is the primary motivation for SafeCurves. The SafeCurves criteria are designed to ensure ECC security, not just ECDLP security." Also you completely ignored them main part of my earlier comment. The actually widely adapted, curve25519 by djb (who's also the author of that safecurves page) with no currently known weaknesses (and needless to say, no backdoors either).
      - mSparks 10y ago
- moby_click 10y ago
  I found some mention of a blockchain here: https://github.com/milagro-docs/docs.milagro.io-english/blob/a4d8088150183c48fe7184bb5a59557a965d78d5/milagro-a-case-for-something-new-part-2.md https://github.com/milagro-docs/docs.milagro.io-english/blob... and here: https://github.com/milagro-docs/docs.milagro.io-english/blob/a4d8088150183c48fe7184bb5a59557a965d78d5/milagro-distributed-trust-proposal.md https://github.com/milagro-docs/docs.milagro.io-english/blob... For my taste, that's tying way too many systems and thinking about the operation and how to get a chain of trust out of it boggles the mind. edit: Since you show enthusiasm for the topic, I'd like to share the most reasonable approaches for key distribution I found so far: http://named-data.net/publications/schematizing_trust_ndn/ http://named-data.net/publications/schematizing_trust_ndn/ and http://named-data.net/publications/techreports/ndn-0034-2-nac/ http://named-data.net/publications/techreports/ndn-0034-2-na...
  - mSparks 10y ago
    Nice. I've found openpgp to be fit for purpose, there's even a js version for apps now: https://openpgpjs.org/ https://openpgpjs.org/ But still run into US import/export control problems with decent encryption. IMHO we can never have a standard as long as the US is involved in creating the standard, with obviously something never standing a chance of becoming a standard without the US being involved.