Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.crypt > #32711 > unrolled thread
| Started by | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| First post | 2015-10-11 19:03 +0200 |
| Last post | 2015-10-21 09:36 +0200 |
| Articles | 20 on this page of 281 — 32 participants |
Back to article view | Back to sci.crypt
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-11 14:42 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-11 20:47 +0100
Password restrictions [Was: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-15 13:30 -0500
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. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-15 20:07 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-16 09:01 +0100
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-16 11:59 -0500
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-16 18:21 +0100
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
Strength from generation restrictions [Re: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-15 15:18 -0500
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. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 23:45 +0100
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. MM <mrvmurray@gmail.com> - 2015-10-16 10:13 -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. Rich <rich@example.invalid> - 2015-10-12 16:47 +0000
Re: Firefox improvements. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-12 17:56 +0100
Re: Firefox improvements. Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-20 00:52 -0500
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. Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 14:35 +0100
Re: Firefox improvements. Rich <rich@example.invalid> - 2015-10-15 22:44 +0000
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. 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
Exhaustive searches, brutish and otherwise [Was: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-20 01:19 -0500
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. 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. 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. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 00:46 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 00:47 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 00:48 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 00:51 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 00:52 -0400
Re: Firefox improvements. DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2015-10-21 00:53 -0400
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. 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. 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. James Kuyper <jameskuyper@verizon.net> - 2015-10-12 13:02 -0400
Re: Firefox improvements. gordonb.wak65@burditt.org (Gordon Burditt) - 2015-10-12 20:47 -0500
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. 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. gordonb.ll6qm@burditt.org (Gordon Burditt) - 2015-10-21 18:36 -0500
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.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-19 00:35 -0500
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.] MM <mrvmurray@gmail.com> - 2015-10-18 11:39 -0700
Re: Trusting password managers [Re: Firefox improvements.] Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-19 15:33 -0500
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. 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. "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
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-10-13 13:24 -0600 |
| Message-ID | <1bfv1einbb.fsf@pfeifferfamily.net> |
| In reply to | #32830 |
Rich <rich@example.invalid> writes: > In sci.crypt krw <krw@nowhere.com> wrote: > >> 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". 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". That definition would call a binary search in a sorted array "brute force". To the extent that the order you try keys is based on knowledge, it isn't brute force.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-13 22:23 +0100 |
| Message-ID | <mvjslf$5dr$1@dont-email.me> |
| In reply to | #32833 |
On 13/10/15 20:24, Joe Pfeiffer wrote:
> Rich <rich@example.invalid> writes:
<snip>
>> It is still
>> "brute force" because you are simply "trying keys until one is found".
>
> That definition would call a binary search in a sorted array "brute
> force".
No, because in a binary search you exclude half the keys at every step,
so you will never search them all.
Consider the following search:
{ 0, 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16 }
Search for: 8
{ 0, 1, 2, 3, 4, 5, 6, **7**, 9, 10, 11, 12, 13, 14, 15, 16 }
No, 7's no good. We want something bigger.
0, 1, 2, 3, 4, 5, 6 are eliminated from consideration without being
tested. 7 was tested.
{ 9, 10, 11, **12**, 13, 14, 15, 16 }
No, 12's no good. We want something smaller.
0, 1, 2, 3, 4, 5, 6, 13, 14, 15, 16 are eliminated from consideration
without being tested. 7 and 12 were tested.
{ 9, **10**, 11 }
No, 10's no good. We want something smaller.
0, 1, 2, 3, 4, 5, 6, 11, 13, 14, 15, 16 are eliminated from
consideration without being tested. 7, 10, 12 and (in the final
iteration) 9 were tested.
So we only tested a quarter of the keys, even though we didn't find what
we were looking for. So no, binary search is not brute force.
--
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-13 20:36 -0400 |
| Message-ID | <sr8r1btcj5nvf3ugup570o8umvrfs6a318@4ax.com> |
| In reply to | #32833 |
On Tue, 13 Oct 2015 13:24:40 -0600, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote: >Rich <rich@example.invalid> writes: > >> In sci.crypt krw <krw@nowhere.com> wrote: >> >>> 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". 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". > >That definition would call a binary search in a sorted array "brute >force". To the extent that the order you try keys is based on >knowledge, it isn't brute force. Exactly.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 22:59 -0400 |
| Message-ID | <b6hr1bt4i2vo0pi6bb4ivub400rmdokcmj@4ax.com> |
| In reply to | #32833 |
On Tue, 13 Oct 2015 13:24:40 -0600, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> Gave us: >Rich <rich@example.invalid> writes: > >> In sci.crypt krw <krw@nowhere.com> wrote: >> >>> 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". 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". > >That definition would call a binary search in a sorted array "brute >force". To the extent that the order you try keys is based on >knowledge, it isn't brute force. ALL "brute force" engines are structured inasmuch as they all have a starting point and not all start at the same point. So that decision process alone makes them structured to some degree.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 20:35 -0400 |
| Message-ID | <8q8r1b1c6m9j9juntnpe8t7gdckq3vjt2l@4ax.com> |
| In reply to | #32830 |
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 | #32853 |
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 | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 22:52 -0400 |
| Message-ID | <dlgr1bpfabmtsifcf80p566ngtp0g7udef@4ax.com> |
| In reply to | #32825 |
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 | #32862 |
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 | #32904 |
"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 | #32923 |
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 | #32927 |
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 | #32793 |
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 | #32795 |
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 | #32770 |
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 | #32770 |
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 | #33000 |
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 | #33012 |
[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 | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-21 00:46 -0400 |
| Message-ID | <616e2btptm79u7dssqlo04pfh4cde9fi2d@4ax.com> |
| In reply to | #33093 |
On Tue, 20 Oct 2015 22:13:13 -0500, Jeffrey Goldberg <nobody@goldmark.org> Gave us: >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". This isn't a bank, it is a secret lab, contracted by the government, and between the cameras and the banks of analysts in yet another lab on the same campus, there is not anyone running around pulling stupid shit trying to access others' workstations. You got it now, ding dong?
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-21 00:47 -0400 |
| Message-ID | <t56e2b94mptak89j6pmpasc33db11pv37a@4ax.com> |
| In reply to | #33093 |
On Tue, 20 Oct 2015 22:13:13 -0500, Jeffrey Goldberg <nobody@goldmark.org> Gave us: >And you've looked at the research on this? Particularly the research >by people who actually actually crack passwords? There are exactly ZERO illicit logins on our system. That makes the math pretty simple.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-21 00:48 -0400 |
| Message-ID | <586e2bl9smpl4mq6k549m304mgotbjlgqu@4ax.com> |
| In reply to | #33093 |
On Tue, 20 Oct 2015 22:13:13 -0500, Jeffrey Goldberg <nobody@goldmark.org> Gave us: >Ah yes. A strict set of password restrictions PLUS required password >changes. Because !MyKidsName123Summer needs to be changed to >!MyKidsName123Fall to be secure. Presumptuous horseshit.
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | sci.crypt
csiph-web