Re: [foaf-protocols] New attack plucks secrets from HTTPS-protected pages

On 4 August 2013 22:54, Peter Williams <home_pw@msn.com> wrote:

> one of the things that came “before its time” is making a come back. One
> has to play the “factoring” game “sensibly” - much as one has to allow
> security committees to be stacked with agendized-folks with money (that
> pays for core research, too).
>
> If you look in dotNet, there is a particular ws-trust/ws-security binding.
> Its compatible with java, etc (circa 5 years ago, when Java security
> mattered.) More importantly, its compatible with apache libs, these days.
> In short, the saml process of delivering a per-recipient encrypted proof
> key (within the signed XML) was leveraged so that it delivered a client’s
> EPHEMERAL rsa key. Any client proxy (and you can have n of those, and being
> generated for a given service instance exposing service&policy-metadata)
> can maintain 1000 of these in its RSA security token cache; before keys
> overwrite cache slots. Typically, the client signs web service call headers
> (timestamp, and address) using the RSA key, rather than signing with hmac
> similarly.
>
> So, if you are worried about your 512 bit RSA being factored in 500 hours,
> (or 50, or 5)  why not give it a life time of 500mS, and just use 1000 of
> them? There is built in probability drive in every CPU...
>

Ephemeral keys are a nice option.  But long lived keys also have advantages:

1. You can build up a reputation for each key
2. You can build cachable relationships between your identity and your key
3. You can store virtual currency against a key, and transfer or prove
ownership by signing
4. You can spend time generating a key via proof of work algorithm to show
you're not a sock puppet

So there's a trade off between security and key management.


>
>
>
>
> *From:* Melvin Carvalho
> *Sent:* Sunday, August 4, 2013 10:14 AM
> *To:* Peter Williams
> *Cc:* public-webid, foaf-protocols@lists.foaf-project.org
>
>
>
>
> On 4 August 2013 17:16, Peter Williams <home_pw@msn.com> wrote:
>
>> nothing new.
>>
>> so use compression that is BUILT IN to the SSL process. IT is properly
>> tuned. It properly uses the record layer so record-layer AND security
>> handshake boundaries are “application aware”. It does make SSL more of an
>> internet (i.e. layer 4 peer entity layer) concept, than a webby layer
>> 7 “hypermedia concept”, though.
>>
>> But, note that compression and SSL *was* patented (and continuations may
>> still be). It was proactively-patented for national security reasons; both
>> good and bad. The good one was to stop folks doing it completely wrong
>> (this was at a time when VeriSign required SSL vendors to undergo a basic
>> software audit to be allowed to embed root keys, a governance technique
>> designed to “stop folks being stupid about basic comsec that would
>> undermine the value of the [VISA] brand attached to certs”). The bad one
>> was the usual CI caveat reason - minimize the distribution of knowhow about
>> military cryptananalysis methods. We are all still thinking 1980s, even in
>> 1994, one should recall.
>>
>> A webid IDP is perfectly proper place to apply better knowhow, as is
>> ws-trust STS IDP that leverages clients certs at layer 4 to authorize
>> SAML/JWT token minting. These are proper places to apply strong crypto
>> knowhow, speaking in terms of social politics.
>>
>> Sent from Windows Mail
>>
>
> Here's a great presentation about cracking RSA.  Perhaps we will need
> bigger keys or to switch to ECC sooner than we thought ...
>
> http://www.slideshare.net/astamos/bh-slides
>
>
>>
>> *From:* Melvin Carvalho
>> *Sent:* Sunday, August 4, 2013 7:10 AM
>> *To:* public-webid, foaf-protocols@lists.foaf-project.org
>>
>>
>> http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/
>>
>
>