Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.computer.security > #5720

Re: Socat vulnerability shows that crypto backdoors can be hard to spot

From Nathan Hale <nobody@remailer.org.uk>
References (5 earlier) <n933d4$j9l$1@dont-email.me> <Z5Cdndw6QauMyCjLnZ2dnUU7-bOdnZ2d@earthlink.com> <n93n7k$h66$1@dont-email.me> <hPudndhhluxeHyjLnZ2dnUU7-cednZ2d@earthlink.com> <n957e3$4nq$1@dont-email.me>
Subject Re: Socat vulnerability shows that crypto backdoors can be hard to spot
Message-ID <7113c6d129d1fa115cb28c98c8bb8330@remailer.org.uk> (permalink)
Date 2016-02-07 07:28 +0000
Newsgroups alt.hacker, alt.privacy.anon-server, comp.os.linux.advocacy, comp.sys.mac.system, alt.computer.security
Organization dizum.com - The Internet Problem Provider

Cross-posted to 5 groups.

Show all headers | View raw


In article <n957e3$4nq$1@dont-email.me>
William Unruh <unruh@invalid.ca> wrote:
>
> On 2016-02-06, Big Bad Bob <BigBadBob-at-mrp3-dot-com@testing.local> wrote:
> > On 02/05/16 18:53, William Unruh so wittily quipped:
> >> On 2016-02-06, Big Bad Bob <BigBadBob-at-mrp3-dot-com@testing.local> wrote:
> >>> On 02/05/16 13:15, William Unruh so wittily quipped:
> >>>> On 2016-02-05, Big Bad Bob <BigBadBob-at-mrp3-dot-com@testing.local> wrote:
> >>>>> On 02/04/16 18:51, William Unruh so wittily quipped:
> >>>>>> On 2016-02-04, Anonymous <anonymous@foto.nl1.torservers.net> wrote:
> >>>>>>> In article <n9018u$ufq$1@dont-email.me>
> >>>>>>> William Unruh <unruh@invalid.ca> wrote:
> >>>>>>>>
> >>>>>>>> On 2016-02-04, Anonymous <anonymous@foto.nl1.torservers.net> wrote:
> >>>>>>>>> Developers of the Socat networking tool have fixed a
> >>>>>>>>> cryptographic flaw that left communications open to
> >>>>>>>>> eavesdropping for over a year. The error is so serious that
> >>>>>>>>> members of the security community believe it could be an
> >>>>>>>>> intentional backdoor.
> >>>>>>>>>
> >>>>>>>>> http://www.csoonline.com/article/3029369/security/socat-
> >>>>>>>>> vulnerability-shows-that-crypto-backdoors-can-be-hard-to-
> >>>>>>>>> spot.html?google_editors_picks=true
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It contains a stupid statement. "Checking whether a 1024-bit number is
> >>>>>>>> prime is doable, but is not exactly straightforward." It is very
> >>>>>>>> straightforward, and very doable (RSA key generation does 10s to 100s in a
> >>>>>>>> very short time.) While probabilistic even deterministic checking is not
> >>>>>>>> that hard. Certainly the lesson is that a long term key should be
> >>>>>>>> checked by someone other than the proposer.
> >>>>>>>
> >>>>>>> Couldn't you just fix this yourself by generating a new key and
> >>>>>>> using it?
> >>>>>>
> >>>>>> Both sides need to use the same prime. In this case I guess they insist
> >>>>>> on both using their "prime" (which is public knowledge). But their prime
> >>>>>> was not prime meaning that deriving g^ab from g^a and g^b (all mod p, the
> >>>>>> so called prime) became easier. Ie, no they want you to use theirs.
> >>>>>>
> >>>>>>>
> >>>>>>>> I did not even know that DH would work with a non-prime key. RSA I
> >>>>>>>> believe would fall over if you used a non-prime key.
> >>>>>>
> >>>>>> I guess it does work. All you use p for is to generate a key which you
> >>>>>> can use in some other program (eg AES).
> >>>>>>
> >>>>>> In RSA you actually use the primes to encrypt, and if they are not
> >>>>>> primes, there is a chance (how big?) that the decryption of the
> >>>>>> encryption will not give the original message.
> >>>>>
> >>>>> I suspect it's actually simpler than that - multiple key solutions for
> >>>>> non-prime [hence, non-secure]
> >>>>>
> >>>>>
> >>>>
> >>>> Depends on how hard it is to find one of those solutions. If it for
> >>>> example only takes half the work to find one of two vs the time to find
> >>>> a unique one, that is hardly less secure. If there are or order e^p more
> >>>> solutions, then it would of course be trivial. But it is certainly
> >>>> somewhere in between. Does it depend on the size of the largest factor?
> >>>> the smallest factor? Ie, knowing g^a and g^b (mod p) how mush easier is
> >>>> it to find g^ab (mod p)  if p is composite than if it is prime?
> >>>>
> >>>>>
> >>>
> >>> yeah, some people that like mathematics for the sake of mathematics
> >>> might want to derive that.  Me, I just think in practical terms:  if it
> >>> takes half as many bots or half as many [stolen] cloudy threads to crack
> >>> my key, or it's done in HALF the time because multiple solutions exist
> >>> [due to use of non-prime], I think I'll take the extra few bits and use
> >>> primes...
> >>>
> >> Since the time might be a billion times the age of the universe, that
> >> this would be half a billion times the age of the universe, your
> >> position would be silly if that is what you based it on. After all
> >> simply using two computers instead of one, also halves the time.
> >> Now I would strongly urge you to use a prime, and I suspect that the
> >> reduction in time is much more than a factor of 2.  But it would be
> >> intellectually interesting to know how much.
> >
> > well, considering how keys though "uncrackable" as little as 10 years
> > ago are now crackable using cloud services or distributed nodes of some
> > kind, sometimes in 'real time' enough to be useful.  anyway, never hurts
> > to make it as secure as possible [and that's the point].
>
> No, that is never the point. to make it as secure as possible disconnect
> your computer from all networks remove any wireless/bluetooth/...
> devices, and install it in a concrete and copper lined room. Oh, you
> want to do something else with it or do not have the money? But you said
> the whole point was "make it as secure as possible".
>
> The question I was asking is how insecure does having a non-prime for DH
> make it. If it requires 10 years of computation with 10million dollars
> of equipment to make use of it, then, unless your secret is worth
> billions, it is not too much of a treat. If it takes 2 min on a 1988 PC,
> then it is a huge threat.
>
> I have done some googling, and it seems that if the factors are
> small enough (eg 512 bits)  and if the number is used widely enough, it become
> worthwhile precomputing a variety of things (what I am not sure of)
> which allows breaking the encryption (finding g^ab from g^a and g^b)
> "easily" And that if you make the factors large enough (eg 512 bits)  it it highly
> unlikely that an examiner would be able to factor the number. (on the
> other hand, testing that p is prime is not that hard). It also seems
> that having many more systems use their own generated primes instead of
> using universal primes (ie ones everyone else also uses) is not a good
> idea.

There is a lot of computing power in a bitcoin rig that can be 
harnessed to crack keys.  Just sayin'

https://securityledger.com/2012/12/new-25-gpu-monster-devours-
passwords-in-seconds/

https://bitcointalk.org/index.php?topic=87476.0

http://bitcoin.stackexchange.com/questions/7236/bitcoin-mining-
asics-used-for-cryptographic-application-rainbow-tables/7264#7264

Back to alt.computer.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Socat vulnerability shows that crypto backdoors can be hard to spot Anonymous <anonymous@foto.nl1.torservers.net> - 2016-02-04 02:16 -0500
  Re: Socat vulnerability shows that crypto backdoors can be hard to spot William Unruh <unruh@invalid.ca> - 2016-02-04 17:20 +0000
    Re: Socat vulnerability shows that crypto backdoors can be hard to spot Anonymous <anonymous@foto.nl1.torservers.net> - 2016-02-04 16:54 -0500
      Re: Socat vulnerability shows that crypto backdoors can be hard to spot William Unruh <unruh@invalid.ca> - 2016-02-05 02:51 +0000
        Re: Socat vulnerability shows that crypto backdoors can be hard to spot Big Bad Bob <BigBadBob-at-mrp3-dot-com@testing.local> - 2016-02-05 11:17 -0800
          Re: Socat vulnerability shows that crypto backdoors can be hard to spot William Unruh <unruh@invalid.ca> - 2016-02-05 21:15 +0000
            Re: Socat vulnerability shows that crypto backdoors can be hard to spot Big Bad Bob <BigBadBob-at-mrp3-dot-com@testing.local> - 2016-02-05 18:07 -0800
              Re: Socat vulnerability shows that crypto backdoors can be hard to spot William Unruh <unruh@invalid.ca> - 2016-02-06 02:53 +0000
                Re: Socat vulnerability shows that crypto backdoors can be hard to spot Big Bad Bob <BigBadBob-at-mrp3-dot-com@testing.local> - 2016-02-05 21:22 -0800
                Re: Socat vulnerability shows that crypto backdoors can be hard to spot William Unruh <unruh@invalid.ca> - 2016-02-06 16:36 +0000
                Re: Socat vulnerability shows that crypto backdoors can be hard to spot Nathan Hale <nobody@remailer.org.uk> - 2016-02-07 07:28 +0000
                Re: Socat vulnerability shows that crypto backdoors can be hard to spot Anonymous <nobody@mixmin.net> - 2016-02-28 02:18 +0000
                Re: Socat vulnerability shows that crypto backdoors can be hard to spot Anonymous <anonymous@foto.nl1.torservers.net> - 2016-02-27 23:27 -0500
                Re: Socat vulnerability shows that crypto backdoors can be hard to spot Anonymous <nobody@mixmin.net> - 2016-03-01 04:42 +0000
  Re: Socat vulnerability shows that crypto backdoors can be hard to spot Anonymous <nobody@mixmin.net> - 2016-02-24 21:47 +0000
    Re: Socat vulnerability shows that crypto backdoors can be hard to spot Nathan Hale <nobody@remailer.org.uk> - 2016-02-25 06:40 +0000

csiph-web