Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.computer.security > #5720
| 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.
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
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