"You can have 128bit security with a 4 digit pin"....
No, No you can't. A 4 digit pin is 14 bit security. Any system is only as secure as its weakest link.
It's not a password it's a pin...
Dear god, how have we not got past this yet.
While it's good to see an acceptance that iot is fundamentally unworkable on current infrastructure. I am a long way from being convinced this will be it's saviour.
I just learned about Milagro through this submission and only looked at a fraction of the docs but as someone who is not a cryptographer but put some effort into understanding pairing based cryptograph, I find the documentation excellent so far.
> No, No you can't. A 4 digit pin is 14 bit security. Any system is only as secure as its weakest link.
As far as I understand it, the PIN is used to secure a secret key for a 128bit security cryptosystem against key compromise. Like password protection on ssh keys, this provides stronger security than unprotected keys but I think this PIN is actually part of an interactive proof to protect against offline attacks.
The downside of Identity Based Encryption is that you need a master secret key (aside: I think we shoud find a less loaded term like root secret key) to derive the client secrets. The DTA is a way to avoid a single authority in posession of this root secret through secret sharing. Sharing in secret sharing is not copying but splitting into shares. I'm not yet sure if it works like I think it works but I think they use secure multiparty computation to use a shared root secret to derive shares of the client secrets that the clients combine to obtain their secret. That would be really awesome and about the best we can do before more powerful cryptography (functional encryption, fully homomorphic encryption etc.) becomes practical.
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.
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.
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.
Nice.
I've found openpgp to be fit for purpose, there's even a js version for apps now:
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.
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 ). As close to a "standard" as you'd find today that nobody believes to have known weaknesses or backdoors.
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:
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:"
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).
Confused.. Safecurves exists because all the standard curves appear to be backdoored. Curve25519 is not a standard curve. How is this FUD?
Curve25519 was first released by Daniel J. Bernstein in 2005,[7] but interest increased considerably after 2013 when it was discovered that the NSA had implemented a backdoor into Dual EC DRBG. While not directly related,[8] suspicious aspects of the NIST's P curve constants[9] led to concerns[10] that the NSA had chosen values that gave them an advantage in factoring[11] public keys.[12]
"Safecurves exists because all the standard curves appear to be backdoored. Curve25519 is not a standard curve.
This was your original stanza that I objected to:
"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."
You were insinuating that basically there's no safe way to establish secrets (using some form of ecdh). While there absolutely is. Here's the list of open source packages using (safe) Curve25519 :
->You were insinuating that basically there's no safe way to establish secrets (using some form of ecdh). While there absolutely is.
I'm complaining there is no STANDARD & SECURE way to establish secrets (unlike say AES or Rabbit). That's not quite the same thing. Nearly everything has been designed to fail from the very beginning. Or are you saying you still trust "the experts" after everything that's happened?
Curve 25519 does not meet the ECRYPT recommendations of a min keylength of 512bits for Ellyptic Curves
https://www.keylength.com/en/3/
Curve 25519 at 128bit provides:Very short-term protection against small organizations
Should not be used for confidentiality in new systems
->OpenSSL since version 1.1.0
Probably the very worst example of an implementation you could give. OpenSSL version 1.1.0... Really????
not true - the public blockchain means that cracking the encryption is only a very small part of such problem. You also need to convince all the other peers that you cracked it first
Because Bitcoin IS cracking encryption - bitcoins are assigned by doing exactly that.
In Bitcoin, a private key is usually a 256-bit number (giving a key length of at least 512 bits)
On the other hand, I'm sure all the MTgox customers will be happy with your assertion that their $450 million of missing/stolen funds allegedly stolen straight out of the MtGox hot wallet over time, beginning in late 2011. are actually still safe. Not sure they'll agree however.
There's an accompanying talk (and slides) that was given at apachecon earlier in the summer. I heard some of the talk (from the OP linked page.. not in person) . The essence of DTA seems to be that it creates key-pairs for both ends of the communication (client and server), multiple DTA's combine to create the private keys and the keys are being distributed to the client side through some out-of-band "protected" channel.
The use-case is not billions of browsers connecting to millions of webservers (as in PKI based TLS) but a small number of controllable client end points (a native app binaries on mobile or IoT devices) connecting to a handful of servers.
The mental image I came away with (not sure if it's 100% correct) is think of an distributed infrastructure to create SSH key-pairs (where PIN is equivalent to the passphrase for the private key).
Wonder if anybody from the Milagro team feels like responding to this thread. It's on HN front-page right now and would be a great chance for the creators to engage with the community.
I went from eurphoria, to cynicism, to total foil hat in less than an hour.
This sounds incredibly like having multiple points of failure (what happens if one of the DTAs is unavailable?) and no public key cryptography (DTAs creating the secret key).
I'll freely admit to neither remotely being a security expert nor being completely confident I got the details right from listening to the talk. It really would help if someone from the actual team engaged the community here (or some other appropriate forum)
- It is a straight forward combination of two forms of encryption from pairing cryptography world. Identity Based Encryption and Threshold Encryption.
- In Identity based encryption, your public key and private key is generated by an identity provider based on an identity string provided to it. This allows encrypting messages to party that hasn't yet recieved the keys. This work has been around for ages.
- Milagro proposes to distribute the trusted third party by having multiple identity providers. The public key and private key are formed from a threshold encryption/ decryption procedure.
Thanks for the link. I think I saw his talk about the topic and that milagro resonates well with it. The use of threshold encryption works around an unfortunate aspect of IBE and is practical today.
PS: As I grow older, I become more accepting of the fact that state power is not going anywhere soon. If multiple authorities (preferably under different jurisdictions) can be coerced into deriving client secrets for law enforcement with proper oversight, like public visibilty of the amount intervention and auditabilty by data protection officers, that would be acceptable to me and better than outlawing homebrewed encryption or more drastic backdooring measures.
Finally. We need for the security community to jolt themselves out of their unhealthy focus on PKI based TLS as the be-all and end-all for client-server communication... which has been driven by web browsers as the main use-case for the last couple of decades -- to something better and more secure for the new mobile world. Not sure Milargo presents a complete solution but hopefully it sparks a dialog for better solutions for native apps and IoT world.
There is little information about what this is exactly on the site (but lots of words.) And since their proposal is just "TBC" at the moment, I'll see if I can give it a shot...
Milagro uses 'Pairing-Based Cryptography' to do better decentralization of trust. This concept was new to me, briefly it seems like it uses special constructs of elliptic curves to provide zero-knowledge proofs and Diffie-Hellman style key exchange.
So, instead of using CAs and certificates to prove identity, this system would use indnividual pairings for authorization and would end up being more decentralized.
With M-PIN that is a big part of this library, you can have signatures but also upgrade to full key agreement and PFS, with a standard protocol that has been around since 2002.
What I am unsure about is how the decentralization will work, especially compared to just having CAs cross-sign keys. Seems like you will always need to ultimately have some trust anchor somewhere? Or can have a Perspectives-like 'network notary' system?
Milagro envisions a new class of cryptographic service providers called Distributed Trust Authorities, or D-TAs for short.
The purpose of a D-TA is to independently issue shares, or fractions, of cryptographic keys to Milagro clients and servers and application endpoints which have embedded Milagro cryptographic libraries. D-TAs operate independently from each other, are isolated in totality, and completely unaware of the existence of other D-TAs.
In practice, a Distributed Trust Authority (D-TA) framework would split the functions of a pairing-based key generation server into three services, each D-TA issuing thirds of private keys to distinct identities.
Now, if instead of starting with a half-baked implementation in Java that involves 36 configuration files and an artisanally sculpted Maven build, how about we make a spec, in terms of API docs and compliance tests.
Anything conforming to the spec which passes the tests is considered a valid implementation.
So one of the key benefits of this system is that two (or more) distributed CA's issue the certificate so if one is compromised (or the government demands access) the server (and client) are still safe?
"Apache Milagro (incubating) establishes a new internet security framework purpose-built for cloud-connected app-centric software and IoT devices that require Internet scale."
Are they trying to achieve some kind of 'most buzzwords per sentence' world record or smth?
"You can have 128bit security with a 4 digit pin"....
No, No you can't. A 4 digit pin is 14 bit security. Any system is only as secure as its weakest link.
It's not a password it's a pin... Dear god, how have we not got past this yet.
While it's good to see an acceptance that iot is fundamentally unworkable on current infrastructure. I am a long way from being convinced this will be it's saviour.
EDIT:Furthermore: https://github.com/apache/incubator-milagro-crypto/blob/mast... /* Client and Server are issued secrets by DTA */
HELL NO.!.!.!.!.!