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 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 20:35 -0400 |
| Message-ID | <8q8r1b1c6m9j9juntnpe8t7gdckq3vjt2l@4ax.com> |
| In reply to | #72731 |
On Tue, 13 Oct 2015 18:48:49 +0000 (UTC), Rich <rich@example.invalid> wrote: >In sci.crypt krw <krw@nowhere.com> 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. > >Nope, it is you that is wrong. Brute force simply means "try keys >until one that works is found". Then the term has no meaning. All searches are then "brute force". >It places no requirement upon the >order in which you test the keys. You can try them forward, backwards, >in a random order, or in an order that is likely to test the most >likely candidates first, but it is still "brute force". It is still >"brute force" because you are simply "trying keys until one is found". >
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 02:16 +0100 |
| Message-ID | <mvkaad$hmd$1@dont-email.me> |
| In reply to | #72766 |
On 14/10/15 01:35, krw wrote:
> On Tue, 13 Oct 2015 18:48:49 +0000 (UTC), Rich <rich@example.invalid>
> wrote:
>
<snip>
>>
>> Nope, it is you that is wrong. Brute force simply means "try keys
>> until one that works is found".
>
> Then the term has no meaning. All searches are then "brute force".
The term has a meaning. Bruce Schneier, "Applied Cryptography", 2nd
edition, p8: "All other cryptosystems [he is excluding One-Time Pads]
are breakable in a ciphertext-only attack, simply by trying every
possible key one by one and checking whether the resulting plaintext is
meaningful. This is called a brute-force attack (see Section 7.1)."
Not all searches are brute force. The binary search algorithm has
already been discussed in this context. A linear search, however, /is/ a
brute force search:
found = false;
for(i = 0; !found && i < MAX; i++)
{
if(a[i].key == needle)
{
haystack_index = i;
found = true;
}
}
This algorithm terminates either when the key is found, or when all keys
have been tried. It is a brute force search.
Either a search is brute force or it isn't. We have already seen that,
if krw's understanding of brute force is correct, a specific search can
be both brute force and not brute force, without changing the code; and
that is a contradiction, and therefore false. Conclusion: krw's
understanding of brute force is incorrect.
Below, I present three attacks:
1) a brute-force attack;
2) a definitely-not-brute-force attack;
3) a hybrid attack.
I've already shown, in an earlier article, a brute force attack, but
here it is again:
for(pin = 9999; pin >= 0; pin--)
{
trypin(pin, account);
}
Clearly this is skeleton code. In real code, we'd stop the loop on
finding the correct key.
An example of a not-even-remotely-brute-force attack would be a
frequency analysis of a Caesar-style rotated-alphabet cipher. One can
simply count byte frequencies, and print a graph of those frequencies in
order, and compare to a graph of frequencies of a reference text corpus.
The key can thus be derived simply by looking at the two graphs and
working out the offset between the two tallest lines (using, if desired,
the shape of the rest of the graph as confirmation).
Here is an example of an attack that does not rely on trying every
possible key, but which nevertheless has a brute force aspect to it.
First, the algorithm under attack, which uses XOR for substitution and a
16-element transposition table to create a little diffusion (sci.crypt
subscribers may recognise this algorithm from recent discussions):
for(i = 0; i < n; i++)
{
t[i % 16] = p[i] ^ k[i % keylen];
c[i % 16] = t[transpose[i % 16]];
fwrite(c, 1, 16, outfp);
}
We have a known plaintext and matching ciphertext, and our task is to
determine the key.
The attack begins with p[0], which is enciphered by XORing with k[0],
and then placed at some arbitrary point within the first 16 bytes of
ciphertext. So we XOR p[0] with all of those first 16 bytes, yielding 16
possible candidates for byte 0 of the key.
By reducing the possibilities for the first byte of the key from 256 to
16, we have removed the need to test the other 240 possibilities, even
though we don't yet know which is the correct key byte, let alone the
whole key. It is then possible to produce trial decrypts for every
16*keylen'th ciphertext byte and compare these trial decrypts with the
corresponding plaintext byte. If every one is a match, we have a strong
candidate for the first byte of the key. We then extend this method for
the second byte of the key, and so on.
That's an attack that is directed by an analysis of the algorithm. It is
not a purely brute force attack.
On the other hand, having reduced the first byte of the key from 256
possibilities to 16, we then try every possibility *out of those 16*, so
we are conducting a brute force attack *on those 16 possible byte
values*, but only after reducing the workload to 1/16th of its previous
size.
The term "brute force" should, then, be used with some care, but you
can't go too far wrong if you think of it as "testing all keys that have
not been previously eliminated as possibilities".
The order in which the keys are tried is of no consequence in terms of
the applicability of the phrase "brute force", but it can have
significant impact on how quickly the key is recovered.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-13 18:54 -0700 |
| Message-ID | <3ea92cc4-0da1-4b30-b214-b12164b3306d@googlegroups.com> |
| In reply to | #72768 |
On Wednesday, October 14, 2015 at 2:17:19 AM UTC+1, Richard Heathfield wrote: > > Either a search is brute force or it isn't. We have already seen that, > if krw's understanding of brute force is correct, a specific search can > be both brute force and not brute force, without changing the code; and > that is a contradiction, and therefore false. Conclusion: krw's > understanding of brute force is incorrect. > No, because there's a grey area. If you know that keys from the lower end of the range are more likely, it makes sense to start from zero and go up. If you know the reverse, it makes sense to start from the highest allowed key and work down. So it's not quite "brute force", but it's pretty close to it - the information you are using is quite simple, and it's not helping much. A non-brute force attack involves strategies such as running your own discussion board, capturing passwords, and then trying the same passwords. A dictionary attack is halfway between that and trying every possible key, more "brutal" than the captured password attack, less so than the exhaustive key enumeration attack.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 04:05 +0100 |
| Message-ID | <mvkglj$477$1@dont-email.me> |
| In reply to | #72771 |
On 14/10/15 02:54, Malcolm McLean wrote: > On Wednesday, October 14, 2015 at 2:17:19 AM UTC+1, Richard Heathfield wrote: >> >> Either a search is brute force or it isn't. We have already seen that, >> if krw's understanding of brute force is correct, a specific search can >> be both brute force and not brute force, without changing the code; and >> that is a contradiction, and therefore false. Conclusion: krw's >> understanding of brute force is incorrect. >> > No, because there's a grey area. Convince me. > If you know that keys from the lower end of the range are more likely, > it makes sense to start from zero and go up. If you know the reverse, > it makes sense to start from the highest allowed key and work down. Both correct. > So it's not quite "brute force", Why not? You're still planning to try every key until you hit paydirt. That smells like brute force to me. > but it's pretty close to it - the > information you are using is quite simple, and it's not helping > much. > A non-brute force attack involves strategies such as running your > own discussion board, capturing passwords, and then trying the > same passwords. A dictionary attack is halfway between that and > trying every possible key, more "brutal" than the captured password > attack, less so than the exhaustive key enumeration attack. Note that a dictionary attack can be /part of/ a brute force attack. The order in which one tries keys is irrelevant, and of course it makes sense to try the most likely keys first. But if you're planning (if necessary) to try every possible key, then, well, that's what brute force actually is. -- 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 22:52 -0400 |
| Message-ID | <dlgr1bpfabmtsifcf80p566ngtp0g7udef@4ax.com> |
| In reply to | #72722 |
On Tue, 13 Oct 2015 13:02:14 -0400, krw <krw@nowhere.com> Gave us: >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: snip >>>>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. You're an idiot. No muscle. Merely means that it is a "try 'em all" engine which keeps previously tried keys and tries all that have not yet been tried. There are "smart" brute force engines which can apply search factors based on known rules, which is essentially what this entire thread branch argument has been all about. You lose.... again.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 20:49 -0400 |
| Message-ID | <7vtt1bpj28nb01m3av0o5nahv9gmi7i99j@4ax.com> |
| In reply to | #72780 |
On Tue, 13 Oct 2015 22:52:00 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Tue, 13 Oct 2015 13:02:14 -0400, krw <krw@nowhere.com> Gave us: > >>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: >snip >>>>>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. > > > You're an idiot. No muscle. Merely means that it is a "try 'em all" >engine which keeps previously tried keys and tries all that have not yet >been tried. There are "smart" brute force engines which can apply >search factors based on known rules, which is essentially what this >entire thread branch argument has been all about. > > You lose.... again. You don't have to convince everyone you're always wrong, AlwaysWrong. They got it, already!
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-10-14 23:07 -0500 |
| Message-ID | <d88n4oFmbsrU1@mid.individual.net> |
| In reply to | #72904 |
"krw" <krw@nowhere.com> wrote in message news:7vtt1bpj28nb01m3av0o5nahv9gmi7i99j@4ax.com... > On Tue, 13 Oct 2015 22:52:00 -0400, DecadentLinuxUserNumeroUno > <DLU1@DecadentLinuxUser.org> wrote: > >>On Tue, 13 Oct 2015 13:02:14 -0400, krw <krw@nowhere.com> Gave us: >> >>>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: >>snip >>>>>>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. >> >> >> You're an idiot. No muscle. Merely means that it is a "try 'em all" >>engine which keeps previously tried keys and tries all that have not yet >>been tried. There are "smart" brute force engines which can apply >>search factors based on known rules, which is essentially what this >>entire thread branch argument has been all about. >> >> You lose.... again. > > You don't have to convince everyone you're always wrong, AlwaysWrong. > They got it, already! >
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-15 07:12 -0400 |
| Message-ID | <pf2v1btkm2einpgt17jnhigvju5hqogr2g@4ax.com> |
| In reply to | #72924 |
On Wed, 14 Oct 2015 23:07:51 -0500, "Osmium" <r124c4u102@comcast.net> Gave us: >"krw" Too stupid to say anything, Lameium?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-15 12:58 +0100 |
| Message-ID | <mvo48q$qgp$1@dont-email.me> |
| In reply to | #72934 |
On 15/10/15 12:12, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 23:07:51 -0500, "Osmium" <r124c4u102@comcast.net> > Gave us: > >> "krw" > > Too stupid to say anything, Lameium? It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. So far, almost everything you've posted about this subject has been wrong, so I don't think you are in a position to make claims about other people's stupidity or otherwise. Clearly, Osmium posted a null reply. It is likely that this was by mistake. Everybody makes mistakes. "Making a mistake" is not synonymous with "being stupid". If you think otherwise, please be aware that you have made a great many mistakes in this thread. -- 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-12 20:49 -0400 |
| Message-ID | <78lo1blb03rpe7fk2cuebteja1g75v8apb@4ax.com> |
| In reply to | #72664 |
On Mon, 12 Oct 2015 20:01:29 -0400, krw <krw@nowhere.com> Gave us: >Please understand that the person you're responding to is universally >known as "AlwaysWrong" on SED. No... Only when it spews forth from your retarded, alzheimers inhibited mouth. Or one of your tribe member wannabes.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 12:26 -0400 |
| Message-ID | <24cq1b989u8d957edpeq8tcsma5m15q307@4ax.com> |
| In reply to | #72667 |
On Mon, 12 Oct 2015 20:49:18 -0400, DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >On Mon, 12 Oct 2015 20:01:29 -0400, krw <krw@nowhere.com> Gave us: > >>Please understand that the person you're responding to is universally >>known as "AlwaysWrong" on SED. > > No... Only when it spews forth from your retarded, alzheimers >inhibited mouth. Or one of your tribe member wannabes. See, you're always wrong, AlwaysWrong.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-13 03:02 +0000 |
| Message-ID | <mvhs92$541$2@speranza.aioe.org> |
| In reply to | #72627 |
In comp.lang.c DecadentLinuxUserNumeroUno <DLU1@decadentlinuxuser.org> wrote: (snip) > This is NOT true. The key requisites at my workplace are NOT "public > knowledge". > And all brute force hacks try ALL keys. They do not discredit any, as > you have. They try all, but might order the tries in a way that makes it more likely to find the right one earlier. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-16 12:19 -0500 |
| Message-ID | <d8cps5Fnpp2U1@mid.individual.net> |
| In reply to | #72627 |
On 2015-10-12 16:20:27 +0000, DecadentLinuxUserNumeroUno said: > This is NOT true. The key requisites at my workplace are NOT "public > knowledge". These can presumably be guessed at fairly well by anyone who has had to comply with those requirements. Depending on the size of your organization, that may be a lot of people. Furthermore, that is the pool of people who are most likely to try to attack each others passwords. In any case, it sounds like your workplace is basing its security on widely available "secret". As I've been saying (in some sci.crypt only posts), I believe that you and your policy makers (perhaphs that's you) are the victim of a cargo cult. There was a time and a place when there was a fair argument that placing such restrictions would encourage users to pick passwords stronger than they would have if no such rules were in place. That is, the rules got better password behavior despite the undeniable mathematical fact that they reduce the search space. But that was a long time ago. Yet people are still being led to believe that sticking a "!" at the end of their password makes it a strong password. What has happened is that people have been told various rules about making strong passwords that were never true (although it was once a useful lie to tell people), and they have come to imagine false reasons why these rules "work". It appears that you may have intenralized these rules in such a way that has pushed you toward denying basic mathematical facts. Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-16 17:17 -0400 |
| Message-ID | <lbq22b5klbd8dnhrhhbb7smicnebl7c715@4ax.com> |
| In reply to | #73045 |
On Fri, 16 Oct 2015 12:19:01 -0500, Jeffrey Goldberg <nobody@goldmark.org> Gave us: >On 2015-10-12 16:20:27 +0000, DecadentLinuxUserNumeroUno said: > >> This is NOT true. The key requisites at my workplace are NOT "public >> knowledge". > >These can presumably be guessed at fairly well by anyone who has had >to comply with those requirements. Depending on the size of your >organization, that may be a lot of people. > >Furthermore, that is the pool of people who are most likely to try to >attack each others passwords. They'd get shitcanned immediately. In some cases for even being at someone else's workstation. > >In any case, it sounds like your workplace is basing its security on >widely available "secret". Very few connect for outside, and even those only connect to specific terminals. No one has their PC set up for remote access, nor are they permitted to. > >As I've been saying (in some sci.crypt only posts), I believe that >you and your policy makers (perhaphs that's you) are the victim of a >cargo cult. No. They are strict government guidelines, and we have banks of security folks examining our networks, and we know about every access attempt. There are no breaches and those making the attempts had better not be on a machine of a discoverable nature, or they'll get a knock on their door. "And that right quick" --Shawshank Redemption >There was a time and a place when there was a fair argument that >placing such restrictions would encourage users to pick passwords >stronger than they would have if no such rules were in place. It is still a fair argument. We even have to change ours every few months. And a previously used one will not become available again for about ten years. > That >is, the rules got better password behavior despite the undeniable >mathematical fact that they reduce the search space. An attempt to gain access requires a proper user name and password. Failures get locked out and tracked down. >But that was a long time ago. Yet people are still being led to >believe that sticking a "!" at the end of their password makes it a >strong password. If other than alpha characters are included as part of the whole set, the whole set is larger and by definition would increase the search requisite by definition, and therefore make a password including such a character stronger, by definition. >What has happened is that people have been told various rules about >making strong passwords that were never true (although it was once a >useful lie to tell people), and they have come to imagine false >reasons why these rules "work". The fact is the fact. The password IS stronger. The rules therefore DO work. >It appears that you may have intenralized these rules in such a way >that has pushed you toward denying basic mathematical facts. The math given above proves that YOU are incorrect in your assertion.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-20 22:13 -0500 |
| Message-ID | <d8oe7mFn8qeU1@mid.individual.net> |
| In reply to | #73082 |
[Follow-up set to sci.crypt only] On 15-10-16 4:17 PM, DecadentLinuxUserNumeroUno wrote: > On Fri, 16 Oct 2015 12:19:01 -0500, Jeffrey Goldberg > <nobody@goldmark.org> Gave us: > >> On 2015-10-12 16:20:27 +0000, DecadentLinuxUserNumeroUno said: >> >>> This is NOT true. The key requisites at my workplace are NOT "public >>> knowledge". >> >> These can presumably be guessed at fairly well by anyone who has had >> to comply with those requirements. Depending on the size of your >> organization, that may be a lot of people. >> >> Furthermore, that is the pool of people who are most likely to try to >> attack each others passwords. > > They'd get shitcanned immediately. Oh goodie. For many many years we've all been trying to figure out how to defend against insider attacks. But now we know. We just fire the attackers. Whew! I'm so glad that that problem is solved now. Man, why didn't anyone think of this earlier? >> As I've been saying (in some sci.crypt only posts), I believe that >> you and your policy makers (perhaphs that's you) are the victim of a >> cargo cult. > > No. They are strict government guidelines, and we have banks of > security folks examining our networks, and we know about every access > attempt. Because governments and banks are institutions that are among the first to adapt as the facts change. They would never just follow policy for the sake of being able to say "well, we followed all of the policy and ticked all the boxes". (Actually banks set their customer password policies on a very different threat model than most other institutions, and so produce policies that look particularly dumb, but might actually not be under the appropriate set of assumptions. But that is another story.) >> There was a time and a place when there was a fair argument that >> placing such restrictions would encourage users to pick passwords >> stronger than they would have if no such rules were in place. > > It is still a fair argument. And you've looked at the research on this? Particularly the research by people who actually actually crack passwords? > We even have to change ours every few months. And a previously > used one will not become available again for > about ten years. Ah yes. A strict set of password restrictions PLUS required password changes. Because !MyKidsName123Summer needs to be changed to !MyKidsName123Fall to be secure. Seriously. There are people who study this kind of behavior and we've got relatively decent data on how these policies affect crackability. (And of course, crackability with tools that are a teensy-tiny bit more sophisticated then > An attempt to gain access requires a proper user name and password. > Failures get locked out and tracked down. So you assume that on-line attacks are the only threat and that all entry points to trying those passwords online are sufficiently locked down? (This must include any points of authentication, including ones that aren't normally expected to involve human interaction.) > If other than alpha characters are included as part of the whole set, > the whole set is larger and by definition would increase the search > requisite by definition, and therefore make a password including such a > character stronger, by definition. I've watched others trying to explain this to you. They've made a valiant effort. But what the hell, I'll give it a shot: The "whole set" already includes digits and symbols without the restrictions, unless digits and symbols are somehow forbidden. >> What has happened is that people have been told various rules about >> making strong passwords that were never true (although it was once a >> useful lie to tell people), and they have come to imagine false >> reasons why these rules "work". > > The fact is the fact. The password IS stronger. The rules therefore > DO work. > >> It appears that you may have intenralized these rules in such a way >> that has pushed you toward denying basic mathematical facts. > > The math given above proves that YOU are incorrect in your assertion. One of the sad things about this conversation is that I actually think that there are very specific situations in which password restrictions can be a good idea. I will even go so far as to say that there are even environments in which password aging can do more good than harm. But you insist on repeating flat out nonsense that it is hard to try to tease out the hint of a shadow of a grain of truth in what you might be getting at. Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 14:13 +0100 |
| Message-ID | <mvgbil$7aa$1@dont-email.me> |
| In reply to | #72606 |
On 12/10/15 12:08, Bartc wrote: > On 12/10/2015 08:59, DecadentLinuxUserNumeroUno wrote: > >> It gives 62 choices for each and every character. > > Suppose passwords were one character long and you could use any upper or > lower case letter, or a digit. > > Then there would be 62 possible passwords. > > Now the rule is introduced that there must be at least one digit in the > password. The number of legal passwords must now be 10. > > Adding the restriction makes it easier to crack. Well, it makes a brute force attack easier, yes, and that's been my point throughout. These restrictions can, of course, make a *dictionary* attack harder, but a dictionary attack is a lot less work than a brute force attack, so it is worth making dictionary attacks harder at the expense of making brute force attacks easier. Trying to make DecadentLinuxUserNumeroUno see the distinction has not been easy. -- 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-12 15:04 +0000 |
| Message-ID | <mvgi5s$v34$1@dont-email.me> |
| In reply to | #72593 |
In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote: > On 12/10/15 07:23, DecadentLinuxUserNumeroUno wrote: > > On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> > > Gave us: > > > >> The pool with the lower/upper/digit rule is smaller than the pool > >> without that rule. Making the permissible password longer dilutes the > >> effect, but does not eradicate it, and certainly doesn't make it go > >> negative. > > > > I said "odd character" I meant "special", not an "odd" digit. > I didn't think otherwise. Did I confuse you with my number-guessing > analogy? If so, I apologise for that. I was just trying to explain, in > the Nth way, that fewer choices for a password means easier brute > forcing, and restricting a password by reducing the variety of > characters that you can use means fewer choices for the password, and > therefore easier brute forcing. > It's astonishing that you still can't see this. The two of you are talking past one another. Richard, you are explaining from a more set-theory centric viewpoint. You are starting from a viewpoint of an 8 byte long password with no restrictions on what byte values may exist in any of the eight bytes is a larger set of brute force combinations than an 8 byte long password with restrictions upon what byte values may exist somewhere within the 8 bytes. I.e., the restrictions reduce the set of "all possible passwords" to a smaller subset of "possible passwords that also fit the restrictions". And a smaller set makes brute force easier, because there are less items to try. DecadentLinuxUserNumeroUno, you are explaining from the opposite end. From the human physology end, in that if one asks a typical human (a human who does not understand security concerns well) to 'pick an 8 byte password', invariably one will get a password with all lower case letters in it. However, if one forces that same human to pick '8 characters, with one digit, one lower, one upper, one punctuation' then that same human who would otherwise have picked a password from a set of only 26 lower case characters is now forced to pick a password where there are more total possible combinations (note, it is 'more' because the starting point the human would have used was so small). Both of you are correct, in the arguments you are making, it is just that you are both making different arguments and in the end talking past one another. However, the proper solution from the password picking realm is for everyone to use a password manager tool of some form, and for their passwords to all be randomly chosen from all possible character (or better, all possible byte values). But that will not likely ever happen.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 12:30 -0400 |
| Message-ID | <70on1b5smf2nlc4j94oepu30934umleck6@4ax.com> |
| In reply to | #72620 |
On Mon, 12 Oct 2015 15:04:29 +0000 (UTC), Rich <rich@example.invalid> Gave us: >However, the proper solution from the password picking realm is for >everyone to use a password manager tool of some form, and for their >passwords to all be randomly chosen from all possible character (or >better, all possible byte values). But that will not likely ever >happen. It would then require most users, especially neurally lazy ones, to record or store their password somehow. Actually, I am all for this method. A car that uses a key AND a password would make car theft a thing of the past in almost every case. Crypto hardware typically has a CIK (cryptographic ignition key) as well as individual user access keys. They even get grouped by rank such that only a select few have admin privilege to make system level alterations. In the future, protected high value assets will have active ID modules incorporated into them, and one day humans will likely have implants embedded into their bodies in two places, making even limb (or organ) removal unable to facilitate illicit access. Currently, iris and or retina printing is about as good as it gets, and is really all that is needed, except it has no radio/wireless/non-optical input function. Perhaps well have both iris data and retina data on the RF active implant. Whoop, there it is. Now all the privacy nuts can go off on their mental masturbations.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-12 16:43 +0000 |
| Message-ID | <mvgo02$lhb$4@dont-email.me> |
| In reply to | #72631 |
In sci.crypt DecadentLinuxUserNumeroUno <DLU1@decadentlinuxuser.org> wrote:
> On Mon, 12 Oct 2015 15:04:29 +0000 (UTC), Rich <rich@example.invalid>
> Gave us:
> >However, the proper solution from the password picking realm is for
> >everyone to use a password manager tool of some form, and for their
> >passwords to all be randomly chosen from all possible character (or
> >better, all possible byte values). But that will not likely ever
> >happen.
> It would then require most users, especially neurally lazy ones, to
> record or store their password somehow.
That is what a 'password manager' does (well, at least it is hard to
call them 'password managers' if they do not "record or store their
password[s]").
https://en.wikipedia.org/wiki/Password_manager:
A password manager is a software application that helps a user
*store* and organize passwords.
The advantage to the *store* part is not having to remember the 15
character, totally random, passwords that the manager creates.
I.e., something like this: 3sbdY3XO!O-V$l=
Which I just created [1] using the password manager that I use: Password
Gorilla (https://github.com/zdia/gorilla/wiki).
[1]: No, it is not in use anywhere, the one above was created only for
this posting.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 02:29 -0400 |
| Message-ID | <kpkm1bpl8lt8q8sosmokvjgktb8nfv1s5i@4ax.com> |
| In reply to | #72569 |
On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >With that rule, we have 26 lower * 26 upper * 10 digit = 6760 possible >passwords. > >*Without* that rule, we have 62*62*62 = 238328 possible passwords. Not true. Since their position is not part of the rule, the same set applies to each. The attack test has to test all three together, not click off one until a position value is discovered. This isn't "War Games". > >So if your argument is correct, it's more difficult to conduct a brute >force attack on 6760 passwords than it is to conduct a brute force >attack on 238328 passwords. No. Your argument is incorrect. It does not "discover" one, then move on with a reduced set. This isn't a bubble sort. > Homeopathic cryptanalysis! Whatever, child.
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web