Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #72175 > unrolled thread
| Started by | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| First post | 2015-10-08 07:55 +0200 |
| Last post | 2015-10-13 21:42 +0200 |
| Articles | 20 on this page of 283 — 35 participants |
Back to article view | Back to comp.lang.c
Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-08 07:55 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-08 07:57 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-08 08:01 +0200
Re: Firefox improvements. Robert Baer <robertbaer@localnet.com> - 2015-10-09 01:08 -0700
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-10 13:08 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-10 13:09 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-11 19:03 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 13:13 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-11 19:55 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 16:02 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-11 21:45 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-11 17:01 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-11 22:18 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 18:45 -0400
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-11 18:03 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 19:24 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-11 21:07 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:53 +0100
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:50 +0100
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-11 17:13 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:55 +0100
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 01:08 -0500
Re: Firefox improvements. Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 11:53 -0700
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-19 16:58 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-19 14:32 -0700
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-19 18:26 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-20 07:55 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-20 16:35 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-11 20:51 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 21:05 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-12 01:08 +0000
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 03:59 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-11 23:08 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 04:41 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 00:16 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:37 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 05:46 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:56 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 06:18 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:22 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 08:44 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:23 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 08:47 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 03:59 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 09:14 +0100
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-12 12:08 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 08:59 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:25 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:20 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:27 +0000
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 11:20 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 16:01 +0000
Re: Firefox improvements. Geoff <geoff@invalid.invalid> - 2015-10-13 16:16 -0700
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 23:27 +0000
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-15 21:41 +0200
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:43 +0000
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-16 04:44 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-16 07:51 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-16 08:27 -0700
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-16 13:21 -0400
Re: Firefox improvements. Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2015-10-13 11:31 -0400
Re: Firefox improvements. Jeff Liebermann <jeffl@cruzio.com> - 2015-10-13 08:45 -0700
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 16:03 +0000
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 17:46 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 13:10 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-12 20:01 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-13 00:44 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 12:25 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-13 16:40 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 13:02 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 18:16 +0100
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-13 11:32 -0600
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:53 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:27 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-14 01:45 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 21:58 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-14 02:13 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:29 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-15 01:46 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 01:01 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:16 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 01:19 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 22:07 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:22 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:19 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:51 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 12:59 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:09 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 13:18 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:29 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:30 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:31 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:09 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:47 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 21:22 -0400
Re: Firefox improvements. JW <none@dev.null> - 2015-10-16 06:14 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:09 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:07 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 16:24 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:50 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:02 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 17:12 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:50 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 18:01 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 20:06 -0400
Re: Firefox improvements. Jakob Bohm <jb-usenet@wisemo.com> - 2015-10-16 02:37 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 07:32 +0200
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-15 14:05 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 19:10 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-15 14:46 -0400
Re: Firefox improvements. David Brown <david.brown@hesbynett.no> - 2015-10-15 21:28 +0200
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-16 00:19 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 21:31 -0400
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-15 17:51 -0700
Re: Firefox improvements. gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-16 01:41 +0000
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-14 20:35 -0600
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-15 21:53 +0200
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:18 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:46 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-15 09:18 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-14 02:13 +0000
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-13 21:32 -0600
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 00:21 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:30 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:09 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 13:20 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 09:07 -0400
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-14 04:49 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 00:56 -0400
Re: Firefox improvements. Keith Thompson <kst-u@mib.org> - 2015-10-13 22:39 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 08:40 +0100
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-14 15:01 -0600
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 19:13 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:33 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 19:15 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:42 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:32 -0400
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 13:26 -0500
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 07:48 +0200
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 02:09 -0700
Re: Firefox improvements. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-21 11:10 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 03:45 -0700
Re: Firefox improvements. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-21 13:05 +0100
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-21 11:25 -0500
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 07:53 +0200
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 18:45 +0100
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-13 15:47 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 22:17 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 21:59 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:35 -0400
Re: Firefox improvements. Richard Damon <Richard@Damon-Family.org> - 2015-10-13 22:28 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 04:00 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 23:10 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 04:19 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 00:15 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 08:29 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:39 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:10 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:24 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 22:31 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:16 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 16:25 -0400
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 08:03 +0200
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-14 22:50 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-15 12:19 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-14 22:26 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 22:38 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:20 +0100
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-13 22:54 -0500
Re: Firefox improvements. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-14 04:24 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:47 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 23:01 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:44 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-14 21:11 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 22:26 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 18:48 +0000
Re: Firefox improvements. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-13 13:24 -0600
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 22:23 +0100
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:36 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:59 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 20:35 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 02:16 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-13 18:54 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-14 04:05 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:52 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-14 20:49 -0400
Re: Firefox improvements. "Osmium" <r124c4u102@comcast.net> - 2015-10-14 23:07 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-15 07:12 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 12:58 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 20:49 -0400
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 12:26 -0400
Re: Firefox improvements. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:02 +0000
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 12:19 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-16 17:17 -0400
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-20 22:13 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:13 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 15:04 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:30 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:43 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:29 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 08:53 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 08:50 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:18 +0100
Re: Firefox improvements. Jeroen Belleman <jeroen@nospam.please> - 2015-10-12 16:50 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:12 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 17:33 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:32 +0000
Re: Firefox improvements. Richard Damon <Richard@Damon-Family.org> - 2015-10-12 21:20 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 21:43 -0400
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-13 08:03 +0200
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 07:18 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 07:28 +0100
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 10:16 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-13 04:35 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 12:57 +0100
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 13:29 +0100
Re: Firefox improvements. David Brown <david.brown@hesbynett.no> - 2015-10-13 14:41 +0200
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 13:53 +0100
Re: Firefox improvements. David Brown <david.brown@hesbynett.no> - 2015-10-13 16:24 +0200
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 16:12 +0000
Re: Firefox improvements. William Unruh <unruh@invalid.ca> - 2015-10-13 16:39 +0000
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 18:51 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:55 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:47 -0400
Re: Firefox improvements. Bartc <bc@freeuk.com> - 2015-10-13 18:13 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 19:03 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-13 22:57 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-13 22:02 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-13 22:04 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 12:15 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 16:37 +0000
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 12:46 -0400
Re: Firefox improvements. Brian Gladman <blindanagram@nowhere.net> - 2015-10-12 18:01 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 13:14 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 15:12 +0000
Re: Firefox improvements. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:06 +0000
Re: Firefox improvements. krw <krw@nowhere.com> - 2015-10-13 12:28 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:30 -0400
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 23:58 -0700
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 09:01 +0100
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 08:54 -0400
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 14:24 +0100
Re: Firefox improvements. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-12 07:07 -0700
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 13:02 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-12 15:24 +0000
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:18 -0400
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 16:31 -0500
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 15:55 -0500
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-16 17:33 -0400
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-17 01:32 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-17 01:12 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-17 12:53 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-17 19:32 -0400
Re: Firefox improvements. Chad <cdalten@gmail.com> - 2015-10-17 20:29 -0700
Re: Firefox improvements. gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-18 08:10 +0000
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 11:08 -0500
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-18 17:15 -0400
Re: Firefox improvements. James Kuyper <jameskuyper@verizon.net> - 2015-10-18 12:42 -0400
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-17 10:01 +0200
Trusting password managers [Re: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 00:34 -0500
Re: Trusting password managers [Re: Firefox improvements.] James Kuyper <jameskuyper@verizon.net> - 2015-10-18 11:55 -0400
Re: Trusting password managers [Re: Firefox improvements.] DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-18 17:13 -0400
Re: Trusting password managers [Re: Firefox improvements.] DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-19 06:47 -0400
Re: Trusting password managers [Re: Firefox improvements.] Neon John <no@never.com> - 2015-10-18 13:25 -0400
Re: Trusting password managers [Re: Firefox improvements.] Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:18 -0700
Re: Trusting password managers [Re: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-19 18:37 -0500
Re: Trusting password managers [Re: Firefox improvements.] Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 11:54 -0700
Re: Firefox improvements. rpw3@rpw3.org (Rob Warnock) - 2015-10-12 05:52 +0000
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-12 02:35 -0400
Password crackers are not naive [Was: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 01:07 -0500
Re: Password crackers are not naive [Was: Firefox improvements.] "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 08:16 +0200
Re: Password crackers are not naive [Was: Firefox improvements.] David Malone <dwmalone@walton.maths.tcd.ie> - 2015-10-21 15:54 +0000
Re: Password crackers are not naive [Was: Firefox improvements.] DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 11:57 -0400
Re: Password crackers are not naive [Was: Firefox improvements.] dplatt@coop.radagast.org (Dave Platt) - 2015-10-21 11:17 -0700
Re: Firefox improvements. Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:38 -0700
Re: Firefox improvements. Rosario19 <Ros@invalid.invalid> - 2015-10-12 09:56 +0200
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 01:25 -0500
Re: Firefox improvements. fir <profesor.fir@gmail.com> - 2015-10-14 00:32 -0700
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 08:47 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 09:17 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-21 09:36 +0200
Re: Firefox improvements. bartekltg <bartekltg@gmail.com> - 2015-10-11 23:07 +0200
Re: Firefox improvements. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-10-13 21:42 +0200
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-21 11:10 +0100 |
| Message-ID | <878u6wilb5.fsf@bsb.me.uk> |
| In reply to | #73466 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: On the term "brute force": > Normally we use the term to mean "uses an easy NP or N^2 algorithm when a > more difficult lower-order algorithm is available". You probably mean 2^N (i.e. exponential) rather than NP there -- the phrase "NP algorithm" is a misnomer. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-21 03:45 -0700 |
| Message-ID | <799b6caa-9a21-4f80-8d6f-fcb9c6bda146@googlegroups.com> |
| In reply to | #73468 |
On Wednesday, October 21, 2015 at 11:10:51 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On the term "brute force": > > > Normally we use the term to mean "uses an easy NP or N^2 algorithm when a > > more difficult lower-order algorithm is available". > > You probably mean 2^N (i.e. exponential) rather than NP there -- the > phrase "NP algorithm" is a misnomer. > Are you sure? An NP algorithm is one that completes in non-polynomial time. Normally either 2^N or N! (I'm not sure they're the same), but it could have another non-polynomial running time, like 2^(N!) or something even more catastrophic.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-21 13:05 +0100 |
| Message-ID | <87wpugh1et.fsf@bsb.me.uk> |
| In reply to | #73472 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, October 21, 2015 at 11:10:51 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On the term "brute force": >> >> > Normally we use the term to mean "uses an easy NP or N^2 algorithm when a >> > more difficult lower-order algorithm is available". >> >> You probably mean 2^N (i.e. exponential) rather than NP there -- the >> phrase "NP algorithm" is a misnomer. >> > Are you sure? Yes. > An NP algorithm is one that completes in non-polynomial time. No, absolutely not. NP means "non-deterministic polynomial" (time). But that's not the point I was making. My point was that NP is the name of a set of *problems*. It is, at best, confusing to use the term for an algorithm. Algorithms have costs in terms of time and/or space that are characterised into large classes (usually using O(..), o(...) and Omega(...) notation), but it is *problems* that are classified as being "in P", or "in NP" and so on. > Normally either > 2^N or N! (I'm not sure they're the same), but it could have another > non-polynomial > running time, like 2^(N!) or something even more catastrophic. Or polynomial time -- even linear or constant time (since both are polynomials). Every problem with, for example, a linear-time solution is in the class NP, just as every linear algorithm is O(2^N). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-21 11:25 -0500 |
| Message-ID | <d8psj5F415cU1@mid.individual.net> |
| In reply to | #73451 |
[Follow-up set to sci.crypt]
On 15-10-21 12:48 AM, Skybuck Flying wrote:
> To me brute force would have always ment that some process is
> ramming/logging passwords into some system...
It might seem that way to you, but the expression "brute force"
is used in cryptography for far more than just passwords and
authentication systems.
For example, the inadequacy of 40-bit ("export quality") keys
was demonstrated in the 1990s by showing how easy it was to brute
force them. (Today, any desktop computer can do so).
Deep Crack
https://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html
was built for under 250,000 USD in 1998 to brute force 56 bit DES keys,
showing that 56 bit keys were easily vulnerable to well-resourced
attackers. (Again, that would be much cheaper to brute force today.)
The confusion in the current conversation comes from the fact that brute
force attacks are exhaustive searches of a keyspace that have
traditionally been discussed with respect to keys that are uniformly
distributed, and so the "not taking into account the statistical
properties of the distribution" has pretty much gone without saying
because a smart exhaustive search and a dumb exhaustive search are the
same thing in those circumstances.
When applying this language of "brute force" to human created passwords
(which don't have a uniform distribution) the distinction very much matters.
So "brute force" is a technical term from cryptography. But it appears
that there is some disagreement among the specialists in sci.crypt about
this.
> That's where the word "brute" refers to.
Doesn't matter. When I diagonalize a matrix, I'm not doing anything
unseemly to someone's mother.
> It's literally hammering the system.
And, as I said, traditionally brute force attacks on keys, and you are
not hitting some remote system.
Cheers,
-j
--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-21 07:53 +0200 |
| Message-ID | <7dbd0$56272a9f$d47876e2$51972@news.ziggo.nl> |
| In reply to | #73052 |
" When it comes to cracking passwords, nobody does a brute force attack " That's kind of the funny part. Desperate or dumb/unexperienced people might actually try a brute force attack ! Hence brute force kinda means "dumb attack" ! ;) =D If they get in it might be just dumb luck ! ;) This does make me worry about passwords starting with "a" all of a sudden ! LOL :) Or anything below the first part of the alphabet for that matter ! HAHAHA ! Bye, Skybuck =D
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-13 18:45 +0100 |
| Message-ID | <mvjfre$86s$1@dont-email.me> |
| In reply to | #72722 |
On 13/10/15 18:02, krw wrote:
> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
> <unruh@invalid.ca> wrote:
>
>> On 2015-10-13, krw <krw@nowhere.com> wrote:
>>> On Tue, 13 Oct 2015 00:44:45 +0000 (UTC), William Unruh
>>> <unruh@invalid.ca> wrote:
>>>
>>>> On 2015-10-13, krw <krw@nowhere.com> wrote:
>>>>> On Mon, 12 Oct 2015 17:46:35 +0100, Richard Heathfield
>>>>> <rjh@cpax.org.uk> wrote:
>>>>>
>>>>>> On 12/10/15 17:20, DecadentLinuxUserNumeroUno wrote:
>>>>>>> On Mon, 12 Oct 2015 14:25:16 +0100, Richard Heathfield <rjh@cpax.org.uk>
>>>>>>> Gave us:
>>>>>>>
>>>>>>>> On 12/10/15 13:59, DecadentLinuxUserNumeroUno wrote:
>>>>>>>>> On Mon, 12 Oct 2015 12:08:57 +0100, Bartc <bc@freeuk.com> Gave us:
>>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>> Adding the restriction makes it easier to crack.
>>>>>>>>>
>>>>>>>>> It may makes the list of valid keys smaller,
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>>> but the hack computer is
>>>>>>>>> not aware of the restriction,
>>>>>>>>
>>>>>>>> Wrong. That's public knowledge, so you have to assume your adversary
>>>>>>>> knows it.
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>
>>>>>>> This is NOT true. The key requisites at my workplace are NOT "public
>>>>>>> knowledge".
>>>>>>
>>>>>> The Web site under discussion is the Intel community Web site. Is that
>>>>>> your workplace? If so, then I'm sorry to have to tell you that even
>>>>>> Skybuck Flying knows the validation rules (unless, of course, he's got
>>>>>> them wrong, which is always possible) and now so do sci.crypt,
>>>>>> comp.lang.c, and sci.electronics.design subscribers.
>>>>>
>>>>> Please understand that the person you're responding to is universally
>>>>> known as "AlwaysWrong" on SED.
>>>>>
>>>>>> And if it isn't your workplace, then your workplace's key validation
>>>>>> rules are not, strictly speaking, relevant to the discussion.
>>>>>>
>>>>>> Furthermore, Kerckhoffs's Principle requires that you plan against the
>>>>>> possibility that your adversary has the algorithm available for his
>>>>>> inspection. He worded it as follows: "Il faut qu?il n?exige pas le
>>>>>> secret, et qu?il puisse sans inconv?nient tomber entre les mains de
>>>>>> l?ennemi" which, roughly translated, means "[The cryptosystem] shouldn't
>>>>>> need to be secret, and if it falls into enemy hands that shouldn't be a
>>>>>> big deal". (Obviously he doesn't mean the key itself.)
>>>>>
>>>>> Restated: "Security through obscurity isn't security at all."
>>>>>>
>>>>>>> And all brute force hacks try ALL keys. They do not discredit any, as
>>>>>>> you have.
>>>>>>
>>>>>> All *valid* keys. Otherwise, all brute force attacks would have to try
>>>>>> infinitely many keys despite there being an upper limit on key length,
>>>>>> and that's obviously impossible. Brute force is a last resort and takes
>>>>>> *ages*, so any shortcuts that /can/ be applied /are/ applied.
>>>>>> Adversaries are not constrained by your desire for brute force to be
>>>>>> harder than it needs to be.
>>>>>
>>>>> No, they only try half (on average). ;-)
>>>>>
>>>>
>>>> Well, if they have a good heuristic as to how you choose your keys, it
>>>> is much much less than half that they try, on average.
>>>
>>> Then it's not "brute force".
>>
>> Sure it is. Brute force says nothing about the order in which all the
>> keys are tried.
>
> Wrong. That's exactly what the term means. No thought, just pure
> muscle.
So do you mean that:
for(pin = 0; pin < 10000; pin++)
{
trypin(account, pin);
}
is brute force, but
for(pin = 9999; pin >= 0; pin--)
{
trypin(account, pin);
}
isn't?
If so, perhaps you could explain why.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-13 15:47 -0400 |
| Message-ID | <mvjmvt$chi$1@dont-email.me> |
| In reply to | #72726 |
On 10/13/2015 01:45 PM, Richard Heathfield wrote:
> On 13/10/15 18:02, krw wrote:
>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
>> <unruh@invalid.ca> wrote:
...
>>> Sure it is. Brute force says nothing about the order in which all the
>>> keys are tried.
>>
>> Wrong. That's exactly what the term means. No thought, just pure
>> muscle.
>
> So do you mean that:
>
> for(pin = 0; pin < 10000; pin++)
> {
> trypin(account, pin);
> }
>
> is brute force, but
>
> for(pin = 9999; pin >= 0; pin--)
> {
> trypin(account, pin);
> }
>
> isn't?
>
> If so, perhaps you could explain why.
No, neither of those two options show "thought", so by krw's definition,
they both qualify as brute force. On the other hand, consider an array
containing every single permissible PINs, but sorted in order of
decreasing likelihood that someone will choose that PIN when given a
choice. I could then write
for(pin=0; pin < 100000; pin++)
trypin(account, sorted_pins[pin]);
Since that loop will try every single possible pin, by your definition
it qualifies as "brute force", but it's likely to take a LOT less time
than either of the two loops you listed (but only if the PINs are chosen
by the user - if they're assigned randomly, no such advantage can be
achieved). It's the thought that went into determining which PINs were
more likely to be chosen, which makes this NOT "brute force" in krw's
opinion.
Often, the key issue to be decided with respect to how a term should be
defined, is to ask yourself, what conclusions do I want to be able to
justify, based upon knowing that this term applies? If someone says:
"he's using a brute force attack to determine the password", do you want
to be justified in concluding that "he will require, on average, a
number of guesses equal to half the number of permitted passwords"? If
you want to be able to say that, you can't use a definition that ignores
the enormous speedup allowed (at least in some cases) by use of a sorted
PIN list.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-13 22:17 +0100 |
| Message-ID | <mvjs9c$3s1$1@dont-email.me> |
| In reply to | #72737 |
On 13/10/15 20:47, James Kuyper wrote:
> On 10/13/2015 01:45 PM, Richard Heathfield wrote:
>> On 13/10/15 18:02, krw wrote:
>>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
>>> <unruh@invalid.ca> wrote:
> ...
>>>> Sure it is. Brute force says nothing about the order in which all the
>>>> keys are tried.
>>>
>>> Wrong. That's exactly what the term means. No thought, just pure
>>> muscle.
>>
>> So do you mean that:
>>
>> for(pin = 0; pin < 10000; pin++)
>> {
>> trypin(account, pin);
>> }
>>
>> is brute force, but
>>
>> for(pin = 9999; pin >= 0; pin--)
>> {
>> trypin(account, pin);
>> }
>>
>> isn't?
>>
>> If so, perhaps you could explain why.
>
> No, neither of those two options show "thought", so by krw's definition,
> they both qualify as brute force.
Interesting. I think that's what he means, too.
So we now know that:
for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
IS brute force.
I now review the CCTV footage of the victim - sorry, customer - typing
their PIN into the chip'n'pin machine. Alas, they're being sensible and
masking with the other hand, so it's not very clear, but I'm pretty sure
from the angle of their finger that the first digit is on the 7/8/9 row.
So it makes sense to try the high numbers first.
Now we find that:
for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
IS NOT brute force, without changing the code!
Reductio ad absurdum, so I conclude that krw is talking nonsense.
> On the other hand, consider an array
> containing every single permissible PINs, but sorted in order of
> decreasing likelihood that someone will choose that PIN when given a
> choice. I could then write
>
> for(pin=0; pin < 100000; pin++)
> trypin(account, sorted_pins[pin]);
You could, and that would still be brute force - try every valid key
until you hit one that works.
>
> Since that loop will try every single possible pin, by your definition
> it qualifies as "brute force", but it's likely to take a LOT less time
> than either of the two loops you listed (but only if the PINs are chosen
> by the user - if they're assigned randomly, no such advantage can be
> achieved). It's the thought that went into determining which PINs were
> more likely to be chosen, which makes this NOT "brute force" in krw's
> opinion.
Yes, I understand his opinion. I just don't agree with it.
>
> Often, the key issue to be decided with respect to how a term should be
> defined, is to ask yourself, what conclusions do I want to be able to
> justify, based upon knowing that this term applies? If someone says:
> "he's using a brute force attack to determine the password", do you want
> to be justified in concluding that "he will require, on average, a
> number of guesses equal to half the number of permitted passwords"? If
> you want to be able to say that, you can't use a definition that ignores
> the enormous speedup allowed (at least in some cases) by use of a sorted
> PIN list.
If someone says "he's using a brute force attack to determine the
password" and omits to say that the order of search is probabilistically
determined and that this may well result in the key being found earlier
rather than later, then I think that's probably not an example of good
communication.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-13 21:59 +0000 |
| Message-ID | <mvjusp$dmf$1@dont-email.me> |
| In reply to | #72742 |
In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 13/10/15 20:47, James Kuyper wrote:
> > On 10/13/2015 01:45 PM, Richard Heathfield wrote:
> >> On 13/10/15 18:02, krw wrote:
> >>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
> >>> <unruh@invalid.ca> wrote:
> > ...
> >>>> Sure it is. Brute force says nothing about the order in which
> >>>> all the keys are tried.
> >>>
> >>> Wrong. That's exactly what the term means. No thought, just
> >>> pure muscle.
> >>
> >> So do you mean that:
> >>
> >> for(pin = 0; pin < 10000; pin++)
> >> {
> >> trypin(account, pin);
> >> }
> >>
> >> is brute force, but
> >>
> >> for(pin = 9999; pin >= 0; pin--)
> >> {
> >> trypin(account, pin);
> >> }
> >>
> >> isn't?
> >>
> >> If so, perhaps you could explain why.
> >
> > No, neither of those two options show "thought", so by krw's
> > definition, they both qualify as brute force.
> Interesting. I think that's what he means, too.
> So we now know that:
> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
> IS brute force.
> I now review the CCTV footage of the victim - sorry, customer -
> typing their PIN into the chip'n'pin machine. Alas, they're being
> sensible and masking with the other hand, so it's not very clear, but
> I'm pretty sure from the angle of their finger that the first digit
> is on the 7/8/9 row. So it makes sense to try the high numbers
> first.
> Now we find that:
> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
> IS NOT brute force, without changing the code!
> Reductio ad absurdum, so I conclude that krw is talking nonsense.
I agree. This is exactly the point you and I have been trying to make
for several postings. Choosing the order in which your brute force
loop performs the tests based upon 'other knowledge' in such a way that
*may* result in faster results makes it no less brute force.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 20:35 -0400 |
| Message-ID | <mk8r1bdsp53d5dpsja4rg1c9p5deth8uu5@4ax.com> |
| In reply to | #72749 |
On Tue, 13 Oct 2015 21:59:53 +0000 (UTC), Rich <rich@example.invalid>
wrote:
>In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote:
>> On 13/10/15 20:47, James Kuyper wrote:
>> > On 10/13/2015 01:45 PM, Richard Heathfield wrote:
>> >> On 13/10/15 18:02, krw wrote:
>> >>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
>> >>> <unruh@invalid.ca> wrote:
>> > ...
>> >>>> Sure it is. Brute force says nothing about the order in which
>> >>>> all the keys are tried.
>> >>>
>> >>> Wrong. That's exactly what the term means. No thought, just
>> >>> pure muscle.
>> >>
>> >> So do you mean that:
>> >>
>> >> for(pin = 0; pin < 10000; pin++)
>> >> {
>> >> trypin(account, pin);
>> >> }
>> >>
>> >> is brute force, but
>> >>
>> >> for(pin = 9999; pin >= 0; pin--)
>> >> {
>> >> trypin(account, pin);
>> >> }
>> >>
>> >> isn't?
>> >>
>> >> If so, perhaps you could explain why.
>> >
>> > No, neither of those two options show "thought", so by krw's
>> > definition, they both qualify as brute force.
>
>> Interesting. I think that's what he means, too.
>
>> So we now know that:
>
>> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
>
>> IS brute force.
>
>> I now review the CCTV footage of the victim - sorry, customer -
>> typing their PIN into the chip'n'pin machine. Alas, they're being
>> sensible and masking with the other hand, so it's not very clear, but
>> I'm pretty sure from the angle of their finger that the first digit
>> is on the 7/8/9 row. So it makes sense to try the high numbers
>> first.
>
>> Now we find that:
>
>> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
>
>> IS NOT brute force, without changing the code!
>
>> Reductio ad absurdum, so I conclude that krw is talking nonsense.
>
>I agree. This is exactly the point you and I have been trying to make
>for several postings. Choosing the order in which your brute force
>loop performs the tests based upon 'other knowledge' in such a way that
>*may* result in faster results makes it no less brute force.
...and I disagree. Using any information about the password in the
search is not "brute force", just by the definition of the words. Just
because you design search to include the entire set of possible
combinations doesn't mean it's "brute force". You are using brains
not brawn.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-13 22:28 -0400 |
| Message-ID | <z5jTx.493$2h2.443@fx16.iad> |
| In reply to | #72765 |
On 10/13/15 8:35 PM, krw wrote: >> I agree. This is exactly the point you and I have been trying to make >> for several postings. Choosing the order in which your brute force >> loop performs the tests based upon 'other knowledge' in such a way that >> *may* result in faster results makes it no less brute force. > > ...and I disagree. Using any information about the password in the > search is not "brute force", just by the definition of the words. Just > because you design search to include the entire set of possible > combinations doesn't mean it's "brute force". You are using brains > not brawn. > I will point out that making an argument about not being a 'brute force' attack is falling into the fallacy of the Straw Man. The original complaint was about adding the requirement to passwords making it easier to crack an account. Since this is dealing with the real world, the account cracker is NOT limited to just using brute force, but any means available. To someone using a good secure password, yes, the restrictions make the password a bit easier to crack by brute force, maybe taking it from 1000 years to 800 years with current methods (actually, likely a longer time scale, unless the attacker has gotten their hands on the password hash by some other means). What it has done is taken the not so smart user whose password might well have fallen in minutes to hours, and perhaps kicking it up to months. This is probably a fair trade, as maybe the cracker will move on to some easier site.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 04:00 +0100 |
| Message-ID | <mvkgcg$3f4$1@dont-email.me> |
| In reply to | #72778 |
On 14/10/15 03:28, Richard Damon wrote: > On 10/13/15 8:35 PM, krw wrote: >>> I agree. This is exactly the point you and I have been trying to make >>> for several postings. Choosing the order in which your brute force >>> loop performs the tests based upon 'other knowledge' in such a way that >>> *may* result in faster results makes it no less brute force. >> >> ...and I disagree. Using any information about the password in the >> search is not "brute force", just by the definition of the words. Just >> because you design search to include the entire set of possible >> combinations doesn't mean it's "brute force". You are using brains >> not brawn. >> > > I will point out that making an argument about not being a 'brute force' > attack is falling into the fallacy of the Straw Man. The original > complaint was about adding the requirement to passwords making it easier > to crack an account. Er, no. The original complaint was that the password restriction is "annoying". In a reply to that complaint, the claim was made that the restriction "foils brute force search hacking", which clearly isn't true. In fact, it makes "brute force search hacking" easier. Had the reply been "it makes dictionary attacks more difficult", that would have been a perfectly sensible thing to say. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 23:10 -0400 |
| Message-ID | <5phr1bp7pu5ll527t29744pj0tan1h0khk@4ax.com> |
| In reply to | #72786 |
On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 14/10/15 03:28, Richard Damon wrote: >> On 10/13/15 8:35 PM, krw wrote: >>>> I agree. This is exactly the point you and I have been trying to make >>>> for several postings. Choosing the order in which your brute force >>>> loop performs the tests based upon 'other knowledge' in such a way that >>>> *may* result in faster results makes it no less brute force. >>> >>> ...and I disagree. Using any information about the password in the >>> search is not "brute force", just by the definition of the words. Just >>> because you design search to include the entire set of possible >>> combinations doesn't mean it's "brute force". You are using brains >>> not brawn. >>> >> >> I will point out that making an argument about not being a 'brute force' >> attack is falling into the fallacy of the Straw Man. The original >> complaint was about adding the requirement to passwords making it easier >> to crack an account. > >Er, no. The original complaint was that the password restriction is >"annoying". In a reply to that complaint, the claim was made that the >restriction "foils brute force search hacking", which clearly isn't >true. In fact, it makes "brute force search hacking" easier. > >Had the reply been "it makes dictionary attacks more difficult", that >would have been a perfectly sensible thing to say. > ><snip> It only makes it easier when those rules are known. I responded with my firm's not known rules in mind. You are correct about web sites with published password creation rules. I should have said "makes more difficult" instead of foils as well, but even that is not true in publicly known rule systems, and I conceded that.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 04:19 +0100 |
| Message-ID | <mvkhgs$69o$1@dont-email.me> |
| In reply to | #72790 |
On 14/10/15 04:10, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 14/10/15 03:28, Richard Damon wrote: >>> On 10/13/15 8:35 PM, krw wrote: >>>>> I agree. This is exactly the point you and I have been trying to make >>>>> for several postings. Choosing the order in which your brute force >>>>> loop performs the tests based upon 'other knowledge' in such a way that >>>>> *may* result in faster results makes it no less brute force. >>>> >>>> ...and I disagree. Using any information about the password in the >>>> search is not "brute force", just by the definition of the words. Just >>>> because you design search to include the entire set of possible >>>> combinations doesn't mean it's "brute force". You are using brains >>>> not brawn. >>>> >>> >>> I will point out that making an argument about not being a 'brute force' >>> attack is falling into the fallacy of the Straw Man. The original >>> complaint was about adding the requirement to passwords making it easier >>> to crack an account. >> >> Er, no. The original complaint was that the password restriction is >> "annoying". In a reply to that complaint, the claim was made that the >> restriction "foils brute force search hacking", which clearly isn't >> true. In fact, it makes "brute force search hacking" easier. >> >> Had the reply been "it makes dictionary attacks more difficult", that >> would have been a perfectly sensible thing to say. >> >> <snip> > > It only makes it easier when those rules are known. Sure. But a wise system designer realises that the system itself cannot be kept a secret. In any case, adding the restrictions certainly doesn't make brute force more difficult, even if the rules are not known. > I responded with my firm's not known rules in mind. You are correct > about web sites with published password creation rules. The claim that the rules foil brute force attacks is false, regardless of whether the rules are known. > I should have said "makes more difficult" instead of foils as well, That's still wrong, though. > but even that is not true in publicly known rule systems, and I conceded > that. It isn't even true when the rules are not publicly known. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 00:15 -0400 |
| Message-ID | <3mlr1blvsm135oqijeihangt1g7t6ecg6m@4ax.com> |
| In reply to | #72793 |
On Wed, 14 Oct 2015 04:19:52 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 14/10/15 04:10, DecadentLinuxUserNumeroUno wrote: >> On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> >> Gave us: >> >>> On 14/10/15 03:28, Richard Damon wrote: >>>> On 10/13/15 8:35 PM, krw wrote: >>>>>> I agree. This is exactly the point you and I have been trying to make >>>>>> for several postings. Choosing the order in which your brute force >>>>>> loop performs the tests based upon 'other knowledge' in such a way that >>>>>> *may* result in faster results makes it no less brute force. >>>>> >>>>> ...and I disagree. Using any information about the password in the >>>>> search is not "brute force", just by the definition of the words. Just >>>>> because you design search to include the entire set of possible >>>>> combinations doesn't mean it's "brute force". You are using brains >>>>> not brawn. >>>>> >>>> >>>> I will point out that making an argument about not being a 'brute force' >>>> attack is falling into the fallacy of the Straw Man. The original >>>> complaint was about adding the requirement to passwords making it easier >>>> to crack an account. >>> >>> Er, no. The original complaint was that the password restriction is >>> "annoying". In a reply to that complaint, the claim was made that the >>> restriction "foils brute force search hacking", which clearly isn't >>> true. In fact, it makes "brute force search hacking" easier. >>> >>> Had the reply been "it makes dictionary attacks more difficult", that >>> would have been a perfectly sensible thing to say. >>> >>> <snip> >> >> It only makes it easier when those rules are known. > >Sure. But a wise system designer realises that the system itself cannot >be kept a secret. In any case, adding the restrictions certainly doesn't >make brute force more difficult, even if the rules are not known. > >> I responded with my firm's not known rules in mind. You are correct >> about web sites with published password creation rules. > >The claim that the rules foil brute force attacks is false, regardless >of whether the rules are known. > >> I should have said "makes more difficult" instead of foils as well, > >That's still wrong, though. > >> but even that is not true in publicly known rule systems, and I conceded >> that. > >It isn't even true when the rules are not publicly known. Ok "foils *basic* brute force search engines". That better?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 08:29 +0100 |
| Message-ID | <mvl05k$bmq$1@dont-email.me> |
| In reply to | #72798 |
On 14/10/15 05:15, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 04:19:52 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 14/10/15 04:10, DecadentLinuxUserNumeroUno wrote: <snip> >>> I should have said "makes more difficult" instead of foils as well, >> >> That's still wrong, though. >> >>> but even that is not true in publicly known rule systems, and I conceded >>> that. >> >> It isn't even true when the rules are not publicly known. > > > Ok "foils *basic* brute force search engines". > > That better? Well, it's still wrong, because it doesn't actually foil even basic brute force search engines. They'll get the key in the end. Reducing the key space doesn't have any beneficial effect whatsoever against brute force. "Increases protection against dictionary attacks" would have been better, because it's actually correct. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 20:39 -0400 |
| Message-ID | <tatt1b5o428hubr7qqugfjgpurd555glln@4ax.com> |
| In reply to | #72790 |
On Tue, 13 Oct 2015 23:10:29 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> >Gave us: > >>On 14/10/15 03:28, Richard Damon wrote: >>> On 10/13/15 8:35 PM, krw wrote: >>>>> I agree. This is exactly the point you and I have been trying to make >>>>> for several postings. Choosing the order in which your brute force >>>>> loop performs the tests based upon 'other knowledge' in such a way that >>>>> *may* result in faster results makes it no less brute force. >>>> >>>> ...and I disagree. Using any information about the password in the >>>> search is not "brute force", just by the definition of the words. Just >>>> because you design search to include the entire set of possible >>>> combinations doesn't mean it's "brute force". You are using brains >>>> not brawn. >>>> >>> >>> I will point out that making an argument about not being a 'brute force' >>> attack is falling into the fallacy of the Straw Man. The original >>> complaint was about adding the requirement to passwords making it easier >>> to crack an account. >> >>Er, no. The original complaint was that the password restriction is >>"annoying". In a reply to that complaint, the claim was made that the >>restriction "foils brute force search hacking", which clearly isn't >>true. In fact, it makes "brute force search hacking" easier. >> >>Had the reply been "it makes dictionary attacks more difficult", that >>would have been a perfectly sensible thing to say. >> >><snip> > > It only makes it easier when those rules are known. > > I responded with my firm's not known rules in mind. You are correct >about web sites with published password creation rules. How do you choose a password if you don't know the rules? Choose, get rejected, chose another, rinse... > > I should have said "makes more difficult" instead of foils as well, >but even that is not true in publicly known rule systems, and I conceded >that.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 21:10 -0400 |
| Message-ID | <l7vt1bd4db6chf911nqck5ej2r5jhd4n92@4ax.com> |
| In reply to | #72900 |
On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: >How do you choose a password if you don't know the rules? Choose, get >rejected, chose another, rinse... The *public* does not know the rules. Those within the establishment do.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 22:24 -0400 |
| Message-ID | <lg3u1btmosniceh2md2hfdvmrio23hil2p@4ax.com> |
| In reply to | #72907 |
On Wed, 14 Oct 2015 21:10:42 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: > >>How do you choose a password if you don't know the rules? Choose, get >>rejected, chose another, rinse... > > The *public* does not know the rules. Those within the establishment >do. That's absurd. How secure is that? Hundreds (of thousands?) know the rules but you expect it somehow to be a secret? Silly.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 22:31 -0400 |
| Message-ID | <0u3u1bpjpul8mpsfush5eqhmdjrhb6llig@4ax.com> |
| In reply to | #72916 |
On Wed, 14 Oct 2015 22:24:22 -0400, krw <krw@nowhere.com> Gave us: >On Wed, 14 Oct 2015 21:10:42 -0400, DecadentLinuxUserNumeroUno ><DLU1@DecadentLinuxUser.org> wrote: > >>On Wed, 14 Oct 2015 20:39:07 -0400, krw <krw@nowhere.com> Gave us: >> >>>How do you choose a password if you don't know the rules? Choose, get >>>rejected, chose another, rinse... >> >> The *public* does not know the rules. Those within the establishment >>do. > >That's absurd. How secure is that? Hundreds (of thousands?) know the >rules but you expect it somehow to be a secret? Silly. > As stated earlier. I refer to my company. The rules are NOT public. Learn to read. It isn't a website access. So re-read it, dumbass.
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web