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 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-16 07:51 -0400 |
| Message-ID | <c4p12bd2j7u9gv01r6ncvtke0p599ollkc@4ax.com> |
| In reply to | #32989 |
On Fri, 16 Oct 2015 04:44:56 +0200, "Skybuck Flying" <skybuck2000@hotmail.com> Gave us: >I disagree.. it's more likely intel has been taken over by NSA or was always >part of NSA. > >"Features" like AMT kinda proves that ! ;) > >Bye, > Skybuck :) Children like you should not be permitted to sit at a computer console. Not for scientific, nor simple gaming purpose.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-16 08:27 -0700 |
| Message-ID | <lnzizi6dh4.fsf@kst-u.example.com> |
| In reply to | #32995 |
DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> writes:
> On Fri, 16 Oct 2015 04:44:56 +0200, "Skybuck Flying"
> <skybuck2000@hotmail.com> Gave us:
>>I disagree.. it's more likely intel has been taken over by NSA or was always
>>part of NSA.
>>
>>"Features" like AMT kinda proves that ! ;)
>>
>>Bye,
>> Skybuck :)
>
> Children like you should not be permitted to sit at a computer
> console.
> Not for scientific, nor simple gaming purpose.
If you're going to insult each other, however much some of you might
deserve it, can you please at least take it out of comp.lang.c?
I presume the folks in sci.crypt and sci.electronics.design aren't
pleased about this discussion either.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | MM <mrvmurray@gmail.com> |
|---|---|
| Date | 2015-10-16 10:13 -0700 |
| Message-ID | <7c0d00d3-ed9a-4f5d-a046-cb2467772c78@googlegroups.com> |
| In reply to | #32996 |
On Friday, 16 October 2015 16:27:09 UTC+1, Keith Thompson wrote: > If you're going to insult each other, however much some of you might > deserve it, can you please at least take it out of comp.lang.c? > I presume the folks in sci.crypt and sci.electronics.design aren't > pleased about this discussion either. Hear, hear! (From someone in sci.crypt) M --
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-16 13:21 -0400 |
| Message-ID | <e9c22bhsl2nlhhiqpmqm0rlndfetui4ett@4ax.com> |
| In reply to | #32996 |
On Fri, 16 Oct 2015 08:27:03 -0700, Keith Thompson <kst-u@mib.org> Gave us: >DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> writes: >> On Fri, 16 Oct 2015 04:44:56 +0200, "Skybuck Flying" >> <skybuck2000@hotmail.com> Gave us: >>>I disagree.. it's more likely intel has been taken over by NSA or was always >>>part of NSA. >>> >>>"Features" like AMT kinda proves that ! ;) >>> >>>Bye, >>> Skybuck :) >> >> Children like you should not be permitted to sit at a computer >> console. >> Not for scientific, nor simple gaming purpose. > >If you're going to insult each other, however much some of you might >deserve it, can you please at least take it out of comp.lang.c? >I presume the folks in sci.crypt and sci.electronics.design aren't >pleased about this discussion either. He never said anything to me. I make observations about his stupidity at time, however, and the cross-post behavior is also rooted with his lame ass, so jump on him. Although he has as yet failed miserably to come anywhere close to understanding anything about Usenet. And whether or not you or the readers of any other Usenet group is pleased or not, you can kiss my ass, because what you should be doing is chastising the skytard for his retarded behavior, not jumping on me for pointing out his stupidity. If you need for me to make that more compact and succinct, I can though I doubt you'll like the language I choose to use.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2015-10-13 11:31 -0400 |
| Message-ID | <OsydnTk1U6p9voDLnZ2dnUU7-eWdnZ2d@supernews.com> |
| In reply to | #32771 |
On 10/12/2015 12:27 PM, Rich wrote: > In sci.crypt DecadentLinuxUserNumeroUno <DLU1@decadentlinuxuser.org> wrote: >> And all brute force hacks try ALL keys. They do not discredit any, >> as you have. > > This is most definitly *not* true, certainly when the adjative "all" is > part of the sentence. > > Many 'brute force' hacks work by trying to be creative in how they > process the keyspace. I.e., they will process the keyspace in this > order: > > 1) try all possible combinations of lower case letters only; > 2) try all possible combinations of upper case letters only; > 3) try each of 1 and 2 above, but also with digits allowed; > 4) try each of 1 and 2 above, but also with digits and punctuation; > > And there is a reason they are often programmed to test the keys in the > pattern. It is because human physology is such that many people's > passwords will be all lower case letters. To testing combinations of > all lowercase first is very likely to find a hit faster than > sequentially testing all possible combinations. > > I.e., they try to structure the order such that the likely > possibilities are tried first, with the lowered possibilities tried > later. > > And because of the human psychology issue, doing something like the > above, while still a 'brute force' attack, will most often > significantly reduce the time needed to perform the attack. > Lots will do human-guided combinations of dictionary words first, out to much longer lengths than the brute-force attack. The XKCD advice https://xkcd.com/936/ is very, very bad. See <https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html> Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
[toc] | [prev] | [next] | [standalone]
| From | Jeff Liebermann <jeffl@cruzio.com> |
|---|---|
| Date | 2015-10-13 08:45 -0700 |
| Message-ID | <4k9q1bp77ibth3r1cbmd39e9g23ljnekb2@4ax.com> |
| In reply to | #32811 |
On Tue, 13 Oct 2015 11:31:44 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote: ><https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html> For many years, the rainbow tables were mostly in English. So, I used passwords generated from phrases in Polish. It didn't last: <http://backtrack.pl/2012/10/23/polskie-teczowe-tablice-polish-rainbow-tables/> Time to learn a new language. -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-13 16:03 +0000 |
| Message-ID | <mvja0k$f9j$2@dont-email.me> |
| In reply to | #32811 |
In sci.crypt Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote: > On 10/12/2015 12:27 PM, Rich wrote: > > In sci.crypt DecadentLinuxUserNumeroUno <DLU1@decadentlinuxuser.org> wrote: > >> And all brute force hacks try ALL keys. They do not discredit any, > >> as you have. > > > > This is most definitly *not* true, certainly when the adjative "all" is > > part of the sentence. > > > > Many 'brute force' hacks work by trying to be creative in how they > > process the keyspace. I.e., they will process the keyspace in this > > order: > > > > 1) try all possible combinations of lower case letters only; > > 2) try all possible combinations of upper case letters only; > > 3) try each of 1 and 2 above, but also with digits allowed; > > 4) try each of 1 and 2 above, but also with digits and punctuation; > > > > And there is a reason they are often programmed to test the keys in the > > pattern. It is because human physology is such that many people's > > passwords will be all lower case letters. To testing combinations of > > all lowercase first is very likely to find a hit faster than > > sequentially testing all possible combinations. > > > > I.e., they try to structure the order such that the likely > > possibilities are tried first, with the lowered possibilities tried > > later. > > > > And because of the human psychology issue, doing something like the > > above, while still a 'brute force' attack, will most often > > significantly reduce the time needed to perform the attack. > > > Lots will do human-guided combinations of dictionary words first, out to > much longer lengths than the brute-force attack. The XKCD advice > https://xkcd.com/936/ is very, very bad. See > <https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html> Yep, all part of "[being] creative in how they process the keyspace". Try the patterns that are statistically more likely to succeed before going into the long brute force run of trying each remaining one in sequence.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 17:46 +0100 |
| Message-ID | <mvgo1f$r9r$1@dont-email.me> |
| In reply to | #32770 |
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. 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.) > 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. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-12 16:47 +0000 |
| Message-ID | <mvgo7q$lhb$5@dont-email.me> |
| In reply to | #32778 |
[Only posted to sci.crypt, as comp.lang.c and sci.electronics.design likely won't know what "AOB" means.] In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote: > > 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. I'm beginning to sense an alternate AOB here. "Brute force" is defined only his way, no other way, and "Eve" can only work by applying "his way" in reverse.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 17:56 +0100 |
| Message-ID | <mvgokb$tpa$1@dont-email.me> |
| In reply to | #32779 |
On 12/10/15 17:47, Rich wrote: > [Only posted to sci.crypt, as comp.lang.c and sci.electronics.design > likely won't know what "AOB" means.] > > In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote: >>> 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. > > I'm beginning to sense an alternate AOB here. > > "Brute force" is defined only his way, no other way, and "Eve" can only > work by applying "his way" in reverse. I was too slow in coming to that conclusion myself. I think I'll leave it there. Some sci.crypters may still remember Anthony Szopa and David(?) Scott, who were similarly gifted in their determination to hold onto their preconceptions. Arguing with them never did much good either. -- 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 | Jeffrey Goldberg <nobody@goldmark.org> |
|---|---|
| Date | 2015-10-20 00:52 -0500 |
| Message-ID | <d8m351F4repU1@mid.individual.net> |
| In reply to | #32780 |
On 2015-10-12 16:56:39 +0000, Richard Heathfield said: > On 12/10/15 17:47, Rich wrote: >> [Only posted to sci.crypt, as comp.lang.c and sci.electronics.design >> likely won't know what "AOB" means.] >> >> In sci.crypt Richard Heathfield <rjh@cpax.org.uk> wrote: >>>> 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. >> >> I'm beginning to sense an alternate AOB here. >> >> "Brute force" is defined only his way, no other way, and "Eve" can only >> work by applying "his way" in reverse. > > > I was too slow in coming to that conclusion myself. I think I'll leave > it there. Yep. It was clear from early on that when he refused to acknolwedge basic facts of math that there was little reason to continue to engage with him. It's one thing to be wrong; it's another to persist in a verifiable mistake once it's been pointed out. But his nonesense did give me the opportunity to rant about things that I am particularly interested in, which is how humans create passwords in the face of rules/advice/restrictions and whether there are realistic ways to either side step the whole problem by eliminiting such passwords or by getting people to pick better ones for the ones that they do have to create. Underneath DLU#1's errors and stubborness is a grain of an intuition that if thought about clearly has some value: If you present people with restrictions like "must contain two digits", do you get them to pick better passwords despite the fact that you are actually restricting the password space? I think that in some cases the answer can reasonably be "yes". I actually think that that good intuition did underly his idiocy, but he clearly was unable to acknowledge any error in his original statement, so there was no way to isolate reasonable bit from the layers of BS he added to try to defend each of is bizaare statements. But I didn't want to deal with him. Cheers, -j > > Some sci.crypters may still remember Anthony Szopa and David(?) Scott, > who were similarly gifted in their determination to hold onto their > preconceptions. Arguing with them never did much good either.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 13:10 -0400 |
| Message-ID | <btpn1b9h8cj5pk8cr578bn4lbe41jil63o@4ax.com> |
| In reply to | #32778 |
On Mon, 12 Oct 2015 17:46:35 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >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. > >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.) > >> 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. OK. I concede to Kirckhoff for those systems which /are/ publicly known. I do not concede that it must be assumed that all are, however. I'll let my PUF the magic key dragon make mine. * Perhaps I'll also let him design the kay system basis as well. One could have keys within keys, etc. Layers, as like an onion. Makes your eyes water, eh? * I know a professor at Purdue working on a MEMs PUF. Pretty cool stuff. She started at MIT and designed the finfet some of us are familiar with. She became a prof there, and then took an offer from Indiana which included tenure upon arrival. This chick is one smart cookie!
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-12 20:01 -0400 |
| Message-ID | <b8io1bhujkh24688q7v6nm60bcm9n86gem@4ax.com> |
| In reply to | #32778 |
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). ;-)
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-10-13 00:44 +0000 |
| Message-ID | <mvhk5t$6rt$1@dont-email.me> |
| In reply to | #32793 |
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.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 12:25 -0400 |
| Message-ID | <33cq1bpedih4vphmv26rdbnkq7a1a4fcgn@4ax.com> |
| In reply to | #32794 |
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".
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-10-13 16:40 +0000 |
| Message-ID | <mvjc67$ofa$2@dont-email.me> |
| In reply to | #32819 |
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.
[toc] | [prev] | [next] | [standalone]
| From | krw <krw@nowhere.com> |
|---|---|
| Date | 2015-10-13 13:02 -0400 |
| Message-ID | <67eq1bptag92gral1q91c2vtj7321kgdrq@4ax.com> |
| In reply to | #32824 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-13 18:16 +0100 |
| Message-ID | <mvje61$2g2$1@dont-email.me> |
| In reply to | #32825 |
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). 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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-10-13 11:32 -0600 |
| Message-ID | <1b37xeeksf.fsf@pfeifferfamily.net> |
| In reply to | #32827 |
Bartc <bc@freeuk.com> writes: > 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). > > 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. To whatever extent that you use knowledge (beyond simple bounds on possible solutions) to guide the search, it isn't brute force. What you're describing is admittedly very close to "real" brute force, but not quite.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-13 22:53 -0400 |
| Message-ID | <4sgr1b5kk112vhh3jkhiiarl5t4eau2aps@4ax.com> |
| In reply to | #32828 |
On Tue, 13 Oct 2015 11:32:48 -0600, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> Gave us: >Bartc <bc@freeuk.com> writes: > >> 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). >> >> 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. > >To whatever extent that you use knowledge (beyond simple bounds on >possible solutions) to guide the search, it isn't brute force. What >you're describing is admittedly very close to "real" brute force, but >not quite. Call it "guided brute force", but it still qualifies as brute force, nonetheless.
[toc] | [prev] | [next] | [standalone]
Page 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
Back to top | Article view | sci.crypt
csiph-web