[nycbug-talk] RSA/DSA for encryption: has it's time come?

George Rosamond george at ceetonetechnology.com
Tue Aug 27 22:07:26 EDT 2013


Okan Demirmen:
> On Tue, Aug 27, 2013 at 9:50 PM, George Rosamond
> <george at ceetonetechnology.com> wrote:
>> Okan Demirmen:
>>> On Tue, Aug 27, 2013 at 7:24 PM, George Rosamond
>>> <george at ceetonetechnology.com> wrote:
>>>> Okan Demirmen:
>>>>> On Wed, Aug 7, 2013 at 9:58 AM, Isaac (.ike) Levy
>>>>> <ike at blackskyresearch.net> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I'd love to know what people's thoughts are on the state of older
>>>>>> RSA/DSA encryption, versus the future of eliptic curve ECDSA:
>>>>>>
>>>>>> http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/
>>>>>>
>>>>>> --
>>>>>> A few years ago, a number of us were wary of the brand-spankin'-new ECC
>>>>>> crypto for use in SSH public keys.  And then months later, there were
>>>>>> some ECDSA/ssh implementation problems exposed:
>>>>>>
>>>>>> http://marc.info/?l=openssh-unix-dev&m=130613765816780&w=2
>>>>>>
>>>>>> So, that was 2 years ago, ECDSA implementations are now no longer in
>>>>>> their infancy.
>>>>>>
>>>>>> --
>>>>>> What are people's thoughts on the practicality of starting to use ECDSA
>>>>>> keys?
>>>>>>
>>>>>> Has anyone here seen their use mandated over RSA/DSA in a business setting?
>>>>>> Has anyone just jumped into ECDSA bliss, and not looked back?
>>>>>
>>>>> Not that this might mean much, but I use them.
>>>>>
>>>>> As for policies in a business setting; I gather such technical
>>>>> policies are made by people like you, so it's likely up to what folks
>>>>> like you write in said policies :)
>>>>
>>>> So I'm in the process of getting a client to pickup better practices
>>>> with SSH, and found out even OSX 10.7.5 doesn't support ecdsa.
>>>>
>>>> AFAIK, Putty doesn't either yet, and I doubt SSH for Windows does either.
>>>
>>> So many things there just blew my mind...but OK, I'll mend myself later :)
>>>
>>> I'd simply recommend to them to start using keys, regardless of type -
>>> get them in the habit, and whenever these other tools get support for
>>> the new fangle stuff, just add to authorized keys and migrate.  Just
>>> get them in the habit of thinking about keys instead.  I'm sure you
>>> know all this....
>>
>> Like most of the sane world, they are using keys.. with passwds.  I'm
>> going the next step.
> 
> I figured.  So here's my issue, and you can call it a double-edged
> sword if you want - one is storing private keys on client that lives
> in an extremely hostile environment - that is the vector that needs to
> be addressed.  Sure, remove keys and use passwords instead - then
> we're back to that debate.
> 
> Double-edged? Maybe, but think about the use-case and attack vectors -
> that's all I'm saying.

So this would be much easier if we could have IRC synchronized with
talk@  ;)  (efnet #nycbug)

Security and its related fields are often relative, and dependent upon
adversaries in question.  And part of the relative and cumulative issue
is with user behavior.

Don't require a strict security policy on passwds and 12 other things
overnight.  Once they figure out how to create and remember multiple
long passwds, then you build off that, for instance.  So you have them
comfortably using SSH, then keys.  And keys with passwds doesn't seem so
initimidating.

g




More information about the talk mailing list