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 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-14 20:33 -0400 |
| Message-ID | <l1tt1b5c3gsdll9grre0jurbbakpo001fh@4ax.com> |
| In reply to | #32885 |
On Wed, 14 Oct 2015 15:01:14 -0600, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote: >Richard Heathfield <rjh@cpax.org.uk> writes: > > >> On 14/10/15 06:39, Keith Thompson wrote: >>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >>> [...] >>>> (since it sounds like Keith's definition and mine agree) I'll accept >>>> that others have a different version, but I'll insist that their version >>>> is less brute than mine. >>> >>> Not mine; I've been staying out of this discussion. >> >> I'm guessing that Joe means krw, who is presumably known in s.c.d (by >> a process of elimination). > >Indeed that is who I meant; I've got no idea why "krw" was translated to >"Keith" when typing... > My mommy did that translation. ;-)
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 19:15 -0400 |
| Message-ID | <keot1b1cha80ppj8u5t2lmv58q6hc9sul9@4ax.com> |
| In reply to | #32880 |
On Wed, 14 Oct 2015 08:40:40 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 14/10/15 06:39, Keith Thompson wrote: >> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >> [...] >>> (since it sounds like Keith's definition and mine agree) I'll accept >>> that others have a different version, but I'll insist that their version >>> is less brute than mine. >> >> Not mine; I've been staying out of this discussion. > >I'm guessing that Joe means krw, who is presumably known in s.c.d (by a >process of elimination). Was that a "brute force" process?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-15 12:42 +0100 |
| Message-ID | <mvo3bb$n7a$1@dont-email.me> |
| In reply to | #32895 |
On 15/10/15 00:15, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 08:40:40 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 14/10/15 06:39, Keith Thompson wrote: >>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >>> [...] >>>> (since it sounds like Keith's definition and mine agree) I'll accept >>>> that others have a different version, but I'll insist that their version >>>> is less brute than mine. >>> >>> Not mine; I've been staying out of this discussion. >> >> I'm guessing that Joe means krw, who is presumably known in s.c.d (by a >> process of elimination). > > Was that a "brute force" process? It's a reasonable question. I think the answer is "no". It turns out that Joe meant to type "krw" but typed "Keith" by mistake. I made my guess when that information was not known (except, perhaps, by Joe). It seemed to me to be obvious that Joe was describing krw's definition, so I deduced that Joe knew krw. Since he couldn't know him from sci.crypt (because krw doesn't normally post in sci.crypt) or from comp.lang.c (where krw certainly doesn't normally post and I'm reasonably sure Joe Pfeiffer doesn't either although I haven't actually checked that and could conceivably be wrong), of the three newsgroups that this thread is cross-posted to it was only sci.electronics.design (to which I don't subscribe) in which Joe and krw might be on first name terms. So it was a deductive process, rather than a brute force process. Because it was based on an incorrect assumption, it was a flawed deductive process. But it wasn't 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-14 20:32 -0400 |
| Message-ID | <qust1bphi9j9dosg3fppvj4borr3pl82u9@4ax.com> |
| In reply to | #32880 |
On Wed, 14 Oct 2015 08:40:40 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote: >On 14/10/15 06:39, Keith Thompson wrote: >> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >> [...] >>> (since it sounds like Keith's definition and mine agree) I'll accept >>> that others have a different version, but I'll insist that their version >>> is less brute than mine. >> >> Not mine; I've been staying out of this discussion. > >I'm guessing that Joe means krw, who is presumably known in s.c.d (by a >process of elimination). k => Keith, so I assumed he knew me. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-20 01:19 -0500 |
| Subject | Exhaustive searches, brutish and otherwise [Was: Firefox improvements.] |
| Message-ID | <d8m4nuF575uU1@mid.individual.net> |
| In reply to | #32878 |
[replying to sci.crypt only, because this awful newsreader I've chosen doesn't do Followup-To] On 2015-10-14 05:39:15 +0000, Keith Thompson said: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > [...] >> (since it sounds like Keith's definition and mine agree) I'll accept >> that others have a different version, but I'll insist that their version >> is less brute than mine. > > Not mine; I've been staying out of this discussion. I also distinguish between exhaustive search (which may consider which things are most likely) and "brute force", which does not. But really. I don't care what we call them as long as we can distinguish between them when needed. Note that the former subsumes that latter. All brute force searchers are exhaustive but not all exhausitive searches are brute force. (And yes, all exhausitive searchers, including the brutish ones, will stop once they've found what they are looking for.) The help support the intuition, suppose you were searching for, say, a 32 bit key that was generated with a heavily biased random bit generator. Suppose the RBG produced 1s with probability 0.55 and 0s with probability 0.45. An intellegent search of the keyspace would start with 1^32 and would then move to keys that had 31 1s and one 0, and then 30 1s and 2 0s, etc. Would you call this a "brute force" attack on those keys? I suspect the answer is "no". You would consider this an attack on the random bit generator. The same holds even if the random selection generator lives in wetware as it does when humans create passwords. But again, I'm not going to insist on my/Joe's/krw's definition of "brute force", but I am going to ask that people are careful to make the distinction. When we deal with distributions that are very far from uniform (as human created passwords are) this distinction becomes very very important. Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-16 13:26 -0500 |
| Message-ID | <d8ctq7FoqsbU1@mid.individual.net> |
| In reply to | #32856 |
On 2015-10-14 01:45:39 +0000, William Unruh said: > On 2015-10-14, krw <krw@nowhere.com> wrote: >> On Tue, 13 Oct 2015 18:16:43 +0100, Bartc <bc@freeuk.com> wrote: >> >>> On 13/10/2015 18:02, krw wrote: >>>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh >>> >>>>> 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. >>> >>> It can be a combination of logic and brute force (that's usually how I >>> solve puzzles with a machine instead of using an analytical solution). >> >> Surely, but that's not "brute force". >> >>> If I need to find a 4 digit PIN but somehow know it's more likely to be >>> in the top half, I might start at 9999 and work down, instead of 0000 >>> and work up. >> >> OK, but that's just a stupid uneducated guess. The search is still >> dumb. If you use information about the distribution of numbers, even >> if you (intend to) search all combinations, it's not "brute force". >> > > Yes, we now know your own peculiar version of what "brute force" means. > Accept that others (most others?) might have a different version. Suppose you were searching a keyspace (instead of for passwords) and you knew that the generator of the keys had a strong bias for some numbers over others. Suppose that in an n bit number, the probability of getting a 1 bit was 0.51 and the probability of getting a 0 bit is 0.49. If you design a search for keys that exploited such a weaknes in the key generator, would you be happy to call that a "brute force" attack? If you would not, then it wouldn't be appropriate to talk about an attack on passwords that exploited biases in the password generation scheme. We can define our words however we want, but I suspect that a distinction between "exhaustive search" and "brute force" attack might be useful. When a distribution is uniform, an exhausitve search is the same as a brute force attack. But when it is not uniform, then these differ. In what follows I will use "brute force" in the narrow sense. It means that nothing about the distribution other than its bounds is used in designing the search. When it comes to cracking passwords, nobody does a brute force attack unless the key space is very small, and a dictionary attack is only the first phase of an attack. The interesting parts of the attacks search more and more of the keyspace, generating guesses that it considers most likely. So when talking about password security, we need to very much focus on the fact that attackers make great use of the non-uniformality of the distriution. Cheers, -j
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-21 07:48 +0200 |
| Message-ID | <6a60c$56272742$d47876e2$46911@news.ziggo.nl> |
| In reply to | #33006 |
To me brute force would have always ment that some process is ramming/logging passwords into some system... That's where the word "brute" refers to. It's literally hammering the system. And then "force" is to force itself through the entire key space. The actual order or so of it doesn't really matter. Up or Down is as far as I am concerned still brute force. Even if one has a hunch or prior knowledge that the key *might* be in the upper region... but one never really knows for sure... There *might* be a bias as some say, but never sure. If you just want that one password for that one account, these stats probably play very little roll for the actual account. These kinds of stats would only apply to repeatedly trying to hack different accounts, which might also be part of an attack. But already trying to get into a single account is already difficult enough, so these kind of stats don't mean that much ! ;) Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-21 11:25 -0500 |
| Message-ID | <d8psj5F415cU1@mid.individual.net> |
| In reply to | #33101 |
[Follow-up set to sci.crypt]
On 15-10-21 12:48 AM, Skybuck Flying wrote:
> To me brute force would have always ment that some process is
> ramming/logging passwords into some system...
It might seem that way to you, but the expression "brute force"
is used in cryptography for far more than just passwords and
authentication systems.
For example, the inadequacy of 40-bit ("export quality") keys
was demonstrated in the 1990s by showing how easy it was to brute
force them. (Today, any desktop computer can do so).
Deep Crack
https://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html
was built for under 250,000 USD in 1998 to brute force 56 bit DES keys,
showing that 56 bit keys were easily vulnerable to well-resourced
attackers. (Again, that would be much cheaper to brute force today.)
The confusion in the current conversation comes from the fact that brute
force attacks are exhaustive searches of a keyspace that have
traditionally been discussed with respect to keys that are uniformly
distributed, and so the "not taking into account the statistical
properties of the distribution" has pretty much gone without saying
because a smart exhaustive search and a dumb exhaustive search are the
same thing in those circumstances.
When applying this language of "brute force" to human created passwords
(which don't have a uniform distribution) the distinction very much matters.
So "brute force" is a technical term from cryptography. But it appears
that there is some disagreement among the specialists in sci.crypt about
this.
> That's where the word "brute" refers to.
Doesn't matter. When I diagonalize a matrix, I'm not doing anything
unseemly to someone's mother.
> It's literally hammering the system.
And, as I said, traditionally brute force attacks on keys, and you are
not hitting some remote system.
Cheers,
-j
--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-21 07:53 +0200 |
| Message-ID | <7dbd0$56272a9f$d47876e2$51972@news.ziggo.nl> |
| In reply to | #33006 |
" When it comes to cracking passwords, nobody does a brute force attack " That's kind of the funny part. Desperate or dumb/unexperienced people might actually try a brute force attack ! Hence brute force kinda means "dumb attack" ! ;) =D If they get in it might be just dumb luck ! ;) This does make me worry about passwords starting with "a" all of a sudden ! LOL :) Or anything below the first part of the alphabet for that matter ! HAHAHA ! Bye, Skybuck =D
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-13 18:45 +0100 |
| Message-ID | <mvjfre$86s$1@dont-email.me> |
| In reply to | #32825 |
On 13/10/15 18:02, krw wrote:
> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
> <unruh@invalid.ca> wrote:
>
>> On 2015-10-13, krw <krw@nowhere.com> wrote:
>>> On Tue, 13 Oct 2015 00:44:45 +0000 (UTC), William Unruh
>>> <unruh@invalid.ca> wrote:
>>>
>>>> On 2015-10-13, krw <krw@nowhere.com> wrote:
>>>>> On Mon, 12 Oct 2015 17:46:35 +0100, Richard Heathfield
>>>>> <rjh@cpax.org.uk> wrote:
>>>>>
>>>>>> On 12/10/15 17:20, DecadentLinuxUserNumeroUno wrote:
>>>>>>> On Mon, 12 Oct 2015 14:25:16 +0100, Richard Heathfield <rjh@cpax.org.uk>
>>>>>>> Gave us:
>>>>>>>
>>>>>>>> On 12/10/15 13:59, DecadentLinuxUserNumeroUno wrote:
>>>>>>>>> On Mon, 12 Oct 2015 12:08:57 +0100, Bartc <bc@freeuk.com> Gave us:
>>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>> Adding the restriction makes it easier to crack.
>>>>>>>>>
>>>>>>>>> It may makes the list of valid keys smaller,
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>>> but the hack computer is
>>>>>>>>> not aware of the restriction,
>>>>>>>>
>>>>>>>> Wrong. That's public knowledge, so you have to assume your adversary
>>>>>>>> knows it.
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>
>>>>>>> This is NOT true. The key requisites at my workplace are NOT "public
>>>>>>> knowledge".
>>>>>>
>>>>>> The Web site under discussion is the Intel community Web site. Is that
>>>>>> your workplace? If so, then I'm sorry to have to tell you that even
>>>>>> Skybuck Flying knows the validation rules (unless, of course, he's got
>>>>>> them wrong, which is always possible) and now so do sci.crypt,
>>>>>> comp.lang.c, and sci.electronics.design subscribers.
>>>>>
>>>>> Please understand that the person you're responding to is universally
>>>>> known as "AlwaysWrong" on SED.
>>>>>
>>>>>> And if it isn't your workplace, then your workplace's key validation
>>>>>> rules are not, strictly speaking, relevant to the discussion.
>>>>>>
>>>>>> Furthermore, Kerckhoffs's Principle requires that you plan against the
>>>>>> possibility that your adversary has the algorithm available for his
>>>>>> inspection. He worded it as follows: "Il faut qu?il n?exige pas le
>>>>>> secret, et qu?il puisse sans inconv?nient tomber entre les mains de
>>>>>> l?ennemi" which, roughly translated, means "[The cryptosystem] shouldn't
>>>>>> need to be secret, and if it falls into enemy hands that shouldn't be a
>>>>>> big deal". (Obviously he doesn't mean the key itself.)
>>>>>
>>>>> Restated: "Security through obscurity isn't security at all."
>>>>>>
>>>>>>> And all brute force hacks try ALL keys. They do not discredit any, as
>>>>>>> you have.
>>>>>>
>>>>>> All *valid* keys. Otherwise, all brute force attacks would have to try
>>>>>> infinitely many keys despite there being an upper limit on key length,
>>>>>> and that's obviously impossible. Brute force is a last resort and takes
>>>>>> *ages*, so any shortcuts that /can/ be applied /are/ applied.
>>>>>> Adversaries are not constrained by your desire for brute force to be
>>>>>> harder than it needs to be.
>>>>>
>>>>> No, they only try half (on average). ;-)
>>>>>
>>>>
>>>> Well, if they have a good heuristic as to how you choose your keys, it
>>>> is much much less than half that they try, on average.
>>>
>>> Then it's not "brute force".
>>
>> Sure it is. Brute force says nothing about the order in which all the
>> keys are tried.
>
> Wrong. That's exactly what the term means. No thought, just pure
> muscle.
So do you mean that:
for(pin = 0; pin < 10000; pin++)
{
trypin(account, pin);
}
is brute force, but
for(pin = 9999; pin >= 0; pin--)
{
trypin(account, pin);
}
isn't?
If so, perhaps you could explain why.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-13 15:47 -0400 |
| Message-ID | <mvjmvt$chi$1@dont-email.me> |
| In reply to | #32829 |
On 10/13/2015 01:45 PM, Richard Heathfield wrote:
> On 13/10/15 18:02, krw wrote:
>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
>> <unruh@invalid.ca> wrote:
...
>>> Sure it is. Brute force says nothing about the order in which all the
>>> keys are tried.
>>
>> Wrong. That's exactly what the term means. No thought, just pure
>> muscle.
>
> So do you mean that:
>
> for(pin = 0; pin < 10000; pin++)
> {
> trypin(account, pin);
> }
>
> is brute force, but
>
> for(pin = 9999; pin >= 0; pin--)
> {
> trypin(account, pin);
> }
>
> isn't?
>
> If so, perhaps you could explain why.
No, neither of those two options show "thought", so by krw's definition,
they both qualify as brute force. On the other hand, consider an array
containing every single permissible PINs, but sorted in order of
decreasing likelihood that someone will choose that PIN when given a
choice. I could then write
for(pin=0; pin < 100000; pin++)
trypin(account, sorted_pins[pin]);
Since that loop will try every single possible pin, by your definition
it qualifies as "brute force", but it's likely to take a LOT less time
than either of the two loops you listed (but only if the PINs are chosen
by the user - if they're assigned randomly, no such advantage can be
achieved). It's the thought that went into determining which PINs were
more likely to be chosen, which makes this NOT "brute force" in krw's
opinion.
Often, the key issue to be decided with respect to how a term should be
defined, is to ask yourself, what conclusions do I want to be able to
justify, based upon knowing that this term applies? If someone says:
"he's using a brute force attack to determine the password", do you want
to be justified in concluding that "he will require, on average, a
number of guesses equal to half the number of permitted passwords"? If
you want to be able to say that, you can't use a definition that ignores
the enormous speedup allowed (at least in some cases) by use of a sorted
PIN list.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-13 22:17 +0100 |
| Message-ID | <mvjs9c$3s1$1@dont-email.me> |
| In reply to | #32834 |
On 13/10/15 20:47, James Kuyper wrote:
> On 10/13/2015 01:45 PM, Richard Heathfield wrote:
>> On 13/10/15 18:02, krw wrote:
>>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
>>> <unruh@invalid.ca> wrote:
> ...
>>>> Sure it is. Brute force says nothing about the order in which all the
>>>> keys are tried.
>>>
>>> Wrong. That's exactly what the term means. No thought, just pure
>>> muscle.
>>
>> So do you mean that:
>>
>> for(pin = 0; pin < 10000; pin++)
>> {
>> trypin(account, pin);
>> }
>>
>> is brute force, but
>>
>> for(pin = 9999; pin >= 0; pin--)
>> {
>> trypin(account, pin);
>> }
>>
>> isn't?
>>
>> If so, perhaps you could explain why.
>
> No, neither of those two options show "thought", so by krw's definition,
> they both qualify as brute force.
Interesting. I think that's what he means, too.
So we now know that:
for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
IS brute force.
I now review the CCTV footage of the victim - sorry, customer - typing
their PIN into the chip'n'pin machine. Alas, they're being sensible and
masking with the other hand, so it's not very clear, but I'm pretty sure
from the angle of their finger that the first digit is on the 7/8/9 row.
So it makes sense to try the high numbers first.
Now we find that:
for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
IS NOT brute force, without changing the code!
Reductio ad absurdum, so I conclude that krw is talking nonsense.
> On the other hand, consider an array
> containing every single permissible PINs, but sorted in order of
> decreasing likelihood that someone will choose that PIN when given a
> choice. I could then write
>
> for(pin=0; pin < 100000; pin++)
> trypin(account, sorted_pins[pin]);
You could, and that would still be brute force - try every valid key
until you hit one that works.
>
> Since that loop will try every single possible pin, by your definition
> it qualifies as "brute force", but it's likely to take a LOT less time
> than either of the two loops you listed (but only if the PINs are chosen
> by the user - if they're assigned randomly, no such advantage can be
> achieved). It's the thought that went into determining which PINs were
> more likely to be chosen, which makes this NOT "brute force" in krw's
> opinion.
Yes, I understand his opinion. I just don't agree with it.
>
> Often, the key issue to be decided with respect to how a term should be
> defined, is to ask yourself, what conclusions do I want to be able to
> justify, based upon knowing that this term applies? If someone says:
> "he's using a brute force attack to determine the password", do you want
> to be justified in concluding that "he will require, on average, a
> number of guesses equal to half the number of permitted passwords"? If
> you want to be able to say that, you can't use a definition that ignores
> the enormous speedup allowed (at least in some cases) by use of a sorted
> PIN list.
If someone says "he's using a brute force attack to determine the
password" and omits to say that the order of search is probabilistically
determined and that this may well result in the key being found earlier
rather than later, then I think that's probably not an example of good
communication.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-13 21:59 +0000 |
| Message-ID | <mvjusp$dmf$1@dont-email.me> |
| In reply to | #32838 |
In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 13/10/15 20:47, James Kuyper wrote:
> > On 10/13/2015 01:45 PM, Richard Heathfield wrote:
> >> On 13/10/15 18:02, krw wrote:
> >>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
> >>> <unruh@invalid.ca> wrote:
> > ...
> >>>> Sure it is. Brute force says nothing about the order in which
> >>>> all the keys are tried.
> >>>
> >>> Wrong. That's exactly what the term means. No thought, just
> >>> pure muscle.
> >>
> >> So do you mean that:
> >>
> >> for(pin = 0; pin < 10000; pin++)
> >> {
> >> trypin(account, pin);
> >> }
> >>
> >> is brute force, but
> >>
> >> for(pin = 9999; pin >= 0; pin--)
> >> {
> >> trypin(account, pin);
> >> }
> >>
> >> isn't?
> >>
> >> If so, perhaps you could explain why.
> >
> > No, neither of those two options show "thought", so by krw's
> > definition, they both qualify as brute force.
> Interesting. I think that's what he means, too.
> So we now know that:
> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
> IS brute force.
> I now review the CCTV footage of the victim - sorry, customer -
> typing their PIN into the chip'n'pin machine. Alas, they're being
> sensible and masking with the other hand, so it's not very clear, but
> I'm pretty sure from the angle of their finger that the first digit
> is on the 7/8/9 row. So it makes sense to try the high numbers
> first.
> Now we find that:
> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
> IS NOT brute force, without changing the code!
> Reductio ad absurdum, so I conclude that krw is talking nonsense.
I agree. This is exactly the point you and I have been trying to make
for several postings. Choosing the order in which your brute force
loop performs the tests based upon 'other knowledge' in such a way that
*may* result in faster results makes it no less brute force.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 20:35 -0400 |
| Message-ID | <mk8r1bdsp53d5dpsja4rg1c9p5deth8uu5@4ax.com> |
| In reply to | #32844 |
On Tue, 13 Oct 2015 21:59:53 +0000 (UTC), Rich <rich@example.invalid>
wrote:
>In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote:
>> On 13/10/15 20:47, James Kuyper wrote:
>> > On 10/13/2015 01:45 PM, Richard Heathfield wrote:
>> >> On 13/10/15 18:02, krw wrote:
>> >>> On Tue, 13 Oct 2015 16:40:39 +0000 (UTC), William Unruh
>> >>> <unruh@invalid.ca> wrote:
>> > ...
>> >>>> Sure it is. Brute force says nothing about the order in which
>> >>>> all the keys are tried.
>> >>>
>> >>> Wrong. That's exactly what the term means. No thought, just
>> >>> pure muscle.
>> >>
>> >> So do you mean that:
>> >>
>> >> for(pin = 0; pin < 10000; pin++)
>> >> {
>> >> trypin(account, pin);
>> >> }
>> >>
>> >> is brute force, but
>> >>
>> >> for(pin = 9999; pin >= 0; pin--)
>> >> {
>> >> trypin(account, pin);
>> >> }
>> >>
>> >> isn't?
>> >>
>> >> If so, perhaps you could explain why.
>> >
>> > No, neither of those two options show "thought", so by krw's
>> > definition, they both qualify as brute force.
>
>> Interesting. I think that's what he means, too.
>
>> So we now know that:
>
>> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
>
>> IS brute force.
>
>> I now review the CCTV footage of the victim - sorry, customer -
>> typing their PIN into the chip'n'pin machine. Alas, they're being
>> sensible and masking with the other hand, so it's not very clear, but
>> I'm pretty sure from the angle of their finger that the first digit
>> is on the 7/8/9 row. So it makes sense to try the high numbers
>> first.
>
>> Now we find that:
>
>> for(pin = 9999; pin >= 0; pin--){trypin(account, pin);}
>
>> IS NOT brute force, without changing the code!
>
>> Reductio ad absurdum, so I conclude that krw is talking nonsense.
>
>I agree. This is exactly the point you and I have been trying to make
>for several postings. Choosing the order in which your brute force
>loop performs the tests based upon 'other knowledge' in such a way that
>*may* result in faster results makes it no less brute force.
...and I disagree. Using any information about the password in the
search is not "brute force", just by the definition of the words. Just
because you design search to include the entire set of possible
combinations doesn't mean it's "brute force". You are using brains
not brawn.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-13 22:28 -0400 |
| Message-ID | <z5jTx.493$2h2.443@fx16.iad> |
| In reply to | #32852 |
On 10/13/15 8:35 PM, krw wrote: >> I agree. This is exactly the point you and I have been trying to make >> for several postings. Choosing the order in which your brute force >> loop performs the tests based upon 'other knowledge' in such a way that >> *may* result in faster results makes it no less brute force. > > ...and I disagree. Using any information about the password in the > search is not "brute force", just by the definition of the words. Just > because you design search to include the entire set of possible > combinations doesn't mean it's "brute force". You are using brains > not brawn. > I will point out that making an argument about not being a 'brute force' attack is falling into the fallacy of the Straw Man. The original complaint was about adding the requirement to passwords making it easier to crack an account. Since this is dealing with the real world, the account cracker is NOT limited to just using brute force, but any means available. To someone using a good secure password, yes, the restrictions make the password a bit easier to crack by brute force, maybe taking it from 1000 years to 800 years with current methods (actually, likely a longer time scale, unless the attacker has gotten their hands on the password hash by some other means). What it has done is taken the not so smart user whose password might well have fallen in minutes to hours, and perhaps kicking it up to months. This is probably a fair trade, as maybe the cracker will move on to some easier site.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 04:00 +0100 |
| Message-ID | <mvkgcg$3f4$1@dont-email.me> |
| In reply to | #32860 |
On 14/10/15 03:28, Richard Damon wrote: > On 10/13/15 8:35 PM, krw wrote: >>> I agree. This is exactly the point you and I have been trying to make >>> for several postings. Choosing the order in which your brute force >>> loop performs the tests based upon 'other knowledge' in such a way that >>> *may* result in faster results makes it no less brute force. >> >> ...and I disagree. Using any information about the password in the >> search is not "brute force", just by the definition of the words. Just >> because you design search to include the entire set of possible >> combinations doesn't mean it's "brute force". You are using brains >> not brawn. >> > > I will point out that making an argument about not being a 'brute force' > attack is falling into the fallacy of the Straw Man. The original > complaint was about adding the requirement to passwords making it easier > to crack an account. Er, no. The original complaint was that the password restriction is "annoying". In a reply to that complaint, the claim was made that the restriction "foils brute force search hacking", which clearly isn't true. In fact, it makes "brute force search hacking" easier. Had the reply been "it makes dictionary attacks more difficult", that would have been a perfectly sensible thing to say. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 23:10 -0400 |
| Message-ID | <5phr1bp7pu5ll527t29744pj0tan1h0khk@4ax.com> |
| In reply to | #32867 |
On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 14/10/15 03:28, Richard Damon wrote: >> On 10/13/15 8:35 PM, krw wrote: >>>> I agree. This is exactly the point you and I have been trying to make >>>> for several postings. Choosing the order in which your brute force >>>> loop performs the tests based upon 'other knowledge' in such a way that >>>> *may* result in faster results makes it no less brute force. >>> >>> ...and I disagree. Using any information about the password in the >>> search is not "brute force", just by the definition of the words. Just >>> because you design search to include the entire set of possible >>> combinations doesn't mean it's "brute force". You are using brains >>> not brawn. >>> >> >> I will point out that making an argument about not being a 'brute force' >> attack is falling into the fallacy of the Straw Man. The original >> complaint was about adding the requirement to passwords making it easier >> to crack an account. > >Er, no. The original complaint was that the password restriction is >"annoying". In a reply to that complaint, the claim was made that the >restriction "foils brute force search hacking", which clearly isn't >true. In fact, it makes "brute force search hacking" easier. > >Had the reply been "it makes dictionary attacks more difficult", that >would have been a perfectly sensible thing to say. > ><snip> It only makes it easier when those rules are known. I responded with my firm's not known rules in mind. You are correct about web sites with published password creation rules. I should have said "makes more difficult" instead of foils as well, but even that is not true in publicly known rule systems, and I conceded that.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 04:19 +0100 |
| Message-ID | <mvkhgs$69o$1@dont-email.me> |
| In reply to | #32869 |
On 14/10/15 04:10, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 14/10/15 03:28, Richard Damon wrote: >>> On 10/13/15 8:35 PM, krw wrote: >>>>> I agree. This is exactly the point you and I have been trying to make >>>>> for several postings. Choosing the order in which your brute force >>>>> loop performs the tests based upon 'other knowledge' in such a way that >>>>> *may* result in faster results makes it no less brute force. >>>> >>>> ...and I disagree. Using any information about the password in the >>>> search is not "brute force", just by the definition of the words. Just >>>> because you design search to include the entire set of possible >>>> combinations doesn't mean it's "brute force". You are using brains >>>> not brawn. >>>> >>> >>> I will point out that making an argument about not being a 'brute force' >>> attack is falling into the fallacy of the Straw Man. The original >>> complaint was about adding the requirement to passwords making it easier >>> to crack an account. >> >> Er, no. The original complaint was that the password restriction is >> "annoying". In a reply to that complaint, the claim was made that the >> restriction "foils brute force search hacking", which clearly isn't >> true. In fact, it makes "brute force search hacking" easier. >> >> Had the reply been "it makes dictionary attacks more difficult", that >> would have been a perfectly sensible thing to say. >> >> <snip> > > It only makes it easier when those rules are known. Sure. But a wise system designer realises that the system itself cannot be kept a secret. In any case, adding the restrictions certainly doesn't make brute force more difficult, even if the rules are not known. > I responded with my firm's not known rules in mind. You are correct > about web sites with published password creation rules. The claim that the rules foil brute force attacks is false, regardless of whether the rules are known. > I should have said "makes more difficult" instead of foils as well, That's still wrong, though. > but even that is not true in publicly known rule systems, and I conceded > that. It isn't even true when the rules are not publicly known. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-14 00:15 -0400 |
| Message-ID | <3mlr1blvsm135oqijeihangt1g7t6ecg6m@4ax.com> |
| In reply to | #32870 |
On Wed, 14 Oct 2015 04:19:52 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 14/10/15 04:10, DecadentLinuxUserNumeroUno wrote: >> On Wed, 14 Oct 2015 04:00:28 +0100, Richard Heathfield <rjh@cpax.org.uk> >> Gave us: >> >>> On 14/10/15 03:28, Richard Damon wrote: >>>> On 10/13/15 8:35 PM, krw wrote: >>>>>> I agree. This is exactly the point you and I have been trying to make >>>>>> for several postings. Choosing the order in which your brute force >>>>>> loop performs the tests based upon 'other knowledge' in such a way that >>>>>> *may* result in faster results makes it no less brute force. >>>>> >>>>> ...and I disagree. Using any information about the password in the >>>>> search is not "brute force", just by the definition of the words. Just >>>>> because you design search to include the entire set of possible >>>>> combinations doesn't mean it's "brute force". You are using brains >>>>> not brawn. >>>>> >>>> >>>> I will point out that making an argument about not being a 'brute force' >>>> attack is falling into the fallacy of the Straw Man. The original >>>> complaint was about adding the requirement to passwords making it easier >>>> to crack an account. >>> >>> Er, no. The original complaint was that the password restriction is >>> "annoying". In a reply to that complaint, the claim was made that the >>> restriction "foils brute force search hacking", which clearly isn't >>> true. In fact, it makes "brute force search hacking" easier. >>> >>> Had the reply been "it makes dictionary attacks more difficult", that >>> would have been a perfectly sensible thing to say. >>> >>> <snip> >> >> It only makes it easier when those rules are known. > >Sure. But a wise system designer realises that the system itself cannot >be kept a secret. In any case, adding the restrictions certainly doesn't >make brute force more difficult, even if the rules are not known. > >> I responded with my firm's not known rules in mind. You are correct >> about web sites with published password creation rules. > >The claim that the rules foil brute force attacks is false, regardless >of whether the rules are known. > >> I should have said "makes more difficult" instead of foils as well, > >That's still wrong, though. > >> but even that is not true in publicly known rule systems, and I conceded >> that. > >It isn't even true when the rules are not publicly known. Ok "foils *basic* brute force search engines". That better?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-14 08:29 +0100 |
| Message-ID | <mvl05k$bmq$1@dont-email.me> |
| In reply to | #32873 |
On 14/10/15 05:15, DecadentLinuxUserNumeroUno wrote: > On Wed, 14 Oct 2015 04:19:52 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 14/10/15 04:10, DecadentLinuxUserNumeroUno wrote: <snip> >>> I should have said "makes more difficult" instead of foils as well, >> >> That's still wrong, though. >> >>> but even that is not true in publicly known rule systems, and I conceded >>> that. >> >> It isn't even true when the rules are not publicly known. > > > Ok "foils *basic* brute force search engines". > > That better? Well, it's still wrong, because it doesn't actually foil even basic brute force search engines. They'll get the key in the end. Reducing the key space doesn't have any beneficial effect whatsoever against brute force. "Increases protection against dictionary attacks" would have been better, because it's actually correct. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | sci.crypt
csiph-web