SSH Agent keys >4096 bit?

[Milo]

On 05/05/2012 02:20 PM, Robert J. Hansen wrote:
> On 5/5/12 4:37 AM, Milo wrote:
>> This is futile. I'm reminding you that you are giving one example of
>> rarely used algo (so _niche_ and _out_of_mainsteam_) to back your
>> statement "that there is good amount of them".
> 
> "Rarely used" is not the same as "proof of concept."  Your statement did
> not mention "out of the mainstream."  No moving the goalposts, please.

I mentioned some attributes of ciphers which are generally out of
concern because - e.g. - they aren't widely used. I understand term
"niche cipher" as somehow overlapping and with similar meaning as "out
of mainstream". And I used `,' logical disjunction. Hope my intention is
clear now ;)

> You were also arguing that QC would shred all or most asymmetric
> systems.  It turns out that no, QC doesn't, can't, won't: it will only
> shred the discrete logarithm problem or problems isomorphic to it, such
> as integer factorization.  Other systems, whether multivariate, lattice
> or Goppa code-based systems, won't be.  (Well -- lattice systems might:
> right now they're only conjectured to be outside of BQP.  But Goppa
> codes are well-known for being NP-hard.)

after Wikipedia:

"Derivatives of Shor's algorithm are widely conjectured to be effective
against all mainstream public-key algorithms including RSA,
Diffie-Hellman and elliptic curve cryptography". I'm not considering all
of them. I used more general expression.

> If you're now claiming that I've only presented one system, well, that's
> because I wasn't aware you were looking for the kitchen sink.  Do some
> reading on post-quantum cryptography.  As I read the tea leaves the new
> hotness is in the lattice-based systems, but I think systems based on
> Goppa codes will continue to surprise us.

Thanks for this tip.

>> In context of this discussion your statement is ridiculous. At one point
>> you even agreed on using 256-bit symmetric cipher for 50+ years
>> confidentiality (not guaranteed but at least assumed or expected) and
>> now you are turning all things around.
> 
> Not at all.
> 
> If you're securing nuclear weapon release codes and you ask me, "is it
> okay if I use 256-bit crypto?", I will blink a few times and back away
> slowly from the thermonuclear weapon while nodding vigorously and making
> noises about how they must be secure for fifty years or more, oh and is
> that thing releasing radiation right now and where do you plan on
> storing this so I can live far away from it.
> 
> If you're securing your recipe book and you ask me, "is it okay if I use
> 256-bit crypto?", I will smile and pleasantly explain that, really, past
> about 112 bits it's just an exercise in paranoia.  Use whatever you
> like, but managing your keys will be a much more important task than
> deciding between 3DES and AES256.
> 
> And if you're telling everyone that AES256 will give them a larger
> security margin than 3DES, well... at that point I'm going to start
> pointing and laughing.  There is enough misinformation and half-truths
> floating around the crypto-hobbyist's world: I consider it to be a
> polite act towards the community to challenge this when I encounter it.

And again we are going through field of evaluating data's value. I don't
think I have something more to add here. I understand your point and
possibly person who will ask you such question(s) can follow your advice
without harm.

But I don't think that biggest proponents of longer asymmetric keys are
such kind of guys. Your approach advised to this hypothetical person is
more like tao of using encryption then set of objective rules.

>> 3des is old
> 
> Old software engineering joke: "legacy code (n): code that hasn't
> crashed in the last 40 years."
> 
> You call 3DES old.  I call it quite well tested in demanding production
> environments.  More often than not when you swipe a credit card, 3DES is
> being used to secure the transaction at various critical points.

But lacking bigger margin of security because of limited key space. See
NIST advisories for 3des keying methods (see: 50 years+ security
problem; yeah, some people are quite suspicious about them).

>> and it's providing something like 80-112 bits of security.
> 
> The best attack against three-key 3DES requires almost 10^27 bytes of
> RAM.  This is completely impractical, as even the inventor of the attack
> has said.  To the best of our knowledge there is no effective way to
> reduce three-key 3DES, which is the only NIST-approved version, below
> 168 bits of key space.
> 
>> It has ugly history of keying hacks and some aren't back compatible -
> 
> ... I have absolutely no idea what you're talking about here.  None.

Check 3des history for details (
https://en.wikipedia.org/wiki/3des#Keying_options ).

-- 
Regards,
Milo