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 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 02:22 -0400 |
| Message-ID | <5bkm1b9ilmv2280v4f7uiarfpha8ip7ili@4ax.com> |
| In reply to | #32738 |
On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >With that rule, we have 26 lower * 26 upper * 10 digit = 6760 possible >passwords. Nope. Their position also varies.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 08:44 +0100 |
| Message-ID | <mvfo9r$45u$1@dont-email.me> |
| In reply to | #32743 |
On 12/10/15 07:22, DecadentLinuxUserNumeroUno wrote: > On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> With that rule, we have 26 lower * 26 upper * 10 digit = 6760 possible >> passwords. > > Nope. Their position also varies. Correct, which elevates it by a factor of 6, to 40560, which is still way less than 238328. -- 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-15 15:18 -0500 |
| Subject | Strength from generation restrictions [Re: Firefox improvements.] |
| Message-ID | <d8ag04F60n3U1@mid.individual.net> |
| In reply to | #32748 |
On 2015-10-12 07:44:54 +0000, Richard Heathfield said:
> On 12/10/15 07:22, DecadentLinuxUserNumeroUno wrote:
>> On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk>
>> Gave us:
>>
>>> With that rule, we have 26 lower * 26 upper * 10 digit = 6760 possible
>>> passwords.
>>
>> Nope. Their position also varies.
>
> Correct, which elevates it by a factor of 6, to 40560, which is still
> way less than 238328.
Yep. Imposing any restrictions (as long as length is held constant)
reduces the number of passwords you can generate with a scheme. As you
correctly point out, yaying you want "at least 2 digits" reduces the
space from saying that you allow any number of digits. (Though see the
thing I posted in sci.crypt only for why when asking humans to create
passwords, these restrictions
may still improve results.)
Because lots of sites and services insist on various restrictions, we
need to write password generators that can conform to them even if we
know that those reduce the number of passwords that we could otherwise
generate for a specific length. And as it happens, I put in an entropy
calculator into to password generator I've been playing with. And some
parts of it are obsessively commented.
To be able to read this (Swift 2), you need to know that the class
contains a "recipe", which specifies what a kinds of passwords are
allowed. While the recipe contains flags for things like allowing
ambiguous characters or white space, etc, the relevant part here is
that is that allows one to specify a "minimum number of X" where X can
be digits, symbols, or letters.
Of course there will be total length requested as well. Note that the
characters be drawn from have been put into arrays like
reqDigitArray, which is the set of digits that can be used for
selecting the required number of digits. (Because the recipe might
exclude ambious character, that array may lack "0", "1", and "5". So
"10" isn't coded in here, instead reqDigitArray!.count is used to get
the number of characters in that array.)
(Also for help with reading Swift, know that there is absolutely no
implicit casting. So there is a lot of explicit stuff going on in
there).
// `generalLength` will be the length of the "other" stuff
that isn't part of the minimum X
var generalLength = ((length - recipe.minDigits.min) -
recipe.minSymbols.min) - recipe.minLetters.min
precondition(generalLength >= 0, "Requested lengths and
conditions to not add up")
result += log2(pow(Double(charsetArray!.count),
Double(generalLength)))
// Let's deal with Digits first
if recipe.minDigits.min > 0 {
result += log2(pow(Double(reqDigitArray!.count),
Double(recipe.minDigits.min)))
let ways = waysToInsert(insertaionsCount:
recipe.minDigits.min, intoCount: generalLength)
result += log2(Double(ways))
generalLength += recipe.minDigits.min // Now the
string we will be inserting into is longer
}
// Let's deal with Symbols
if recipe.minSymbols.min > 0 {
result += log2(pow(Double(reqSymbolArray!.count),
Double(recipe.minSymbols.min)))
let ways = waysToInsert(insertaionsCount:
recipe.minSymbols.min, intoCount: generalLength)
result += log2(Double(ways))
generalLength += recipe.minSymbols.min // Now the
string we will be inserting into is longer
}
// Let's deal with Letters
if recipe.minLetters.min > 0 {
result += log2(pow(Double(reqLetterArray!.count),
Double(recipe.minLetters.min)))
let ways = waysToInsert(insertaionsCount:
recipe.minLetters.min, intoCount: generalLength)
result += log2(Double(ways))
generalLength += recipe.minLetters.min // Now the
string we will be inserting into is longer
}
return result
The other thing that you will need is waysToInsert(). That is
public func waysToInsert(insertaionsCount d: Int, intoCount c: Int)
-> Int {
/* We've got d items to insert randomly into an array of length c.
How many different ways are there to do it?
This one-liner does it, but I made it a separate function because I
call it multiple times, but
only wish to explain the math once.
The first of the d items can be inserted into c + 1 places.
The second of the d items can be inserted into c + 2 places.
the third can be inserted into c + 3 places.
So number of possible ways is
ways = (c + 1) + (c + 2) + ... + (c + d)
Regrouping we get
= c * d + 1 + 2 + ... + d
summing up 1 through d is d*(d-1)/2, so
ways = d * c + (d * (d - 1))/2
Note that because we are doing integer division we want to do the "d
* (d -1)" BEFORE we divide by 2 to
always be dividing an even number. So DON'T mess with what might
appear to be superfluous parentheses.
*/
return d * c + (d * (d - 1))/2 // DON'T mess with what might appear
to be superfluous parentheses.
}
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 02:23 -0400 |
| Message-ID | <nekm1b5b88tvpgi3kqdlas14lll56vb7gf@4ax.com> |
| In reply to | #32738 |
On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >The pool with the lower/upper/digit rule is smaller than the pool >without that rule. Making the permissible password longer dilutes the >effect, but does not eradicate it, and certainly doesn't make it go >negative. I said "odd character" I meant "special", not an "odd" digit.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 08:47 +0100 |
| Message-ID | <mvfof7$45u$2@dont-email.me> |
| In reply to | #32744 |
On 12/10/15 07:23, DecadentLinuxUserNumeroUno wrote: > On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> The pool with the lower/upper/digit rule is smaller than the pool >> without that rule. Making the permissible password longer dilutes the >> effect, but does not eradicate it, and certainly doesn't make it go >> negative. > > I said "odd character" I meant "special", not an "odd" digit. I didn't think otherwise. Did I confuse you with my number-guessing analogy? If so, I apologise for that. I was just trying to explain, in the Nth way, that fewer choices for a password means easier brute forcing, and restricting a password by reducing the variety of characters that you can use means fewer choices for the password, and therefore easier brute forcing. It's astonishing that you still can't see this. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 03:59 -0400 |
| Message-ID | <83qm1bt725k3537qtlo1f58p8h0vkqd5jl@4ax.com> |
| In reply to | #32749 |
On Mon, 12 Oct 2015 08:47:46 +0100, Richard Heathfield <rjh@cpax.org.uk> Gave us: >On 12/10/15 07:23, DecadentLinuxUserNumeroUno wrote: >> On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> >> Gave us: >> >>> The pool with the lower/upper/digit rule is smaller than the pool >>> without that rule. Making the permissible password longer dilutes the >>> effect, but does not eradicate it, and certainly doesn't make it go >>> negative. >> >> I said "odd character" I meant "special", not an "odd" digit. > >I didn't think otherwise. A digit is merely a character. In computerse, it would still be a mere 8 bit word. > Did I confuse you with my number-guessing >analogy? Don't try to be a psychologist. That is where troll mindsets originate. > If so, I apologise for that. I was just trying to explain, in >the Nth way, that fewer choices for a password means easier brute >forcing, and restricting a password by reducing the variety of >characters that you can use means fewer choices for the password, and >therefore easier brute forcing. > >It's astonishing that you still can't see this. It is astonishing that you cannot see that it increases the variety and is not 'fewer choices'. It merely forces the user to make sensible choices to do so. That is directed choices, not fewer. It changes nothing about the number of permutations with the exception of your three character example, since there are only three segmented sections to the available character pool. It gives 62 choices for each and every character. Not having the rule does not automatically mean the person will use all lower case, or omit a numeric segment. Having the rule merely means that at least one instance of specific segments of the full set will be included. It doesn't reduce the complexity of the entire set (with the exception of your three character example).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 09:14 +0100 |
| Message-ID | <mvfq1f$9l7$1@dont-email.me> |
| In reply to | #32752 |
On 12/10/15 08:59, DecadentLinuxUserNumeroUno wrote: > On Mon, 12 Oct 2015 08:47:46 +0100, Richard Heathfield <rjh@cpax.org.uk> > Gave us: > >> On 12/10/15 07:23, DecadentLinuxUserNumeroUno wrote: >>> On Mon, 12 Oct 2015 05:46:26 +0100, Richard Heathfield <rjh@cpax.org.uk> >>> Gave us: >>> >>>> The pool with the lower/upper/digit rule is smaller than the pool >>>> without that rule. Making the permissible password longer dilutes the >>>> effect, but does not eradicate it, and certainly doesn't make it go >>>> negative. >>> >>> I said "odd character" I meant "special", not an "odd" digit. >> >> I didn't think otherwise. > > A digit is merely a character. In computerse, it would still be a > mere 8 bit word. I agree that a digit is a character. I now regret my "odd/even number" example, since it has clearly confused matters, but I find myself in the position of having to try to explain the blindingly obvious in increasing numbers of ways in the hope of stumbling across an explanation that you can understand. > >> Did I confuse you with my number-guessing >> analogy? > > Don't try to be a psychologist. That is where troll mindsets > originate. I don't see the relevance of your comment. You made an incorrect claim, and I am doing my best to explain why that claim is incorrect. This isn't about psychology or trolls or mindsets. It's about simple mathematics. > >> If so, I apologise for that. I was just trying to explain, in >> the Nth way, that fewer choices for a password means easier brute >> forcing, and restricting a password by reducing the variety of >> characters that you can use means fewer choices for the password, and >> therefore easier brute forcing. >> >> It's astonishing that you still can't see this. > > It is astonishing that you cannot see that it increases the variety > and is not 'fewer choices'. A two-character password that can be any two letters of either case is drawn from a pool of 52^2 = 2704 possible passwords. A two-character password that can be any two letters but at least one must be lower case and at least one must be upper case is drawn from a pool of: [a-z][A-Z] = 26 * 26 = 676 [A-Z][a-z] = 26 * 26 = 676 = 1352 possible passwords. The variety is /decreased/ and there are substantially fewer choices. > It gives 62 choices for each and every character. If that were true, I would be able to choose passwords like: ABCDEFGH But I can't. (Not that I would want to. That's not the point here.) > Not having the rule > does not automatically mean the person will use all lower case, or omit > a numeric segment. Finally something we can agree on. But not having the rule means a wider choice, which means a more intensive brute force search is required. -- 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-12 12:08 +0100 |
| Message-ID | <mvg48d$bvv$1@dont-email.me> |
| In reply to | #32752 |
On 12/10/2015 08:59, DecadentLinuxUserNumeroUno wrote: > It gives 62 choices for each and every character. Suppose passwords were one character long and you could use any upper or lower case letter, or a digit. Then there would be 62 possible passwords. Now the rule is introduced that there must be at least one digit in the password. The number of legal passwords must now be 10. Adding the restriction makes it easier to crack. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 08:59 -0400 |
| Message-ID | <9gbn1b5rqadqfo8klt3jc9fhsa84edvb1l@4ax.com> |
| In reply to | #32756 |
On Mon, 12 Oct 2015 12:08:57 +0100, Bartc <bc@freeuk.com> Gave us: >On 12/10/2015 08:59, DecadentLinuxUserNumeroUno wrote: > >> It gives 62 choices for each and every character. > >Suppose passwords were one character long and you could use any upper or >lower case letter, or a digit. > >Then there would be 62 possible passwords. > >Now the rule is introduced that there must be at least one digit in the >password. The number of legal passwords must now be 10. > >Adding the restriction makes it easier to crack. It may makes the list of valid keys smaller, but the hack computer is not aware of the restriction, so it adds ten more keys for each character position in the final key, because said computer now has a larger set it must use to make attempts with, since it doesn't know about the rule.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-10-12 14:25 +0100 |
| Message-ID | <mvgc7v$9kr$2@dont-email.me> |
| In reply to | #32759 |
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> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2015-10-12 12:20 -0400 |
| Message-ID | <mbnn1blr4ih2qnn53t6fu648abe1ik3ijo@4ax.com> |
| In reply to | #32763 |
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". And all brute force hacks try ALL keys. They do not discredit any, as you have.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-12 16:27 +0000 |
| Message-ID | <mvgn1r$lhb$1@dont-email.me> |
| In reply to | #32770 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-13 11:20 +0100 |
| Message-ID | <mvilpq$vs8$1@dont-email.me> |
| In reply to | #32771 |
On 12/10/2015 17:27, 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: How does a brute force attack actually work in practice? Most times I have to enter a password, it's at one end of an internet connection. Usually I have to get it right within a limited number of goes (eg. three or even two) before I'm blocked out temporarily or am required to set a new password. (Maybe that's a better way of getting in!) So I'd imagine it would be difficult to try billions of different combinations. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-13 16:01 +0000 |
| Message-ID | <mvj9t1$f9j$1@dont-email.me> |
| In reply to | #32807 |
In sci.crypt Bartc <bc@freeuk.com> wrote: > On 12/10/2015 17:27, 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: > How does a brute force attack actually work in practice? Try all possibile keys until one decrypts the file - statistics says on average you will test half of the keyspace before you locate the key. Note that the order in which you try them is totally up to you. This is actually the only attack against all cryptosystems that is guaranteed to always work. However, finding the key in a reasonable timeframe is a different story. Which is why longer keys are more secure. A 40-bit key (the old US export crypto keysize) has 2^40 total possible combinations, which is: 1,099,511,627,776 different keys. A 64 bit key has 2^64 combinations, which is: 18,446,744,073,709,551,616 different keys. A 128 bit key has 2^128 combinations, which is: 340,282,366,920,938,463,463,374,607,431,768,211,456 different keys And a 256 bit key has 2^256 combinations, which is: 11579208923731619542357098500868790785326998466564056403945758400791\ 3129639936 so big that bc decided to word wrap the number. > Most times I have to enter a password, it's at one end of an internet > connection. Usually I have to get it right within a limited number of > goes (eg. three or even two) before I'm blocked out temporarily or am > required to set a new password. (Maybe that's a better way of getting in!) > So I'd imagine it would be difficult to try billions of different > combinations. Well, not all 'logins' actually limit the number of tries, so for some, the only limit to the rate is the network latency between the attcker and the system being attacked. In that case, it is quite advantageous to choose one's keys to test in an order other than +1 from the previous key. So trying things like all lowercase letters first, then all lowercase with a number on the front, all lowercase with a number on the back, etc., makes for a higher likelyhood of succeeding. However, most brute force attacks are carried out not by hammering a login prompt but by testing all keys 'locally' on hardware controlled by the attacker against the 'protected' item. I.e., say you sent a file encrypted with AES128 to someone. An attacker (Eve) can intercept that encrypted file, and then on an Amazon cloud attempt to try all possible AES128 keys until they find the one that opens the file. The thing is, with 2^128 different keys, if Eve can try 100 billion keys per second, she still needs (on average): (2^128/2)/(10^11) = 1701411834604692317316873037 seconds to find the key which opens the encrypted file. That large number is 28356863910078205288614550 minutes, or 472614398501303421476909 hours, or 19692266604220975894871 days, or 53914487622781590403 years (at 365.25 days per year). That many years means that the data in the file will likely no longer be valuable to Eve once she does discover the key. In fact, Eve will no longer be around to care after that much time. The reason we need such obscene sizes to make brute force infeasable is because as Bruce Schneier has said, attacks always get better over time. This year Eve can try 100 billion keys per second. Next year, technology advances mean she can try 1 trillion keys per second, two years after that, 2 trillion, etc. And so on. The total key space size needs to be large enough such that the contents are no longer valuable once the tech is fast enough to brute force it in a reasonable time.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-13 23:45 +0100 |
| Message-ID | <87twpubd5y.fsf@bsb.me.uk> |
| In reply to | #32813 |
[Newsgroups trimmed] Rich <rich@example.invalid> writes: > In sci.crypt Bartc <bc@freeuk.com> wrote: <snip> >> How does a brute force attack actually work in practice? > > Try all possibile keys until one decrypts the file - statistics says on > average you will test half of the keyspace before you locate the key. > Note that the order in which you try them is totally up to you. > > This is actually the only attack against all cryptosystems that is > guaranteed to always work. Only if the message is self-verifying. If you apply key 7sgdhagfa718 and get "ATTACK AT DAWN!" you might think you've got the message, but maybe key [1233$571gdsp= gives you "RETREAT AT ONCE". Which one is right? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-10-13 16:16 -0700 |
| Message-ID | <jd3r1bppebec3vqh479djed8gm0s02vmni@4ax.com> |
| In reply to | #32813 |
On Tue, 13 Oct 2015 16:01:37 +0000 (UTC), Rich <rich@example.invalid> wrote: >which is why longer keys are more secure. A 40-bit key (the old US >export crypto keysize) has 2^40 total possible combinations, which is: [snipped lots of math that in no way computes the correct number of permutations of a 5 letter by 8 bit (40-bit) password of any combination of typeable letters and numbers and punctuation.] It's at this point that I wish to point out that if the password is ASCII encoded per above then all the lower-case letters have range 0x61 to 0x7a and the upper have range 0x41 thru 0x5a and each of those ranges loses a bit that is "stuck at 1" for every alphabetic character in the key. A true brute-force attack on a password of this type would be against the bit pattern of the key, not the letters of the key and the attacker has reduced the search space by at least a factor of 4 by knowing those bits are invariant in each byte of the string.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-13 23:27 +0000 |
| Message-ID | <mvk41l$3pn$1@dont-email.me> |
| In reply to | #32849 |
In sci.crypt Geoff <geoff@invalid.invalid> wrote: > On Tue, 13 Oct 2015 16:01:37 +0000 (UTC), Rich <rich@example.invalid> > wrote: > >which is why longer keys are more secure. A 40-bit key (the old US > >export crypto keysize) has 2^40 total possible combinations, which is: > [snipped lots of math that in no way computes the correct number of > permutations of a 5 letter by 8 bit (40-bit) password of any > combination of typeable letters and numbers and punctuation.] 40-bit *key* is not a "password". The word *key* is critical. The *key* is the bit pattern that feeds into an encryption algorithm. The old US export crypto regulations limited export encryption algorithms to those with a maximum of 40-bit key sizes. A password is what a user types in, which for encryption algorithms is then somehow transformed into the *key* for the encryption algorithm. A brute force search works the same, whether testing passwords against login credentials for systems or keys for encrypted data. Keep testing different passwords/keys until one works. How to define 'works' is not, per se., within the realm of the brute force search itself.
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-15 21:41 +0200 |
| Message-ID | <4aa3c$5620016f$d47876e2$24378@news.ziggo.nl> |
| In reply to | #32813 |
Intel can acquire this password within 1 year using a system which can guess 10 passwords per sec. For example by using 10 computers, each computer trying one password per sec. The assumption here is; Lower case letters for the first 6 characters. The last characters are irrelevant and the assumption is the user was so annoyed at these rules that: 1! was picked or !1. Do you know see my annoyance with this ? ;) Forcing users into a certain set of password characters can only be seen as a delibrate attempt at reducing password strength. Bye, Skybuck.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2015-10-15 22:43 +0000 |
| Message-ID | <mvpa6j$ksp$3@dont-email.me> |
| In reply to | #32964 |
In sci.crypt Skybuck Flying <skybuck2000@hotmail.com> wrote: > Forcing users into a certain set of password characters can only be > seen as a delibrate attempt at reducing password strength. That could be one way of looking at it, and you are entitled to look at it that way. But more likely is that it is simply a checkbox on some form for some 'regulatory' approval (either within Intel or otherwise) that was put in place due to a misguided attempt to 'force' the humans to select 'better' passwords. Like many 'regulatory' approvals, there is often no science behind it, but rather it often is more of a "this ... seems to work well, so lets reqire this ..."
[toc] | [prev] | [next] | [standalone]
| From | "Skybuck Flying" <skybuck2000@hotmail.com> |
|---|---|
| Date | 2015-10-16 04:44 +0200 |
| Message-ID | <eddd0$562064a3$d47876e2$39556@news.ziggo.nl> |
| In reply to | #32973 |
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 :)
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | sci.crypt
csiph-web