On 3/01/14 22:42 PM, coderman wrote:
use case is long term (decade+) identity rather than privacy or
session authorization.
Long term identity is not a concept in a vacuum. Identity in software
business always relates to other people, your identity is like the sum
of the thoughts that *others have about you* unlike psychology where
identity is a concept of how you think about yourself.
So you have to consider (a) everyone else and (b) how everyone else
interacts with you.
Which in today's world is pointing to the phone. If we're talking the
identity on the phone, we're now talking about 2 or more things,
horizontally: an app by itself, or an app that integrates vertically
with the telco (SIM card). We can also bifurcate vertically with Apple
v. Android, and also-rans.
The point being that identity of the future is constrained to the
platform that everyone lives on. The western/past was your laptop and
PGP and online banking. The all-world/future is the phone and mPesa
style mobile money and apps like SnapChat.
The phone is a really sucky platform for security purposes. The end
conclusion of this argument is that ... it doesn't matter much what
strength/type key you're using because you have to deal with the platform.
As an example. In my business, we have money on phones, including
shared accounts and treasurer management and other stuff. This gets
hairy if say /the treasurer loses her phone/. This is a real, live,
every day issue.
What to do?
(skipping long analysis)... we have to be able to recover the entire app
onto a new phone and carry on as if nothing had happened. To do this,
we have to migrate the swamp of server escrow (cryptocloud! got it sorta
working last night) and encryption against servers and 4 digit pins and
finger swipes and cooperative arrangements with people who today are
your most trusted friends and tomorrow have stolen all your money.
See where this is going? The conclusion is, it doesn't matter a damn
what strength key you use. In practice, we use what tickles us as
geeks, and what works well with our software design.
eternity key signs working keys tuned for speed with limited secret
life span (month+). working keys are used for secret exchange and any
other temporal purpose.
you may use any algorithms desired; what do you pick?
Curve3617+NTRU eternity key
Curve25519 working keys
ChaCha20+Poly1305-AES for sym./mac
?
I'm using RSA1024/AES128/SHA1-HMAC at the moment, I could use RSA512 and
I'd be within my analysed threat model and designed security model.
I'll switch over at some stage to CurveLatest/ChaCha20+Poly1305 ... but
it won't make a jot of difference to my identity. I'll do it coz it's cool.
this assumes key agility by signing working keys with all eternity
keys, and promoting un-broken suites to working suites as needed. you
cannot retro-actively add new suites to eternity keys; these must be
selected and generated extremely conservatively.
other questions:
- would you include another public key crypto system with the above?
(if so, why?)
No. RSA then EC is what I'll do. I don't know about NTRU, but I'm the
guy who always says less is best.
- does GGH signature scheme avoid patent mine fields? (like NTRU patents)
- is it true that NSA does not use any public key scheme, nor AES, for
long term secrets?
Now that is a question! Yes, let's hear more about their use of Public
Key [0]. This is now a validated issue, because Suite B and EC is under
a cloud by the NSA's actions. Anyone?
- are you relieved NSA has only a modest effort aimed at keeping an
eye on quantum cryptanalysis efforts in academia and other nations?
lol... What was also funny was that paper had a lot of TS over it. Nice
to know that these guys are carefully covering up the bleeding obvious.
Maybe that's why the newspaper released it over New Year's Day, for
humour.
iang
[0] http://financialcryptography.com/mt/archives/001451.html
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
