
Milagro: Distributed Cryptosystem for Cloud Computing - based2
http://milagro.incubator.apache.org/
======
mSparks
I see a lot of talk and little substance.

"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...](https://github.com/apache/incubator-milagro-
crypto/blob/master/java64/TestMPIN.java) /* Client and Server are issued
secrets by DTA */

HELL NO.!.!.!.!.!

~~~
chetanahuja
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.

~~~
mSparks
:( sounds terrible.

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).

~~~
chetanahuja
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)

------
zmanian
Okay, here is what I think this is

\- 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.

~~~
tptacek
Rogaway has some concerning things to say about IBE here:

[http://web.cs.ucdavis.edu/~rogaway/papers/moral-
fn.pdf](http://web.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf)

It'd be a tangent, except that Milagro proposes to alter the TLS handshake to
accommodate their scheme.

~~~
moby_click
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.

------
chetanahuja
[http://docs.milagro.io/en/milagro-a-case-for-something-
new-p...](http://docs.milagro.io/en/milagro-a-case-for-something-new-
part-1.html)

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.

[http://www.infoworld.com/article/3016733/application-
develop...](http://www.infoworld.com/article/3016733/application-
development/in-search-of-a-cure-for-slow-mobile-downloads.html)

------
kbaker
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?

~~~
shawn-butler
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.

------
whatnotests
Great.

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.

(Had to get that off my chest. Thanks.)

~~~
T-A
Looks like Python to me: [https://github.com/apache/incubator-milagro-mfa-
server](https://github.com/apache/incubator-milagro-mfa-server)

The core MFA library seems to be C, with a bunch of implementations
(wrappers?) in Java, C#, JS, Python, Go and Swift:

[https://github.com/apache/incubator-milagro-
crypto](https://github.com/apache/incubator-milagro-crypto)

~~~
whatnotests
I admit I didn't even look at any code. I've been conditioned to have
expectations in-line with my rant.

------
Xeoncross
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?

------
kbart
_" 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?

------
whatnotests
Milagro is Spanish for "Miracle".

------
rekoros
Excellent [cheap] tequila, by the way!

