Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #318776 > unrolled thread
| Started by | Helmut Schellong <rip@schellong.biz> |
|---|---|
| First post | 2022-03-07 13:27 +0100 |
| Last post | 2022-03-26 12:11 +0100 |
| Articles | 20 on this page of 238 — 26 participants |
Back to article view | Back to de.sci.electronics
Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Helmut Schellong <rip@schellong.biz> - 2022-03-07 13:27 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-03-07 14:25 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-03-07 14:47 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Helmut Schellong <rip@schellong.biz> - 2022-03-07 16:08 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Arno Welzel <usenet@arnowelzel.de> - 2022-03-08 01:09 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Karl Davis <me@privacy.org> - 2022-03-08 07:46 +0000
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-03-08 11:27 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Arno Welzel <usenet@arnowelzel.de> - 2022-03-08 15:01 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-03-08 17:04 +0000
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Arno Welzel <usenet@arnowelzel.de> - 2022-03-08 14:58 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Helmut Schellong <rip@schellong.biz> - 2022-03-08 15:09 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Arno Welzel <usenet@arnowelzel.de> - 2022-03-10 18:11 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Helmut Schellong <rip@schellong.biz> - 2022-03-10 23:03 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Arno Welzel <usenet@arnowelzel.de> - 2022-03-12 19:37 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-03-12 19:52 +0100
OT: Aussagen über dicke Menschen (was: Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört!) Arno Welzel <usenet@arnowelzel.de> - 2022-03-13 15:18 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-13 22:15 +0100
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-14 02:28 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-14 13:15 +0100
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-14 14:04 +0100
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-03-14 15:01 +0100
Re: OT: Aussagen über dicke Menschen Reinhardt Behm <rbehm@hushmail.com> - 2022-03-14 15:01 +0000
Re: OT: Aussagen über dicke Menschen Alfred Gemsa <gemsa@gmx.de> - 2022-03-14 17:28 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-14 19:49 +0100
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-03-25 17:10 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-25 17:42 +0100
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-25 17:57 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-25 18:35 +0100
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-25 20:49 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-25 21:08 +0100
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-25 22:30 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-26 14:16 +0100
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-26 23:59 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-27 04:25 +0200
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-27 13:24 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-02 11:52 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-02 13:54 +0200
Re: OT: Aussagen über dicke Menschen Theo Bomba <medicus@hohenheim.org> - 2022-04-02 15:26 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-02 16:49 +0200
Re: OT: Aussagen über dicke Menschen Theo Bomba <medicus@hohenheim.org> - 2022-04-02 17:10 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:11 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-05 16:33 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-06 18:11 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-06 18:37 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-12 00:37 +0200
Re: OT: Aussagen über dicke Menschen Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-04-25 10:37 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:09 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-05 16:29 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-06 18:14 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-06 18:39 +0200
Re: OT: Aussagen über dicke Menschen Theo Bomba <medicus@hohenheim.org> - 2022-04-06 19:03 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-06 19:10 +0200
Re: OT: Aussagen über dicke Menschen Theo Bomba <medicus@hohenheim.org> - 2022-04-06 19:16 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-12 00:39 +0200
Re: OT: Aussagen über dicke Menschen Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-05-17 22:31 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-05-18 13:32 +0200
NIHS (was: OT: Aussagen über dicke Menschen) Volker Bartheld <news2022@bartheld.net> - 2022-03-27 10:13 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-27 11:39 +0200
Re: NIHS Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-03-28 09:29 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-28 15:28 +0200
Re: NIHS Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-03-28 20:23 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-28 22:29 +0200
Re: NIHS Josef Moellers <josef.moellers@invalid.invalid> - 2022-03-29 09:39 +0200
Re: NIHS Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-03-29 09:48 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-03-29 12:35 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 16:39 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-03-29 14:49 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 17:14 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-03-29 18:11 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 19:10 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 15:14 +0200
Re: NIHS Josef Moellers <josef.moellers@invalid.invalid> - 2022-03-29 20:04 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 02:02 +0200
Re: NIHS Josef Moellers <josef.moellers@invalid.invalid> - 2022-03-30 09:34 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 13:36 +0200
Re: NIHS Josef Moellers <josef.moellers@invalid.invalid> - 2022-03-30 14:32 +0200
Re: NIHS Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-03-30 15:01 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-03-30 16:11 +0200
Re: NIHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-03-30 18:10 +0200
Re: NIHS Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-03-30 18:21 +0200
Re: NIHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-03-31 13:16 +0200
Re: NIHS Eric Bruecklmeier <u@5i7.de> - 2022-03-31 13:29 +0200
Re: NIHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-04-01 15:53 +0200
Re: NIHS Eric Bruecklmeier <u@5i7.de> - 2022-04-01 15:58 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-04-01 17:05 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-04-01 17:07 +0200
Re: NIHS Eric Bruecklmeier <u@5i7.de> - 2022-04-02 13:32 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 21:04 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-03-30 10:19 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 14:02 +0200
Re: NIHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-03-31 12:59 +0200
Re: NIHS Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-03-31 13:05 +0200
Re: NIHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-03-31 13:28 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-03-31 15:14 +0000
Re: NIHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-03-31 20:42 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-04-01 13:21 +0000
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-03-31 18:23 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-04-01 11:03 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-04-01 11:18 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-04-01 11:48 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-01 12:54 +0200
Re: NIHS Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-04-01 11:36 +0000
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-04-01 15:35 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-01 18:20 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-04-01 18:33 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-01 19:19 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:25 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-04-05 13:01 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 18:12 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-06 18:17 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-06 18:51 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-12 00:42 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 16:43 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-06 18:20 +0200
Re: NIHS Theo Bomba <medicus@hohenheim.org> - 2022-04-06 18:24 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-06 19:04 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-12 00:49 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-04-02 13:30 +0200
Re: NIHS Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-05-17 22:36 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:23 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-01 18:10 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 17:03 +0200
Re: NIHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-04-05 17:13 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 18:22 +0200
Re: NIHS Josef Moellers <josef.moellers@invalid.invalid> - 2022-04-06 08:59 +0200
Re: NIHS Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-04-06 09:58 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-06 13:45 +0200
Re: NIHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-04-06 22:38 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-06 23:31 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-06 13:18 +0200
Spezifische beweiskräftige Stichproben (was: NIHS) Helmut Schellong <rip@schellong.biz> - 2022-04-15 03:28 +0200
Re: Spezifische beweiskräftige Stichproben Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-04-15 11:26 +0200
Re: Spezifische beweiskräftige Stichproben Helmut Schellong <rip@schellong.biz> - 2022-04-15 15:26 +0200
Re: Spezifische beweiskräftige Stichproben Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-04-15 22:03 +0200
Re: Spezifische beweiskräftige Stichproben Helmut Schellong <rip@schellong.biz> - 2022-04-15 23:32 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-04-01 13:58 +0200
Re: NIHS Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-04-01 19:24 +0200
Re: NIHS Josef Moellers <josef.moellers@invalid.invalid> - 2022-04-01 08:44 +0200
Re: NIHS Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-03-30 14:57 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 15:07 +0200
Re: NIHS Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-03-30 16:13 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 20:57 +0200
Re: NIHS Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-03-31 07:52 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-31 14:39 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-02 12:03 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-02 14:05 +0200
Re: NIHS Theo Bomba <medicus@hohenheim.org> - 2022-04-02 15:32 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-02 16:53 +0200
Re: NIHS Theo Bomba <medicus@hohenheim.org> - 2022-04-02 17:10 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:39 +0200
Re: NIHS Theo Bomba <medicus@hohenheim.org> - 2022-04-05 14:48 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 16:49 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:50 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 17:09 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 17:01 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-03-29 12:32 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 16:34 +0200
Re: NIHS Reinhardt Behm <rbehm@hushmail.com> - 2022-03-29 14:52 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 17:33 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-03-29 17:58 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 19:04 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-03-29 20:34 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 02:10 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-03-29 09:57 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 16:28 +0200
Re: NIHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-03-29 11:21 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-03-29 13:44 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-03-29 14:42 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-29 17:02 +0200
Re: NIHS Volker Bartheld <news2022@bartheld.net> - 2022-03-29 18:13 +0200
Re: NIHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-03-29 23:35 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-03-30 02:28 +0200
Re: NIHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-04-05 17:16 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 18:42 +0200
Re: NIHS Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-04-05 18:44 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-05 18:51 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-06 18:36 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-23 20:12 +0200
Re: NIHS Laurenz Trossel <me@example.invalid> - 2022-04-23 23:59 +0000
Re: NIHS Eric Bruecklmeier <u@5i7.de> - 2022-04-24 11:55 +0200
Re: NIHS Gerhard Hoffmann <dk4xp@arcor.de> - 2022-04-24 12:24 +0200
Re: NIHS Eric Bruecklmeier <u@5i7.de> - 2022-04-24 12:26 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 12:52 +0200
Re: NIHS Eric Bruecklmeier <u@5i7.de> - 2022-04-24 13:27 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 22:10 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 12:51 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 12:50 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 12:25 +0200
Re: NIHS Theo Bomba <medicus@hohenheim.org> - 2022-04-24 13:11 +0200
Re: NIHS Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-04-24 18:23 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 22:29 +0200
Re: NIHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-04-25 08:04 +0200
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-25 13:40 +0200
Re: NIHS Theo Bomba <medicus@hohenheim.org> - 2022-04-25 13:56 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-25 14:15 +0200
Re: NIHS Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-04-25 12:42 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-25 16:36 +0200
Re: NIHS Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-04-25 18:30 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-25 21:06 +0200
Re: NIHS Helmut Wabnig <hwabnig@.- --- -.dotat> - 2022-04-24 14:25 +0200
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-04-24 15:24 +0200
Re: NIHS Christian Weisgerber <naddy@mips.inka.de> - 2022-04-24 14:51 +0000
Re: NIHS Hanno Foest <hurga-news2@tigress.com> - 2022-04-25 00:37 +0200
Re: NIHS Christian Weisgerber <naddy@mips.inka.de> - 2022-04-25 20:35 +0000
Re: NIHS Helmut Schellong <rip@schellong.biz> - 2022-04-24 21:03 +0200
Re: NIHS Arno Welzel <usenet@arnowelzel.de> - 2022-04-25 00:04 +0200
Re: NIHS Hartmut Kraus <hartmut.melina@web.de> - 2022-04-26 11:44 +0200
Re: OT: Aussagen über dicke Menschen Axel Berger <Spam@Berger-Odenthal.De> - 2022-03-27 13:56 +0200
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-27 14:57 +0200
Re: OT: Aussagen über dicke Menschen Volker Bartheld <news2022@bartheld.net> - 2022-03-27 22:17 +0200
Re: OT: Aussagen über dicke Menschen Volker Bartheld <news2022@bartheld.net> - 2022-03-27 22:21 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-28 07:12 +0200
Re: OT: Aussagen über dicke Menschen Andreas Neumann <an5275@sedo.com> - 2022-03-27 19:10 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-27 19:47 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-02 11:46 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-02 13:45 +0200
Re: OT: Aussagen über dicke Menschen Theo Bomba <medicus@hohenheim.org> - 2022-04-02 15:25 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-02 16:45 +0200
Re: OT: Aussagen über dicke Menschen Theo Bomba <medicus@hohenheim.org> - 2022-04-02 17:09 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 15:00 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-05 17:16 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-06 18:37 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-06 19:08 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-12 00:55 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 14:58 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-02 11:42 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-04-02 12:40 +0200
Re: OT: Aussagen über dicke Menschen Arno Welzel <usenet@arnowelzel.de> - 2022-04-05 15:01 +0200
Re: OT: Aussagen über dicke Menschen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-03-26 00:00 +0100
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-26 14:20 +0100
Re: OT: Aussagen über dicke Menschen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-03-27 11:47 +0200
Re: OT: Aussagen über dicke Menschen Helmut Schellong <rip@schellong.biz> - 2022-03-27 11:55 +0200
Re: OT: Aussagen über dicke Menschen Hanno Foest <hurga-news2@tigress.com> - 2022-03-27 13:23 +0200
Re: OT: Aussagen über dicke Menschen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-03-27 14:56 +0200
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-03-11 11:10 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-03-25 18:22 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Helmut Schellong <rip@schellong.biz> - 2022-03-25 18:37 +0100
Re: Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört! Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-03-26 12:11 +0100
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2022-03-28 20:23 +0200 |
| Subject | Re: NIHS |
| Message-ID | <7pu34hhhjo5a4hmkoqvgvua5bk13j5gu5g@4ax.com> |
| In reply to | #319278 |
On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote:
>Es ist _ganz generell_ richtig, was Du schreibst.
>Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>
>Diese hatte ich aufgelistet:
> |Die Kern-Algorithmen sind nicht selbst entwickelt.
> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
> |Diese Algorithmen sind alle kryptographisch.
>
>In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>ist auch meist eine Testprozedur durch die Entwickler angegeben.
>Diese habe ich jeweils durchgeführt!
>Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>Korrekter und beweiskräftiger geht es nicht!
Das wurde ignoriert weil es kein Beweis ist...
>Desweiteren ist abhängig vom Algorithmus meist ein einziger Test tatsächlich beweiskräftig.
Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.
>Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
>zu 'knacken' oder Schwächen zu entdecken.
>Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
>Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!
Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und Kollisionen in
Sekunden gefunden wurden. Das Zeigen *einer* solchen Kollision war ein Beweis,
aber: andersrum gilt nicht.
>Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für eine korrekte Implementation/!
Also ist der triviale und offensichtlich falsche Algorithmus:
if <Testvektor> then return <test result>
bewiesenermaßen korrekt? ("reductio ad absurdum")
>Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene Test-Inputs angegeben, um
>wirklich _jeden Zweifel_ auszuräumen.
>Ich habe stets alle diese Tests durchgeführt - mit übereinstimmendem Ergebnis.
Also ist der triviale und offensichtlich falsche Algorithmus:
if <Testvektor1> then return <test result1>
else if <Testvektor2> then return <test result2>
usw.
bewiesenermaßen korrekt?
>Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
>derer (sogar) die kryptographische Qualität gesichert ist.
>Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
>Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
>Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
>für eine korrekte Implementation.
äh, nein, sorry.
Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-28 22:29 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1t5qb$2khn$1@solani.org> |
| In reply to | #319280 |
On 03/28/2022 20:23, Thomas Prufer wrote:
> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote:
>
>> Es ist _ganz generell_ richtig, was Du schreibst.
>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>>
>> Diese hatte ich aufgelistet:
>> |Die Kern-Algorithmen sind nicht selbst entwickelt.
>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
>> |Diese Algorithmen sind alle kryptographisch.
>>
>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
>> Diese habe ich jeweils durchgeführt!
>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>> Korrekter und beweiskräftiger geht es nicht!
>
> Das wurde ignoriert weil es kein Beweis ist...
Beweis für was?
Diese Aussage wiederum beweist die Inkompetenz derer, die das ignorierten.
Warum?
Es geht um den Beweis einer korrekten Implementation!
Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben.
Es ist dann der Beweis erbracht, daß die vorgenommene Implementation
werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist.
"This is a set of test vectors for conformance testing,"
Hatte ich bereits gepostet.
"Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
Reicht das nicht?
Falls nicht - was reicht denn dann?
Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des Irrsinns.
>> Desweiteren ist abhängig vom Algorithmus meist ein einziger Test tatsächlich beweiskräftig.
>
> Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.
"kein Beweis" für was?
Ein Hash-Algorithmus generiert einen Hash-Wert.
Dieser hat z.B. einen Wertebereich von 2^512 - also endlich.
Bei 2^512+1 verschiedenen Byte-Folgen als Input müssen also zwangsläufig
mindestens 2 gleiche Hash-Werte ausgegeben werden - gemäß Definition.
Komischerweise gab es jedoch über Jahrzehnte hinweg weltweit kein Doppel bisher!
Das liegt einfach daran, daß der Zahlenbereich 2^512 bisher nicht ausgeschöpft werden konnte.
Und daran, daß es bisher kein unprovoziertes Doppel gab.
Ein vorgekommenes Doppel wäre gleichbedeutend mit einem 'geknackten' Algorithmus.
Meist wird erst dann ein verbesserter Algorithmus entwickelt.
Allerdings wurde SHA3 entwickelt, obwohl an SHA2 noch keine Schwächen entdeckt worden sind.
An Rabbit wurden ebenfalls noch keine Schwächen entdeckt.
Ein absoluter Beweis ist im Kontext der Fund von zwei oder mehr gleichen Ausgabewerten.
Dabei sind Zeitpunkt, Umfang und Werte unbekannt und nicht kalkulierbar.
>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
>> zu 'knacken' oder Schwächen zu entdecken.
>> Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
>> Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!
>
> Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und Kollisionen in
> Sekunden gefunden wurden. Das Zeigen *einer* solchen Kollision war ein Beweis,
> aber: andersrum gilt nicht.
MD5 ist uralt, von 1991.
SHA2 hat bisher keine Doppel gezeigt.
SHA3 erst recht nicht.
RC4 (1987) ist schon lange korrumpiert, Nachfolger Spritz (2014) bisher nicht.
>> Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für eine korrekte Implementation/!
>
> Also ist der triviale und offensichtlich falsche Algorithmus:
>
> if <Testvektor> then return <test result>
>
> bewiesenermaßen korrekt? ("reductio ad absurdum")
Ich schrieb oben:
|Es geht um den Beweis einer korrekten Implementation!
|Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben.
|Es ist dann der Beweis erbracht, daß die vorgenommene Implementation
|werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist.
Wenn die Entwickler sagen, daß die von ihnen ausgearbeiteten Tests
die Konformität mit ihrer Referenz beweisen, dann ist das so - und Punkt.
Man braucht darüber nicht weiter diskutieren.
>> Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene Test-Inputs angegeben, um
>> wirklich _jeden Zweifel_ auszuräumen.
>> Ich habe stets alle diese Tests durchgeführt - mit übereinstimmendem Ergebnis.
>
> Also ist der triviale und offensichtlich falsche Algorithmus:
>
> if <Testvektor1> then return <test result1>
> else if <Testvektor2> then return <test result2>
> usw.
> bewiesenermaßen korrekt?
Irrelevant.
Andernfalls hätten die Entwickler diesen vorstehenden Algorithmus angegeben...
>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
>> derer (sogar) die kryptographische Qualität gesichert ist.
>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
>> Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
>> Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
>> für eine korrekte Implementation.
>
> äh, nein, sorry.
>
>
>
Selbstverständlich wäre das ein Beweis für die Konformität einer Implementation.
Warum?
Die inhärente Sicherheit dieser Algorithmen ist viel geringer als die Wahrscheinlichkeit,
daß eine Ausgabe mit 256 Byte Länge (2048 Bit) rein zufällig Gleichheit aufweist.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2022-03-29 09:39 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jafrdoFecq7U1@mid.individual.net> |
| In reply to | #319287 |
On 28.03.22 22:29, Helmut Schellong wrote: > On 03/28/2022 20:23, Thomas Prufer wrote: >> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong >> <rip@schellong.biz> wrote: >> >>> Es ist _ganz generell_ richtig, was Du schreibst. >>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, >>> um die es hier geht. >>> >>> Diese hatte ich aufgelistet: >>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512, >>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. >>> |Diese Algorithmen sind alle kryptographisch. >>> >>> In der Implementierungsvorschrift der jeweiligen Entwickler der >>> Algorithmen >>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>> Diese habe ich jeweils durchgeführt! >>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>> Korrekter und beweiskräftiger geht es nicht! >> >> Das wurde ignoriert weil es kein Beweis ist... > > Beweis für was? "das Korrektheit beweist!" Es ist allgemein bekannt, daß man mit einem Test NIEMALS die KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn der Test fehl schlägt. Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test nicht bei der nächsten Iteration fehl schlägt. Der *Beweis* der Korrektheit eines Algorithmus oder seiner Implementation (im Folgenden "der Code") ist eine nicht-triviale, in der Regel mathematische Tätigkeit. > Diese Aussage wiederum beweist die Inkompetenz derer, die das ignorierten. > Warum? > Es geht um den Beweis einer korrekten Implementation! Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN. > Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben. Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist dadurch niche bewiesen, daß der Code bei der Durchführung anderer Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, immer noch die erwarteten Ergebnisse liefert. > Es ist dann der Beweis erbracht, daß die vorgenommene Implementation > werte-mäßig identisch mit der Referenz-Implementation der > Algorithmus-Entwickler ist. Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei den vom Entwickler vorgegebenen Eingabedaten die erwarteten Ausgabedaten erzeugt. Nichts anderes. > "This is a set of test vectors for conformance testing," > Hatte ich bereits gepostet. > "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben. > Reicht das nicht? > Falls nicht - was reicht denn dann? Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der Code bei der Eingeba *aller erlaubten* Eingabeparametern die erwarteten Ergebnisse liefern wird. Dazu empfehle ich "The Science of Programming" von David Gries. Ist schon gut abgehangen, aber imho immer noch gut. > Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des > Irrsinns. Nein, wir befinden uns hier im Bereich der Hybris. Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen korrekt, weil er gewisse Tests erfolgreich durchlaufen hat", insbesondere wenn es sich um sicherheitsrelevanten Code handelt. Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat fahren lassen. Josef
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2022-03-29 09:48 +0200 |
| Subject | Re: NIHS |
| Message-ID | <1ae54h9pkduj0jh22lrr07ah1fek1eurda@4ax.com> |
| In reply to | #319296 |
On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers <josef.moellers@invalid.invalid> wrote: (...) Merci, dann kann ich mir das zu schreiben ja sparen... >> Also ist der triviale und offensichtlich falsche Algorithmus: >> >> if <Testvektor1> then return <test result1> >> else if <Testvektor2> then return <test result2> >> usw. >> bewiesenermaßen korrekt? > >Irrelevant. >Andernfalls hätten die Entwickler diesen vorstehenden Algorithmus angegeben... offenbart Lücken... Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2022-03-29 12:35 +0000 |
| Subject | Re: NIHS |
| Message-ID | <t1uudq$ql6$3@dont-email.me> |
| In reply to | #319296 |
On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote: >> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung >> ergaben. > > Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der > vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist > dadurch niche bewiesen, daß der Code bei der Durchführung anderer > Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, immer > noch die erwarteten Ergebnisse liefert. Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist. Mehr können als einer können trotzdem drin sein. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 16:39 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1v5mn$3nv6$1@solani.org> |
| In reply to | #319311 |
On 03/29/2022 14:35, Reinhardt Behm wrote: > On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote: > > >>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung >>> ergaben. >> >> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der >> vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist >> dadurch niche bewiesen, daß der Code bei der Durchführung anderer >> Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, immer >> noch die erwarteten Ergebnisse liefert. > > > Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist. > Mehr können als einer können trotzdem drin sein. > > Das ist falsch - u.a. weil die Entwickler der Algorithmen etwas Gegenteiliges schreiben. Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet diese NG als Ort der Unerquicklichkeiten und Unwahrheiten. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2022-03-29 14:49 +0000 |
| Subject | Re: NIHS |
| Message-ID | <t1v69f$ql6$5@dont-email.me> |
| In reply to | #319317 |
On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote: > On 03/29/2022 14:35, Reinhardt Behm wrote: >> On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote: >> >> >>>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung >>>> ergaben. >>> >>> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der >>> vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist >>> dadurch niche bewiesen, daß der Code bei der Durchführung anderer >>> Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, >>> immer noch die erwarteten Ergebnisse liefert. >> >> >> Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist. >> Mehr können als einer können trotzdem drin sein. >> >> >> > Das ist falsch - u.a. weil die Entwickler der Algorithmen etwas > Gegenteiliges schreiben. > > Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet > diese NG als Ort der Unerquicklichkeiten und Unwahrheiten. Unerquicklich für dich, weil wir nicht in Bewunderung für den größten Programmierer alöler Zeiten erstarren. Dein Pech, dass es hier Leute gibt, die dir halt haushoch überlegen ind und dein Geprotze durchschauen. Versuchs doch irgendwo im Kindergarten. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 17:14 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1v7o0$3pdq$1@solani.org> |
| In reply to | #319318 |
On 03/29/2022 16:49, Reinhardt Behm wrote: > On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote: > >> On 03/29/2022 14:35, Reinhardt Behm wrote: >>> On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote: >>> >>> >>>>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung >>>>> ergaben. >>>> >>>> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der >>>> vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist >>>> dadurch niche bewiesen, daß der Code bei der Durchführung anderer >>>> Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, >>>> immer noch die erwarteten Ergebnisse liefert. >>> >>> >>> Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist. >>> Mehr können als einer können trotzdem drin sein. >>> >>> >>> >> Das ist falsch - u.a. weil die Entwickler der Algorithmen etwas >> Gegenteiliges schreiben. >> >> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet >> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten. > > Unerquicklich für dich, weil wir nicht in Bewunderung für den größten > Programmierer alöler Zeiten erstarren. Das ist massiv unlogisch! Denn ich schrieb mehrmals, daß ich keinen der Algorithmen selbst entwickelt habe. Wie kann ich denn da Bewunderung erwarten?! Wofür denn? Du hast folglich erneut eine wilde Behauptung aufgestellt. Schrieb ich doch vor Deiner vorstehenden Antwort. > Dein Pech, dass es hier Leute gibt, die dir halt haushoch überlegen ind > und dein Geprotze durchschauen. Versuchs doch irgendwo im Kindergarten. > > Welches Geprotze? Was ist an meinen Inhalten im Kontext Geprotze? Ich habe lediglich von anderen Entwicklern entwickelte Algorithmen hier aufgelistet. Mehr ist da nicht! Also schon wieder eine wilde Behauptung. Eine falsche Behauptung nach der anderen. 03/23/2022 21:39 =================================================================== Die Kern-Algorithmen sind nicht selbst entwickelt. Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512, sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. Diese Algorithmen sind alle kryptographisch. =================================================================== Geprotze? -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-03-29 18:11 +0200 |
| Subject | Re: NIHS |
| Message-ID | <40i6njszmjon.dlg@news.bartheld.net> |
| In reply to | #319318 |
On Tue, 29 Mar 2022 14:49:19 -0000 (UTC), Reinhardt Behm wrote: > On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote: >> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet >> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten. Herr Schellong möge bitte einfach weggehen, so er es nicht vertragen kann, daß ihm Menschen wegen seiner unerträglich peinlichen und penetrant vorgetragenen methodischen Schwächen, Irrationalität, Ignoranz, Selbstüberschätzung, Überheblichkeit und Erkenntnisresistenz den Spiegel vorhalten. Dieser Ort der Unerquicklichkeiten und Unwahrheiten wäre ein Besserer. > Unerquicklich für dich, weil wir nicht in Bewunderung für den größten > Programmierer aller Zeiten erstarren. Dein Pech, dass es hier Leute > gibt, die dir halt haushoch überlegen und dein Geprotze durchschauen. > Versuchs doch irgendwo im Kindergarten. Da wird er wohl auch intellektuelle Eigentore schießen. Zwecklos. Solche Gestalten gibts wohl in jedem unmoderierten Forum. Ich hoffe, die Angelegenheit möge sich auf ganz biologische Weise lösen. Bis dahin hilft das Killfile. Volker
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 19:10 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1vei3$3ug7$1@solani.org> |
| In reply to | #319324 |
On 03/29/2022 18:11, Volker Bartheld wrote: > On Tue, 29 Mar 2022 14:49:19 -0000 (UTC), Reinhardt Behm wrote: >> On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote: >>> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet >>> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten. > > Herr Schellong möge bitte einfach weggehen, so er es nicht vertragen > kann, daß ihm Menschen wegen seiner unerträglich peinlichen und > penetrant vorgetragenen methodischen Schwächen, Irrationalität, > Ignoranz, Selbstüberschätzung, Überheblichkeit und Erkenntnisresistenz > den Spiegel vorhalten. Dieser Ort der Unerquicklichkeiten und > Unwahrheiten wäre ein Besserer. Kommt nicht in Frage. >> Unerquicklich für dich, weil wir nicht in Bewunderung für den größten >> Programmierer aller Zeiten erstarren. Dein Pech, dass es hier Leute >> gibt, die dir halt haushoch überlegen und dein Geprotze durchschauen. >> Versuchs doch irgendwo im Kindergarten. > > Da wird er wohl auch intellektuelle Eigentore schießen. Zwecklos. Solche > Gestalten gibts wohl in jedem unmoderierten Forum. Ich hoffe, die > Angelegenheit möge sich auf ganz biologische Weise lösen. Bis dahin > hilft das Killfile. > > Falsch gedacht. Irgendwann wird mein Klon weitermachen. Es müssen doch schließlich Reaktionen auf die Falschaussagen hier erfolgen. Und im Kindergarten wird man mich nicht nehmen. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 15:14 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1v0na$3kjj$1@solani.org> |
| In reply to | #319296 |
On 03/29/2022 09:39, Josef Moellers wrote: > > On 28.03.22 22:29, Helmut Schellong wrote: >> On 03/28/2022 20:23, Thomas Prufer wrote: >>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote: >>> >>>> Es ist _ganz generell_ richtig, was Du schreibst. >>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht. >>>> >>>> Diese hatte ich aufgelistet: >>>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512, >>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. >>>> |Diese Algorithmen sind alle kryptographisch. >>>> >>>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen >>>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>>> Diese habe ich jeweils durchgeführt! >>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>>> Korrekter und beweiskräftiger geht es nicht! >>> >>> Das wurde ignoriert weil es kein Beweis ist... >> >> Beweis für was? > > "das Korrektheit beweist!" > > Es ist allgemein bekannt, daß man mit einem Test NIEMALS die KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn der Test fehl schlägt. > Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test nicht bei der nächsten Iteration fehl schlägt. > Der *Beweis* der Korrektheit eines Algorithmus oder seiner Implementation (im Folgenden "der Code") ist eine nicht-triviale, in der Regel mathematische Tätigkeit. Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können. Das gilt jedoch nicht für kryptographische Algorithmen, die hier aufgelistet sind. >> Diese Aussage wiederum beweist die Inkompetenz derer, die das ignorierten. >> Warum? >> Es geht um den Beweis einer korrekten Implementation! > > Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN. |This is a set of test vectors for conformance testing, Die Entwickler von kryptographischen Algorithmen haben das aber ausgesagt. Willst Du denen widersprechen? 'conformance' heißt 'Übereinstimmung'. Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation korrekt. Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_. Das sagen die Entwickler aus! Und Punkt. >> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben. > > Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist dadurch niche bewiesen, daß der Code bei der Durchführung anderer Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, immer noch die erwarteten Ergebnisse liefert. Falsch. Die Entwickler haben geeignete Tests vorgegeben, um die Korrektheit beweisen zu können. Die Entwickler wissen, daß wenn alle Tests Übereinstimmung ergeben, auch alle weiteren denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau. Schließlich sind die Algorithmen deterministisch. |We, the designers of Rabbit, hereby state that no hidden weaknesses have |been inserted by us in the Rabbit algorithm. |The key expansion stage guarantees a one-to-one correspondence be- |tween the key, the state and the counter, which prevents key redun- |dancy. It also distributes the key bits in an optimal way to prepare |for the the system iteration. |The correctness of the code on different platforms is verified by generating and comparing test vectors. >> Es ist dann der Beweis erbracht, daß die vorgenommene Implementation >> werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist. > > Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei den vom Entwickler vorgegebenen Eingabedaten die erwarteten Ausgabedaten erzeugt. Nichts anderes. Erneut falsche Behauptung. Beweise zur Abwechslung doch mal Deine Behauptung. Ich habe meine nämlich mehrfach bewiesen, anhand der Entwickler-Testprozeduren. >> "This is a set of test vectors for conformance testing," >> Hatte ich bereits gepostet. > > >> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben. >> Reicht das nicht? >> Falls nicht - was reicht denn dann? > > Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der Code bei der Eingeba *aller erlaubten* Eingabeparametern die erwarteten Ergebnisse liefern wird. > Dazu empfehle ich "The Science of Programming" von David Gries. Ist schon gut abgehangen, aber imho immer noch gut. Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein weiteres Buch brauche ich nicht. Ich habe u.a. die Bücher von Knuth. Ein mathematischer Beweis ist bei allen Algorithmen des Kontextes prinzipiell unmöglich. Fehler werden gegebenenfalls lange Zeit nach Veröffentlichung des Algo von untersuchenden Experten mitgeteilt. Die _Entwickler_ wissen, daß wenn alle Tests Übereinstimmung ergeben, auch alle weiteren denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. (s.o.) >> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des Irrsinns. > > Nein, wir befinden uns hier im Bereich der Hybris. Falsch. Ich bin ganz konkret praxisbezogen ziemlich kenntnisreich auf diesem Gebiet. > Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen korrekt, weil er gewisse Tests erfolgreich durchlaufen hat", insbesondere wenn es sich um sicherheitsrelevanten Code handelt. Alle genannten Algorithmen wurden und werden weltweit millionenfach korrekt implementiert und konkret hunderte-millionenfach in sicherheitsfordernder Umgebung verwendet. MD5 und RC4 werden trotz Korrumpierung vor vielen Jahren weiterhin verwendet. > Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat fahren lassen. > > So wird das seit vielleicht 150 Jahren weltweit getan. Dies funktioniert auch, wenn nicht Jahrzehnte lang Warnungen von Experten ignoriert werden. Extrem selten haben Brücken überraschend versagt (Windresonanz). |Ein Prüfbericht stellt klar: Am Unglück in Genua (2018) war nicht das Wetter schuld. |An einem entscheidenden Träger wurde seit 1993 keine Wartung vorgenommen (Bau 1967). |Selbst Warnungen des Bauplaners waren ignoriert worden (~1985). |Der Bericht von vier Universitätsprofessoren, die von der Untersuchungsrichterin Angela Nutini |mit der Prüfung der Einsturzursachen beauftragt wurden, lese sich "wie ein Urteil", Es ist sogar verwunderlich, daß es _erst_ 2018 zum Unglück kam. Du willst die Kenntnisse der Entwickler und Gepflogenheiten im Bereich der kryptographischen Cipher offensichtlich nicht anerkennen. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2022-03-29 20:04 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jah026Fl9i0U1@mid.individual.net> |
| In reply to | #319314 |
On 29.03.22 15:14, Helmut Schellong wrote: > On 03/29/2022 09:39, Josef Moellers wrote: >> >> On 28.03.22 22:29, Helmut Schellong wrote: >>> On 03/28/2022 20:23, Thomas Prufer wrote: >>>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong >>>> <rip@schellong.biz> wrote: >>>> >>>>> Es ist _ganz generell_ richtig, was Du schreibst. >>>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, >>>>> um die es hier geht. >>>>> >>>>> Diese hatte ich aufgelistet: >>>>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512, >>>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. >>>>> |Diese Algorithmen sind alle kryptographisch. >>>>> >>>>> In der Implementierungsvorschrift der jeweiligen Entwickler der >>>>> Algorithmen >>>>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>>>> Diese habe ich jeweils durchgeführt! >>>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>>>> Korrekter und beweiskräftiger geht es nicht! >>>> >>>> Das wurde ignoriert weil es kein Beweis ist... >>> >>> Beweis für was? >> >> "das Korrektheit beweist!" >> >> Es ist allgemein bekannt, daß man mit einem Test NIEMALS die >> KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn >> der Test fehl schlägt. >> Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung >> erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test >> nicht bei der nächsten Iteration fehl schlägt. >> Der *Beweis* der Korrektheit eines Algorithmus oder seiner >> Implementation (im Folgenden "der Code") ist eine nicht-triviale, in >> der Regel mathematische Tätigkeit. > > Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können. > Das gilt jedoch nicht für kryptographische Algorithmen, die hier > aufgelistet sind. Nein. Es gibt keinen Test, der die Korrektheit eines Codes (d.h. Algorithmus UND Implementation) *beweisen* kann! Das ist allgemein bekannt und ich möchte mal behaupten, dessen sind sich die Entwickler des Codes auch bewußt. > >>> Diese Aussage wiederum beweist die Inkompetenz derer, die das >>> ignorierten. >>> Warum? >>> Es geht um den Beweis einer korrekten Implementation! >> >> Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN. > > |This is a set of test vectors for conformance testing, > > Die Entwickler von kryptographischen Algorithmen haben das aber ausgesagt. > Willst Du denen widersprechen? Nein, ich will ihnen nicht widersprechen, daß dies Test Vektoren für das "conformance testing" sind. So ein Test *beweist* eben NICHT die Korrektheit eines Codes sondern nur, daß dieser gewissen Standards entspricht: https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing Da steht nix von "correctness" sondern nur "meets a defined set of standards". Auch der Wikipedia-Artikel https://en.wikipedia.org/wiki/Conformance_testing sprint nicht von "correctness" sondern nur von "performs according to its specified standards.". Wie gesagt/geschrieben: Man kann mit einem noch so guten Test nicht die Korrektheit *beweisen". Man kann sein vertrauen darin durch immer längeres Test immer weiter vergrößern, eine 100% Sicherheit gibt kein Test! Durch das hinzufügen von noch mehr Tests wirst Du Dich dem Ziel "100% Korrektheit bewiesen" ständig asymptotisch annähern, es aber nie erreichen. Im Wikipedia-Artikel zu "Software Testing" steht auch genau drin: "understand the risks of software implementation." und weiter "Software testing can provide objective, independent information about the quality of software and risk of its failure to users or sponsors" Da steht also eindeutig, daß es Risiken gibt (mir fällt kein anderes Risiko ein als daß der Code Fehler enthält) und man kann durch Testen diese *Risiken* erkennen und das Vertrauen erhöhen. > 'conformance' heißt 'Übereinstimmung'. > Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation > korrekt. Übereinstimmung womit? > Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_. > Das sagen die Entwickler aus! > Und Punkt. Tja, dann glaube das bitte weiter. >>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung >>> ergaben. >> >> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der >> vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist >> dadurch niche bewiesen, daß der Code bei der Durchführung anderer >> Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, >> immer noch die erwarteten Ergebnisse liefert. > > Falsch. > Die Entwickler haben geeignete Tests vorgegeben, um die Korrektheit > beweisen zu können. > Die Entwickler wissen, daß wenn alle Tests Übereinstimmung ergeben, auch > alle weiteren > denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. Das heißt, sie können ganz genau angeben, wie viele Tests und mit welchen Werten sie diese Tests durchführen müssen, um die Korrektheit zu 100% zu beweisen? Ich behaupte, daß ihnen bewußt ist, daß dies nicht möglich ist. > Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau. > Schließlich sind die Algorithmen deterministisch. *Jeder* auf einem Computer implementierter Algorithmus ist deterministisch. Trotzdem kann man von vielen Algorithmen z.B. nicht einmal theoretisch beweisen, daß sie jemals enden (Halteproblem). Ergo kann man dies und auch das Gegenteil auch durch die besten Tests nicht beweisen. > |We, the designers of Rabbit, hereby state that no hidden weaknesses have > |been inserted by us in the Rabbit algorithm. Das beruhigt ungemein. > |The key expansion stage guarantees a one-to-one correspondence be- > |tween the key, the state and the counter, which prevents key redun- > |dancy. It also distributes the key bits in an optimal way to prepare > |for the the system iteration. > |The correctness of the code on different platforms is verified by > generating and comparing test vectors. Tja, das würde ich gerne mit ihnen diskutieren. Ich finde gerade keine Email-Adresse, aber das bekomme ich hin! >>> Es ist dann der Beweis erbracht, daß die vorgenommene Implementation >>> werte-mäßig identisch mit der Referenz-Implementation der >>> Algorithmus-Entwickler ist. >> >> Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei >> den vom Entwickler vorgegebenen Eingabedaten die erwarteten >> Ausgabedaten erzeugt. Nichts anderes. > > Erneut falsche Behauptung. > Beweise zur Abwechslung doch mal Deine Behauptung. Wie bitte soll den durch das Testen mit von den Entwicklern vorgegebenen Test-Vektoren bewiesen werden, daß Elemente, die NICHT in den Test-Vektoren enthalten sind, auch die korrekten Ergebnisse liefern? > Ich habe meine nämlich mehrfach bewiesen, anhand der > Entwickler-Testprozeduren. Also hast nicht Du das bewiesen, sondern die Entwickler haben das behauptet und Du hast das nur wiedergegeben. NB Unser Sohn ist Professor für Mathematik an der Universität in Aarhus und ich habe ihn gerade mal (per Email) gefragt, ob er mir ggf die Email-Adresse von Mette Vesterager, die ist am Center for Subjectivity Research an der Uni Kopenhagen, besorgen kann. Mal gucken, was daraus wird. >>> "This is a set of test vectors for conformance testing," >>> Hatte ich bereits gepostet. >> >> >>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben. >>> Reicht das nicht? >>> Falls nicht - was reicht denn dann? >> >> Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der >> Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von >> Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der >> Code bei der Eingeba *aller erlaubten* Eingabeparametern die >> erwarteten Ergebnisse liefern wird. >> Dazu empfehle ich "The Science of Programming" von David Gries. Ist >> schon gut abgehangen, aber imho immer noch gut. > > Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein > weiteres Buch brauche ich nicht. Ja, dann erübrigt sich ja die Debatte mit Dir, oh Du weiser Mann. Zwanzig Programmiersprachen ... wow! Ich erstarre in Ehrfurcht. Ich habe 1981 angefangen zu arbeiten (damals bei der Nixdorf Computer AG) und die Computerei ist mein Hobby. Wie viele Programmiersprachen ich kenne ... ich habe sie nie gezählt. Das ist ja auch völlig irrelevant! Und wenn Du 100 Programmiersprachen könntest, so hast Du immer noch nicht begriffen, was ich sagen will: Daß man mit Testen nie und nimmer die Korrektheit eines Codes beweisen kann. Siehe hierzu auch https://de.wikipedia.org/wiki/Korrektheit_(Informatik) Oder die Folien hier: https://pi4.informatik.uni-mannheim.de/pi4.data/content/courses/2005-ws/pi1/slides/pi1-5b-2006-02-02.pdf "Testen nur das Vertrauen in die Korrektheit eines Programms erhöhen, nicht aber die Korrektheit beweisen." Oder die Folien hier: https://www.mathematik.uni-marburg.de/~gumm/Lehre/WS07/PraktischeInformatikI/Folien/14_Korrektheit.pdf "Durch Testen kann man nur Anwesenheit von Fehlern feststellen, nicht aber ihre Abwesenheit (E. Dijkstra)" Dijstra's Essay "On the reliability of programs" kannst Du übrigens hier nachlesen: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html Ich zitiere mal (sinngemäß) einen Herrn Schellong: "Willst Du dem widersprechen?" Dijstra's These wird übrigens hier diskutiert: https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/ Und auch dort steht "Tests don’t tell you that code works in cases that aren’t tested. Tests tell you code works in the cases that are tested. If you want it to work in some other case, you add a test, or expand an existing test to cover the case you’re interested in." > Ich habe u.a. die Bücher von Knuth. Ja, die sind gut. Was sagt Knuth denn zum Testen? http://www.informit.com/articles/article.aspx?p=1193856 "As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t." OK, es geht um "Unit Tests", aber auch das sind Tests und er lehnt sie ab! > Ein mathematischer Beweis ist bei allen Algorithmen des Kontextes > prinzipiell unmöglich. > Fehler werden gegebenenfalls lange Zeit nach Veröffentlichung des Algo > von untersuchenden Experten mitgeteilt. > > Die _Entwickler_ wissen, daß wenn alle Tests Übereinstimmung ergeben, > auch alle weiteren > denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. (s.o.) Das wage ich zu bezweifeln. Schau'n 'mer mal, ob unser Ältester mir die Adresse von Mette besorgen kann, dann frage ich sie. >>> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des >>> Irrsinns. >> >> Nein, wir befinden uns hier im Bereich der Hybris. > > Falsch. > Ich bin ganz konkret praxisbezogen ziemlich kenntnisreich auf diesem > Gebiet. Wie gesagt: Hybris. >> Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen >> korrekt, weil er gewisse Tests erfolgreich durchlaufen hat", >> insbesondere wenn es sich um sicherheitsrelevanten Code handelt. > > Alle genannten Algorithmen wurden und werden weltweit millionenfach > korrekt implementiert > und konkret hunderte-millionenfach in sicherheitsfordernder Umgebung > verwendet. Ich sage ja nicht, daß sie fehlerhaft SIND, ich behaupte nur, daß man durch Testen niemals eine Korrektheit BEWEISen kann. Das ist in der Informatik allgemein bekannt und akzeptiert. Daß man trotzdem testet hat sicherlich damit zu tun, daß der mathematisch-logische KorrektheitsBEWEIS eines nicht-trivialen Stücks Code selber in besonderem Maße nicht-trivial ist und keiner sich die Arbeit machen will. Ich habe mkich während meine Studiums mit "weakest precondition"s und "postcondition"s 'rumschlagen dürfen. Es hat KEINEN Spaß gemacht ... > MD5 und RC4 werden trotz Korrumpierung vor vielen Jahren weiterhin > verwendet. Wie gesagt: Ich behaupt nicht, daß sie fehlerhaft SIND. >> Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als >> "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr >> freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat >> fahren lassen. >> >> > > So wird das seit vielleicht 150 Jahren weltweit getan. Nein, in erster Instanz werden Brücken *berechnet*. Die Statiker *berechnen*, wie viel Beton und wie viel Armierung und sonstiges da 'rein muß, damit eine Brücke mit einer bestimmten Spannweite eine bestimmte Last aufnehmen kann. Am Ende wird, um das noch einmal zu *verifizieren* ein Belastungstest gemacht. Aber wenn das nicht *berechnet* ist, dann würde kein LKW-Fahrer darüber fahren wollen. [...] > Du willst die Kenntnisse der Entwickler und Gepflogenheiten im Bereich > der kryptographischen Cipher offensichtlich nicht anerkennen. Und Du willst die (Er)-Kenntnisse der theoretischen Informatik nicht anerkennen. Josef
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-30 02:02 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t206n9$4c0j$1@solani.org> |
| In reply to | #319329 |
On 03/29/2022 20:04, Josef Moellers wrote: > > On 29.03.22 15:14, Helmut Schellong wrote: >> On 03/29/2022 09:39, Josef Moellers wrote: >>> >>> On 28.03.22 22:29, Helmut Schellong wrote: >>>> On 03/28/2022 20:23, Thomas Prufer wrote: >>>>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote: >>>>> >>>>>> Es ist _ganz generell_ richtig, was Du schreibst. >>>>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht. >>>>>> >>>>>> Diese hatte ich aufgelistet: >>>>>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>>>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512, >>>>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. >>>>>> |Diese Algorithmen sind alle kryptographisch. >>>>>> >>>>>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen >>>>>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>>>>> Diese habe ich jeweils durchgeführt! >>>>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>>>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>>>>> Korrekter und beweiskräftiger geht es nicht! >>>>> >>>>> Das wurde ignoriert weil es kein Beweis ist... >>>> >>>> Beweis für was? >>> >>> "das Korrektheit beweist!" >>> >>> Es ist allgemein bekannt, daß man mit einem Test NIEMALS die KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn der Test fehl schlägt. >>> Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test nicht bei der nächsten Iteration fehl schlägt. >>> Der *Beweis* der Korrektheit eines Algorithmus oder seiner Implementation (im Folgenden "der Code") ist eine nicht-triviale, in der Regel mathematische Tätigkeit. >> >> Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können. >> Das gilt jedoch nicht für kryptographische Algorithmen, die hier aufgelistet sind. > > Nein. Es gibt keinen Test, der die Korrektheit eines Codes (d.h. Algorithmus UND Implementation) *beweisen* kann! > Das ist allgemein bekannt und ich möchte mal behaupten, dessen sind sich die Entwickler des Codes auch bewußt. Nein, diese Entwickler sagen das Gegenteil. Habe ich gepostet - wurde beharrlich ignoriert. |This is a set of test vectors for conformance testing, |The correctness of the code on different platforms is verified by generating and comparing test vectors. |We, the designers of Rabbit, hereby state that no hidden weaknesses have |been inserted by us in the Rabbit algorithm. |The key expansion stage guarantees a one-to-one correspondence be- |tween the key, the state and the counter, which prevents key redun- |dancy. It also distributes the key bits in an optimal way to prepare |for the the system iteration. Hatte ich bereits gepostet. Es wird die Korrektheit einer Implementation nachgewiesen. Und es wird ausgesagt, daß alle denkbaren Zwischenwerte bei den Testvektoren ebenfalls Übereinstimmen würden (one-to-one correspondence). Immer wieder lesen - vielleicht kommt's dann irgendwann. Auch folgende Übersetzung hatte ich bereits gepostet: o Zuerst steht da, daß Test-Vektoren zum Testen der Übereinstimmung nachfolgend vorhanden sind. o Der zweite Satz sagt aus, daß die Korrektheit des Codes auf unterschiedlichen Plattformen . nachgewiesen wird durch generieren und vergleichen von Test-Vektoren. >>>> Diese Aussage wiederum beweist die Inkompetenz derer, die das ignorierten. >>>> Warum? >>>> Es geht um den Beweis einer korrekten Implementation! >>> >>> Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN. >> >> |This is a set of test vectors for conformance testing, >> >> Die Entwickler von kryptographischen Algorithmen haben das aber ausgesagt. >> Willst Du denen widersprechen? > > Nein, ich will ihnen nicht widersprechen, daß dies Test Vektoren für das "conformance testing" sind. So ein Test *beweist* eben NICHT die Korrektheit eines Codes sondern nur, daß dieser gewissen Standards entspricht: Doch, entsprechende Aussagen der Entwickler postete ich oben in Wiederholung. Du widersprichst den Entwicklern wiederholt. |The correctness of the code on different platforms is verified by generating and comparing test vectors. > https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing > Da steht nix von "correctness" sondern nur "meets a defined set of standards". Irrelevant. > Auch der Wikipedia-Artikel https://en.wikipedia.org/wiki/Conformance_testing sprint nicht von "correctness" sondern nur von "performs according to its specified standards.". Irrelevant. |The correctness of the code on different platforms is verified by generating and comparing test vectors. Diese Aussagen sind aus der Dokumentation der aufgelisteten kryptographischen Algorithmen. Die von Dir gegebenen Dokumentationen sind _nicht_ aus dieser Menge - und daher irrelevant! > Wie gesagt/geschrieben: Man kann mit einem noch so guten Test nicht die Korrektheit *beweisen". Man kann sein vertrauen darin durch immer längeres Test immer weiter vergrößern, eine 100% Sicherheit gibt kein Test! > Durch das hinzufügen von noch mehr Tests wirst Du Dich dem Ziel "100% Korrektheit bewiesen" ständig asymptotisch annähern, es aber nie erreichen. > > Im Wikipedia-Artikel zu "Software Testing" steht auch genau drin: > "understand the risks of software implementation." und weiter "Software testing can provide objective, independent information about the quality of software and risk of its failure to users or sponsors" Da steht also eindeutig, daß es Risiken gibt (mir fällt kein anderes Risiko ein als daß der Code Fehler enthält) und man kann durch Testen diese *Risiken* erkennen und das Vertrauen erhöhen. Alles irrelevant. Es geht um die Korrektheit einer Implementation der aufgeführten kryptographischen Algorithmen. >> 'conformance' heißt 'Übereinstimmung'. >> Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation korrekt. > > Übereinstimmung womit? Mit der Ausgabe des jeweiligen Algorithmus', mit der zugehörigen response. >> Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_. >> Das sagen die Entwickler aus! >> Und Punkt. > > Tja, dann glaube das bitte weiter. Ich habe allen Grund dazu: |The correctness of the code on different platforms is verified by generating and comparing test vectors. >>>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben. >>> >>> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist dadurch niche bewiesen, daß der Code bei der Durchführung anderer Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, immer noch die erwarteten Ergebnisse liefert. >> >> Falsch. >> Die Entwickler haben geeignete Tests vorgegeben, um die Korrektheit beweisen zu können. >> Die Entwickler wissen, daß wenn alle Tests Übereinstimmung ergeben, auch alle weiteren >> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. > > Das heißt, sie können ganz genau angeben, wie viele Tests und mit welchen Werten sie diese Tests durchführen müssen, um die Korrektheit zu 100% zu beweisen? > Ich behaupte, daß ihnen bewußt ist, daß dies nicht möglich ist. |The correctness of the code on different platforms is verified by generating and comparing test vectors. Willst Du irgendwann solche Aussagen der Entwickler respektieren? >> Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau. >> Schließlich sind die Algorithmen deterministisch. > > *Jeder* auf einem Computer implementierter Algorithmus ist deterministisch. Ja. Aber ich meine selbstverständlich, daß die Ausgabe-Sequenzen der kryptographischen Algorithmen deterministisch sind. Gleicher Key - gleiche Sequenz. Wurde bereits durchgekaut. > Trotzdem kann man von vielen Algorithmen z.B. nicht einmal theoretisch beweisen, daß sie jemals enden (Halteproblem). Ergo kann man dies und auch das Gegenteil auch durch die besten Tests nicht beweisen. Irrelevant. Es geht um die Korrektheit einer Implementation nur der aufgeführten kryptographischen Algorithmen. >> |We, the designers of Rabbit, hereby state that no hidden weaknesses have >> |been inserted by us in the Rabbit algorithm. > > Das beruhigt ungemein. Du versuchst, die Entwickler lächerlich zu machen. >> |The key expansion stage guarantees a one-to-one correspondence be- >> |tween the key, the state and the counter, which prevents key redun- >> |dancy. It also distributes the key bits in an optimal way to prepare >> |for the the system iteration. >> |The correctness of the code on different platforms is verified by generating and comparing test vectors. > > Tja, das würde ich gerne mit ihnen diskutieren. > Ich finde gerade keine Email-Adresse, aber das bekomme ich hin! Vielleicht machtest Du Dich damit lächerlich. Ich habe etwa 100 Seiten nur zu Rabbit gelesen. Und ich vertraue diesen Entwicklern - die haben mich überzeugt. >>>> Es ist dann der Beweis erbracht, daß die vorgenommene Implementation >>>> werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist. >>> >>> Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei den vom Entwickler vorgegebenen Eingabedaten die erwarteten Ausgabedaten erzeugt. Nichts anderes. >> >> Erneut falsche Behauptung. >> Beweise zur Abwechslung doch mal Deine Behauptung. > > Wie bitte soll den durch das Testen mit von den Entwicklern vorgegebenen Test-Vektoren bewiesen werden, daß Elemente, die NICHT in den Test-Vektoren enthalten sind, auch die korrekten Ergebnisse liefern? Aufgrund des spezifischen Verhaltens des jeweiligen Algorithmus'. Diese Algorithmen können aufgrund ihres Aufbaus nicht anders. >> Ich habe meine nämlich mehrfach bewiesen, anhand der Entwickler-Testprozeduren. > > Also hast nicht Du das bewiesen, sondern die Entwickler haben das behauptet und Du hast das nur wiedergegeben. Ja, "anhand der Entwickler-Testprozeduren." Wenn ich die korrekt anwende, habe ich es mit Hilfe dieser Prozeduren bewiesen. Geht es nun mit Haarespalten weiter? > NB Unser Sohn ist Professor für Mathematik an der Universität in Aarhus und ich habe ihn gerade mal (per Email) gefragt, ob er mir ggf die Email-Adresse von Mette Vesterager, die ist am Center for Subjectivity Research an der Uni Kopenhagen, besorgen kann. Mal gucken, was daraus wird. https://ku-dk.academia.edu/MetteVesterager Es sind vier Entwickler. Es kann notwendig sein, herauszufinden, welcher welche Texte erarbeitet hatte. >>>> "This is a set of test vectors for conformance testing," >>>> Hatte ich bereits gepostet. >>> >>> >>>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben. >>>> Reicht das nicht? >>>> Falls nicht - was reicht denn dann? >>> >>> Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der Code bei der Eingeba *aller erlaubten* Eingabeparametern die erwarteten Ergebnisse liefern wird. >>> Dazu empfehle ich "The Science of Programming" von David Gries. Ist schon gut abgehangen, aber imho immer noch gut. >> >> Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein weiteres Buch brauche ich nicht. > > Ja, dann erübrigt sich ja die Debatte mit Dir, oh Du weiser Mann. Ich habe nirgendwo behauptet, daß ich weise bin. > Zwanzig Programmiersprachen ... wow! Ich erstarre in Ehrfurcht. Das ist eine Tatsache. Allerdings - wie ich schrieb - mehr oder weniger gut. > Ich habe 1981 angefangen zu arbeiten (damals bei der Nixdorf Computer AG) und die Computerei ist mein Hobby. Wie viele Programmiersprachen ich kenne ... ich habe sie nie gezählt. > Das ist ja auch völlig irrelevant! Und wenn Du 100 Programmiersprachen könntest, so hast Du immer noch nicht begriffen, was ich sagen will: Daß man mit Testen nie und nimmer die Korrektheit eines Codes beweisen kann. Es ist überhaupt nicht irrelevant, welche Programmiersprachen man kann! > Siehe hierzu auch > https://de.wikipedia.org/wiki/Korrektheit_(Informatik) > > Oder die Folien hier: > https://pi4.informatik.uni-mannheim.de/pi4.data/content/courses/2005-ws/pi1/slides/pi1-5b-2006-02-02.pdf > "Testen nur das Vertrauen in die Korrektheit eines Programms erhöhen, > nicht aber die Korrektheit beweisen." > > Oder die Folien hier: > https://www.mathematik.uni-marburg.de/~gumm/Lehre/WS07/PraktischeInformatikI/Folien/14_Korrektheit.pdf > "Durch Testen kann man nur Anwesenheit von > Fehlern feststellen, nicht aber ihre > Abwesenheit (E. Dijkstra)" > > Dijstra's Essay "On the reliability of programs" kannst Du übrigens hier nachlesen: > https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html > > Ich zitiere mal (sinngemäß) einen Herrn Schellong: "Willst Du dem widersprechen?" > > Dijstra's These wird übrigens hier diskutiert: > https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/ > Und auch dort steht "Tests don’t tell you that code works in cases that aren’t tested. Tests tell you code works in the cases that are tested. If you want it to work in some other case, you add a test, or expand an existing test to cover the case you’re interested in." Das alles ist allerdings im Kontext irrelevant. >> Ich habe u.a. die Bücher von Knuth. > > Ja, die sind gut. > Was sagt Knuth denn zum Testen? Ich arbeite jetzt nicht diese Bücher durch... Wozu auch?, wenn ich spezifische, zum Algorithmus passende Testprozeduren habe! > http://www.informit.com/articles/article.aspx?p=1193856 > "As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t." > OK, es geht um "Unit Tests", aber auch das sind Tests und er lehnt sie ab! > >> Ein mathematischer Beweis ist bei allen Algorithmen des Kontextes prinzipiell unmöglich. >> Fehler werden gegebenenfalls lange Zeit nach Veröffentlichung des Algo von untersuchenden Experten mitgeteilt. >> >> Die _Entwickler_ wissen, daß wenn alle Tests Übereinstimmung ergeben, auch alle weiteren >> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. (s.o.) > > Das wage ich zu bezweifeln. Schau'n 'mer mal, ob unser Ältester mir die Adresse von Mette besorgen kann, dann frage ich sie. Es kann sein, daß sie als eine von vier Entwicklern nicht alle Fragen beantworten kann. >>>> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des Irrsinns. >>> >>> Nein, wir befinden uns hier im Bereich der Hybris. >> >> Falsch. >> Ich bin ganz konkret praxisbezogen ziemlich kenntnisreich auf diesem Gebiet. > > Wie gesagt: Hybris. Nein, ich bin ziemlich kenntnisreich auf diesem Gebiet. Das bedeutet, daß ich deutlich mehr weiß, als die große Mehrheit. Ein Experte bin ich nicht für diese Algorithmen - allerdings für die Sprache C. >>> Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen korrekt, weil er gewisse Tests erfolgreich durchlaufen hat", insbesondere wenn es sich um sicherheitsrelevanten Code handelt. >> >> Alle genannten Algorithmen wurden und werden weltweit millionenfach korrekt implementiert >> und konkret hunderte-millionenfach in sicherheitsfordernder Umgebung verwendet. > > Ich sage ja nicht, daß sie fehlerhaft SIND, ich behaupte nur, daß man durch Testen niemals eine Korrektheit BEWEISen kann. > Das ist in der Informatik allgemein bekannt und akzeptiert. > Daß man trotzdem testet hat sicherlich damit zu tun, daß der mathematisch-logische KorrektheitsBEWEIS eines nicht-trivialen Stücks Code selber in besonderem Maße nicht-trivial ist und keiner sich die Arbeit machen will. Ich habe mkich während meine Studiums mit "weakest precondition"s und "postcondition"s 'rumschlagen dürfen. Es hat KEINEN Spaß gemacht ... > >> MD5 und RC4 werden trotz Korrumpierung vor vielen Jahren weiterhin verwendet. > > Wie gesagt: Ich behaupt nicht, daß sie fehlerhaft SIND. > >>> Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat fahren lassen. >>> >>> >> >> So wird das seit vielleicht 150 Jahren weltweit getan. > > Nein, in erster Instanz werden Brücken *berechnet*. Die Statiker *berechnen*, wie viel Beton und wie viel Armierung und sonstiges da 'rein muß, damit eine Brücke mit einer bestimmten Spannweite eine bestimmte Last aufnehmen kann. Am Ende wird, um das noch einmal zu *verifizieren* ein Belastungstest gemacht. Aber wenn das nicht *berechnet* ist, dann würde kein LKW-Fahrer darüber fahren wollen. Diese Berechnungen werden aber begutachtet und eventuell offiziell abgenommen. Das ist in "bewiesenermaßen korrekt gebaut" enthalten. Du willst wieder Haare spalten. > [...] > >> Du willst die Kenntnisse der Entwickler und Gepflogenheiten im Bereich >> der kryptographischen Cipher offensichtlich nicht anerkennen. > > Und Du willst die (Er)-Kenntnisse der theoretischen Informatik nicht anerkennen. > > Nur, wenn enger zugehörige Erkenntnisse die allgemeinen Erkenntnisse überschreiben. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2022-03-30 09:34 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jaifg8FtpfbU1@mid.individual.net> |
| In reply to | #319334 |
On 30.03.22 02:02, Helmut Schellong wrote: > On 03/29/2022 20:04, Josef Moellers wrote: >> >> On 29.03.22 15:14, Helmut Schellong wrote: >>> On 03/29/2022 09:39, Josef Moellers wrote: >>>> >>>> On 28.03.22 22:29, Helmut Schellong wrote: >>>>> On 03/28/2022 20:23, Thomas Prufer wrote: >>>>>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong >>>>>> <rip@schellong.biz> wrote: >>>>>> >>>>>>> Es ist _ganz generell_ richtig, was Du schreibst. >>>>>>> Du ignorierst jedoch die konkrete Praxis mit genau den >>>>>>> Algorithmen, um die es hier geht. >>>>>>> >>>>>>> Diese hatte ich aufgelistet: >>>>>>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>>>>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, >>>>>>> sha2_512, >>>>>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. >>>>>>> |Diese Algorithmen sind alle kryptographisch. >>>>>>> >>>>>>> In der Implementierungsvorschrift der jeweiligen Entwickler der >>>>>>> Algorithmen >>>>>>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>>>>>> Diese habe ich jeweils durchgeführt! >>>>>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>>>>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>>>>>> Korrekter und beweiskräftiger geht es nicht! >>>>>> >>>>>> Das wurde ignoriert weil es kein Beweis ist... >>>>> >>>>> Beweis für was? >>>> >>>> "das Korrektheit beweist!" >>>> >>>> Es ist allgemein bekannt, daß man mit einem Test NIEMALS die >>>> KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich >>>> wenn der Test fehl schlägt. >>>> Du kannst so lange Testen, wie Du willst, Du kannst 100% >>>> Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen >>>> können, daß der Test nicht bei der nächsten Iteration fehl schlägt. >>>> Der *Beweis* der Korrektheit eines Algorithmus oder seiner >>>> Implementation (im Folgenden "der Code") ist eine nicht-triviale, in >>>> der Regel mathematische Tätigkeit. >>> >>> Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können. >>> Das gilt jedoch nicht für kryptographische Algorithmen, die hier >>> aufgelistet sind. >> >> Nein. Es gibt keinen Test, der die Korrektheit eines Codes (d.h. >> Algorithmus UND Implementation) *beweisen* kann! >> Das ist allgemein bekannt und ich möchte mal behaupten, dessen sind >> sich die Entwickler des Codes auch bewußt. > > Nein, diese Entwickler sagen das Gegenteil. > Habe ich gepostet - wurde beharrlich ignoriert. > > |This is a set of test vectors for conformance testing, > |The correctness of the code on different platforms is verified by > generating and comparing test vectors. Seufz ... Den Unterschied zwischen "verified" und "proven" ist Dir bekannt? > |We, the designers of Rabbit, hereby state that no hidden weaknesses have > |been inserted by us in the Rabbit algorithm. > |The key expansion stage guarantees a one-to-one correspondence be- > |tween the key, the state and the counter, which prevents key redun- > |dancy. It also distributes the key bits in an optimal way to prepare > |for the the system iteration. > > Hatte ich bereits gepostet. > > Es wird die Korrektheit einer Implementation nachgewiesen. Nein, es wird *verifiziert*, nicht *bewiesen*. > Und es wird ausgesagt, daß alle denkbaren Zwischenwerte bei den > Testvektoren > ebenfalls Übereinstimmen würden (one-to-one correspondence). > Immer wieder lesen - vielleicht kommt's dann irgendwann. "Würden" heißt nicht "sind". Testen heißt eine Stichprobe nehmen und wenn Du Dich mal mit Statistik und Stichprobeln beschäftigst, wirst Du feststellen, daß zu jeder Stichprobengröße ein "Vertrauensintervall" für den mit Hilfe der Stichprobe bestimmten Wert gehört, also ein Bereich, innerhalb dessen der Wert liegen wird. Gehen wir hier davon aus, daß Du 100% Sicherheit haben willst, bekommst Du mit einer Stichprobe eben nur einen Bereich *um* die 100% und da es mehr als 100%ige Sicherheit nicht geben wird, eben einen Bereich unterhalb der 100%. > Auch folgende Übersetzung hatte ich bereits gepostet: > o Zuerst steht da, daß Test-Vektoren zum Testen der Übereinstimmung > nachfolgend vorhanden sind. > o Der zweite Satz sagt aus, daß die Korrektheit des Codes auf > unterschiedlichen Plattformen > . nachgewiesen wird durch generieren und vergleichen von Test-Vektoren. > >>>>> Diese Aussage wiederum beweist die Inkompetenz derer, die das >>>>> ignorierten. >>>>> Warum? >>>>> Es geht um den Beweis einer korrekten Implementation! >>>> >>>> Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN. >>> >>> |This is a set of test vectors for conformance testing, >>> >>> Die Entwickler von kryptographischen Algorithmen haben das aber >>> ausgesagt. >>> Willst Du denen widersprechen? >> >> Nein, ich will ihnen nicht widersprechen, daß dies Test Vektoren für >> das "conformance testing" sind. So ein Test *beweist* eben NICHT die >> Korrektheit eines Codes sondern nur, daß dieser gewissen Standards >> entspricht: > > Doch, entsprechende Aussagen der Entwickler postete ich oben in > Wiederholung. > Du widersprichst den Entwicklern wiederholt. Nunja, schau'n 'mer mal. Unser Ältester hat mich auf die Webseite von Mette Vesterager verwiesen, er ist da etwas flotter mit, so etwas im akademischen Umfeld zu finden als ich. Ich habe Mette dann auch mal angeschrieben, mal sehen, was sie dazu sagt. > |The correctness of the code on different platforms is verified by > generating and comparing test vectors. Wieder dieses Wörtchen *verified* und NICHT *proven* ... >> https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing >> >> Da steht nix von "correctness" sondern nur "meets a defined set of >> standards". > > Irrelevant. ... weil nicht zu Deiner Argumentation passend. >> Auch der Wikipedia-Artikel >> https://en.wikipedia.org/wiki/Conformance_testing sprint nicht von >> "correctness" sondern nur von "performs according to its specified >> standards.". > > Irrelevant. > |The correctness of the code on different platforms is verified by > generating and comparing test vectors. *verified* > Diese Aussagen sind aus der Dokumentation der aufgelisteten > kryptographischen Algorithmen. > Die von Dir gegebenen Dokumentationen sind _nicht_ aus dieser Menge - > und daher irrelevant! ... weil Deiner Argumentation widersprechend. Ganz einfach gesagt: es ist mir völlig wurscht, was die Entwickler *behaupten*, wenn sie es denn überhaupt tun. Fakt ist, daß es in der Informatik gar nicht mehr diskutiert wird, ob man mit Testen die Korrektheit *beweisen* kann, es ist Konsens, daß dem NICHT so ist. >> Wie gesagt/geschrieben: Man kann mit einem noch so guten Test nicht >> die Korrektheit *beweisen". Man kann sein vertrauen darin durch immer >> längeres Test immer weiter vergrößern, eine 100% Sicherheit gibt kein >> Test! >> Durch das hinzufügen von noch mehr Tests wirst Du Dich dem Ziel "100% >> Korrektheit bewiesen" ständig asymptotisch annähern, es aber nie >> erreichen. >> >> Im Wikipedia-Artikel zu "Software Testing" steht auch genau drin: >> "understand the risks of software implementation." und weiter >> "Software testing can provide objective, independent information about >> the quality of software and risk of its failure to users or sponsors" >> Da steht also eindeutig, daß es Risiken gibt (mir fällt kein anderes >> Risiko ein als daß der Code Fehler enthält) und man kann durch Testen >> diese *Risiken* erkennen und das Vertrauen erhöhen. > > Alles irrelevant. > Es geht um die Korrektheit einer Implementation der aufgeführten > kryptographischen Algorithmen. ... undd die kann man mit Testen NICHT *beweisen*. Man kann die Korrektheit des Algorithmus mit mathematischen Methoden beweisen und ich gehe stark davon aus, daß die Entwickler das getan haben, sonst ist der ganze Rabbit Algorithmus für dir Tonne. Danach will man sicherstellen, daß eine Implementation fehlerfrei ist und, da man den mathematischen Beweis nicht nochmal und nochmal und nochmal für jede Implementation machen will, setzt man auf Tests um das zu *verifizieren*. >>> 'conformance' heißt 'Übereinstimmung'. >>> Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation >>> korrekt. >> >> Übereinstimmung womit? > > Mit der Ausgabe des jeweiligen Algorithmus', mit der zugehörigen response. ... ausschließlich für die gegebenen Werte des "test vectors". Für Werte, die NICHT in den "test vectors" sind, kann man das zwar annehmen, und es wird in den allermeisten Fällen auch so sein, aber *beweisen* tut es das nicht. >>> Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_. >>> Das sagen die Entwickler aus! >>> Und Punkt. >> >> Tja, dann glaube das bitte weiter. > > Ich habe allen Grund dazu: > |The correctness of the code on different platforms is verified by > generating and comparing test vectors. *verified*, nicht *proven*. >>>>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung >>>>> ergaben. >>>> >>>> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der >>>> vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist >>>> dadurch niche bewiesen, daß der Code bei der Durchführung anderer >>>> Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, >>>> immer noch die erwarteten Ergebnisse liefert. >>> >>> Falsch. >>> Die Entwickler haben geeignete Tests vorgegeben, um die Korrektheit >>> beweisen zu können. >>> Die Entwickler wissen, daß wenn alle Tests Übereinstimmung ergeben, >>> auch alle weiteren >>> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. >> >> Das heißt, sie können ganz genau angeben, wie viele Tests und mit >> welchen Werten sie diese Tests durchführen müssen, um die Korrektheit >> zu 100% zu beweisen? >> Ich behaupte, daß ihnen bewußt ist, daß dies nicht möglich ist. > > |The correctness of the code on different platforms is verified by > generating and comparing test vectors. > Willst Du irgendwann solche Aussagen der Entwickler respektieren? Du verdrehst ihnen die Worte im Mund und machst aus "verified" ein "bewiesen". >>> Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau. >>> Schließlich sind die Algorithmen deterministisch. >> >> *Jeder* auf einem Computer implementierter Algorithmus ist >> deterministisch. > > Ja. > Aber ich meine selbstverständlich, daß die Ausgabe-Sequenzen > der kryptographischen Algorithmen deterministisch sind. > Gleicher Key - gleiche Sequenz. > Wurde bereits durchgekaut. Ja, eben mathematisch-logisch nur für die Keys, die im "test vector" sind, und NICHT für alle anderen Keys, die NICHT im "test vector" sind. Daher "verified", nicht "proven". >> Trotzdem kann man von vielen Algorithmen z.B. nicht einmal theoretisch >> beweisen, daß sie jemals enden (Halteproblem). Ergo kann man dies und >> auch das Gegenteil auch durch die besten Tests nicht beweisen. > > Irrelevant. > Es geht um die Korrektheit einer Implementation nur der aufgeführten > kryptographischen Algorithmen. Wenn etwas *grundsätzlich* nicht funktioniert, kann es im Einzelfall auch nicht funktionieren. >>> |We, the designers of Rabbit, hereby state that no hidden weaknesses >>> have >>> |been inserted by us in the Rabbit algorithm. >> >> Das beruhigt ungemein. > > Du versuchst, die Entwickler lächerlich zu machen. Sorry, aber der Satz fordert das ja geradezu heraus. >>> |The key expansion stage guarantees a one-to-one correspondence be- >>> |tween the key, the state and the counter, which prevents key redun- >>> |dancy. It also distributes the key bits in an optimal way to prepare >>> |for the the system iteration. >>> |The correctness of the code on different platforms is verified by >>> generating and comparing test vectors. >> >> Tja, das würde ich gerne mit ihnen diskutieren. >> Ich finde gerade keine Email-Adresse, aber das bekomme ich hin! > > Vielleicht machtest Du Dich damit lächerlich. Schau'n 'mer mal ... Mail ist 'raus. Jan (unser Sohn) sei Dank für den Verweis auf Mettes Email-Adresse. > Ich habe etwa 100 Seiten nur zu Rabbit gelesen. > Und ich vertraue diesen Entwicklern - die haben mich überzeugt. Ich zweifele ihren Code ja auch gar nicht an. Was ich anzweifele sind Deine Behauptungen, man könne durch Testen die Korrektheit beweisen und da sprechen ALLE dagegen, bis auf Du. >>>>> Es ist dann der Beweis erbracht, daß die vorgenommene Implementation >>>>> werte-mäßig identisch mit der Referenz-Implementation der >>>>> Algorithmus-Entwickler ist. >>>> >>>> Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei >>>> den vom Entwickler vorgegebenen Eingabedaten die erwarteten >>>> Ausgabedaten erzeugt. Nichts anderes. >>> >>> Erneut falsche Behauptung. >>> Beweise zur Abwechslung doch mal Deine Behauptung. >> >> Wie bitte soll den durch das Testen mit von den Entwicklern >> vorgegebenen Test-Vektoren bewiesen werden, daß Elemente, die NICHT in >> den Test-Vektoren enthalten sind, auch die korrekten Ergebnisse liefern? > > Aufgrund des spezifischen Verhaltens des jeweiligen Algorithmus'. > Diese Algorithmen können aufgrund ihres Aufbaus nicht anders. Nunja, ich verstehe jetzt von kryptologischen Algorithmen nicht sonderlich viel, aber daß sie interne an diversen Stellen die Daten der "test vector"en kräftig durcheinander würfeln, sollte klar sein. Und jetzt aus "mit dem Wert m kommt das Erwartete heraus" und "mit dem Wert n kommt das Erwartete heraus" zu schließen, daß dann auch für alle Werte zwischen m und n das Erwartete heraus kommt, ist eben ziemlich gewagt. Wenn wir uns darauf einigen könnten, daß es nicht möglich ist, durch Testen die Korrektheit eines Codes (d.h. Algorithmus UND Implementation) zu *beweisen*, dann könnten wir diese Debatte beenden. >>> Ich habe meine nämlich mehrfach bewiesen, anhand der >>> Entwickler-Testprozeduren. >> >> Also hast nicht Du das bewiesen, sondern die Entwickler haben das >> behauptet und Du hast das nur wiedergegeben. > > Ja, "anhand der Entwickler-Testprozeduren." > Wenn ich die korrekt anwende, habe ich es mit Hilfe dieser Prozeduren > bewiesen. > Geht es nun mit Haarespalten weiter? Nunja, Du hast eben die Entwickler Testprozeduren angewendet und es sind die zu erwartenden Ergebnisse herausgekommen. Das ist eben kein "Beweis", wie so ziemlich die gesamte Informatik-Welt weiß. >> NB Unser Sohn ist Professor für Mathematik an der Universität in >> Aarhus und ich habe ihn gerade mal (per Email) gefragt, ob er mir ggf >> die Email-Adresse von Mette Vesterager, die ist am Center for >> Subjectivity Research an der Uni Kopenhagen, besorgen kann. Mal >> gucken, was daraus wird. > > https://ku-dk.academia.edu/MetteVesterager Ja, da war ich gestern abend auch, da fand ich aber auf Anhieb ihre Email-Adresse nicht. Von unserem Ältesten habe ich das hier: https://cfs.ku.dk/staff/?pure=en/persons/307267 und da steht ihre Email-Adresse 'drin. > Es sind vier Entwickler. > Es kann notwendig sein, herauszufinden, welcher welche Texte erarbeitet > hatte. Ich hoffe, daß Mette Vesterager die Frage weiterleiten wird, wenn sie sie nicht selber beantworten kann >>>>> "This is a set of test vectors for conformance testing," >>>>> Hatte ich bereits gepostet. >>>> >>>> >>>>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben. >>>>> Reicht das nicht? >>>>> Falls nicht - was reicht denn dann? >>>> >>>> Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der >>>> Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von >>>> Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der >>>> Code bei der Eingeba *aller erlaubten* Eingabeparametern die >>>> erwarteten Ergebnisse liefern wird. >>>> Dazu empfehle ich "The Science of Programming" von David Gries. Ist >>>> schon gut abgehangen, aber imho immer noch gut. >>> >>> Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - >>> ein weiteres Buch brauche ich nicht. >> >> Ja, dann erübrigt sich ja die Debatte mit Dir, oh Du weiser Mann. > > Ich habe nirgendwo behauptet, daß ich weise bin. > >> Zwanzig Programmiersprachen ... wow! Ich erstarre in Ehrfurcht. > > Das ist eine Tatsache. > Allerdings - wie ich schrieb - mehr oder weniger gut. > >> Ich habe 1981 angefangen zu arbeiten (damals bei der Nixdorf Computer >> AG) und die Computerei ist mein Hobby. Wie viele Programmiersprachen >> ich kenne ... ich habe sie nie gezählt. >> Das ist ja auch völlig irrelevant! Und wenn Du 100 Programmiersprachen >> könntest, so hast Du immer noch nicht begriffen, was ich sagen will: >> Daß man mit Testen nie und nimmer die Korrektheit eines Codes beweisen >> kann. > > Es ist überhaupt nicht irrelevant, welche Programmiersprachen man kann! Doch, wenn man Grundprinzipien der Informatik nicht kennt, kennt man sie mit einer Srache nicht und mit 100 Sprachen auch nicht. >> Siehe hierzu auch >> https://de.wikipedia.org/wiki/Korrektheit_(Informatik) >> >> Oder die Folien hier: >> https://pi4.informatik.uni-mannheim.de/pi4.data/content/courses/2005-ws/pi1/slides/pi1-5b-2006-02-02.pdf >> >> "Testen nur das Vertrauen in die Korrektheit eines Programms erhöhen, >> nicht aber die Korrektheit beweisen." >> >> Oder die Folien hier: >> https://www.mathematik.uni-marburg.de/~gumm/Lehre/WS07/PraktischeInformatikI/Folien/14_Korrektheit.pdf >> >> "Durch Testen kann man nur Anwesenheit von >> Fehlern feststellen, nicht aber ihre >> Abwesenheit (E. Dijkstra)" >> >> Dijstra's Essay "On the reliability of programs" kannst Du übrigens >> hier nachlesen: >> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html >> >> Ich zitiere mal (sinngemäß) einen Herrn Schellong: "Willst Du dem >> widersprechen?" >> >> Dijstra's These wird übrigens hier diskutiert: >> https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/ >> >> Und auch dort steht "Tests don’t tell you that code works in cases >> that aren’t tested. Tests tell you code works in the cases that are >> tested. If you want it to work in some other case, you add a test, or >> expand an existing test to cover the case you’re interested in." > > Das alles ist allerdings im Kontext irrelevant. Nein, es sei denn, Du akzeptierst, daß ein Test NIEMALS die Korrektheit eines Codes *beweisen* kann, sondern eine Implementation nur *verifizieren* kann. >>> Ich habe u.a. die Bücher von Knuth. >> >> Ja, die sind gut. >> Was sagt Knuth denn zum Testen? > > Ich arbeite jetzt nicht diese Bücher durch... Brauchst Du nicht, im "Fundamental Algorithms" Steht schon im ersten Kapitel "Basic Concepts" ein Beweis und der besteht nicht aus einzelnen Werten sondern ist ein mathematisch-logischer Beweis, daß der Algorithmus (Euklids Algorithmus zur Berechnung des größten gemeinsamen Teilers) korrekt ist. Bei meiner Softcover-Ausgabe von 1973 ab Seite 14. > Wozu auch?, wenn ich spezifische, zum Algorithmus passende > Testprozeduren habe! Da ist noch was: hast Du schon mal darüber nachgedacht, daß die Entwickler *selber* diese Test-Vektoren bestimmt haben? Und ist Dir vielleicht mal der Gedanke gekommen, daß man als Entwickler einem gewissen "Bias" unterworfen ist, da.h. man tendiert dazu, in eine Richtung zu denken? >> http://www.informit.com/articles/article.aspx?p=1193856 >> "As to your real question, the idea of immediate compilation and "unit >> tests" appeals to me only rarely, when I’m feeling my way in a totally >> unknown environment and need feedback about what works and what doesn’t." >> OK, es geht um "Unit Tests", aber auch das sind Tests und er lehnt sie >> ab! >> >>> Ein mathematischer Beweis ist bei allen Algorithmen des Kontextes >>> prinzipiell unmöglich. >>> Fehler werden gegebenenfalls lange Zeit nach Veröffentlichung des >>> Algo von untersuchenden Experten mitgeteilt. >>> >>> Die _Entwickler_ wissen, daß wenn alle Tests Übereinstimmung ergeben, >>> auch alle weiteren >>> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. >>> (s.o.) >> >> Das wage ich zu bezweifeln. Schau'n 'mer mal, ob unser Ältester mir >> die Adresse von Mette besorgen kann, dann frage ich sie. > > Es kann sein, daß sie als eine von vier Entwicklern nicht alle Fragen > beantworten kann. Schau'n 'mer mal. Ich hoffe ja, daß sie meine Frage weiterleiten wird, wenn sie sie schon nicht selber beantworten kann. >>>>> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des >>>>> Irrsinns. >>>> >>>> Nein, wir befinden uns hier im Bereich der Hybris. >>> >>> Falsch. >>> Ich bin ganz konkret praxisbezogen ziemlich kenntnisreich auf diesem >>> Gebiet. >> >> Wie gesagt: Hybris. > > Nein, ich bin ziemlich kenntnisreich auf diesem Gebiet. > Das bedeutet, daß ich deutlich mehr weiß, als die große Mehrheit. > Ein Experte bin ich nicht für diese Algorithmen - allerdings für die > Sprache C. Irrelevant und überheblich ... eben Hybris. Und die ist insbesondere im Bereicht der Sicherheit lebensgefährlich. [...] >> Nein, in erster Instanz werden Brücken *berechnet*. Die Statiker >> *berechnen*, wie viel Beton und wie viel Armierung und sonstiges da >> 'rein muß, damit eine Brücke mit einer bestimmten Spannweite eine >> bestimmte Last aufnehmen kann. Am Ende wird, um das noch einmal zu >> *verifizieren* ein Belastungstest gemacht. Aber wenn das nicht >> *berechnet* ist, dann würde kein LKW-Fahrer darüber fahren wollen. > > Diese Berechnungen werden aber begutachtet und eventuell offiziell > abgenommen. > Das ist in "bewiesenermaßen korrekt gebaut" enthalten. > Du willst wieder Haare spalten. Nein, Du willst mir partout widersprechen. Genau das habe ich geschrieben: Brücken werden nicht einfach so gebaut und dann mit LKW getestet, sie werden berechnet, daß sie der Belastung stand halten, dann werden sie gebaut und dann fährt man noch mal mit einer Kolonne LKW 'drüber um das zu ... *verifizieren*. Leider ist "mein Statiker" (Schwiegerpapa) schon vor über 30 Jahren verstorben, sonst hätte ich ihn gefragt, wie so etwas genau abläuft. >> [...] >> >>> Du willst die Kenntnisse der Entwickler und Gepflogenheiten im Bereich >>> der kryptographischen Cipher offensichtlich nicht anerkennen. >> >> Und Du willst die (Er)-Kenntnisse der theoretischen Informatik nicht >> anerkennen. >> >> > > Nur, wenn enger zugehörige Erkenntnisse die allgemeinen Erkenntnisse > überschreiben. Ich sehe nicht, wie man die Erkenntis, daß Testen niemals die Korrektheit eines Codes *beweisen* kann, überschreiben kann. Insbesondere bei etwas so Komplexen wie Verschlüsselungsalgorithmen und dem Bereich der Sicherheit. Wie gesagt: ich gehe davon aus, daß die Entwickler die Korrektheit ihres Algorithmus' mathematisch bewiesen haben und lediglich die Korrektheit der Implementation mittels Tests *verifizieren*. Josef
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-30 13:36 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t21fcg$54b6$1@solani.org> |
| In reply to | #319339 |
On 03/30/2022 09:34, Josef Moellers wrote: > > On 30.03.22 02:02, Helmut Schellong wrote: >> On 03/29/2022 20:04, Josef Moellers wrote: >>> >>> On 29.03.22 15:14, Helmut Schellong wrote: >>>> On 03/29/2022 09:39, Josef Moellers wrote: >>>>> >>>>> On 28.03.22 22:29, Helmut Schellong wrote: >>>>>> On 03/28/2022 20:23, Thomas Prufer wrote: >>>>>>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote: >>>>>>> >>>>>>>> Es ist _ganz generell_ richtig, was Du schreibst. >>>>>>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht. >>>>>>>> >>>>>>>> Diese hatte ich aufgelistet: >>>>>>>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>>>>>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512, >>>>>>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert. >>>>>>>> |Diese Algorithmen sind alle kryptographisch. >>>>>>>> >>>>>>>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen >>>>>>>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>>>>>>> Diese habe ich jeweils durchgeführt! >>>>>>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>>>>>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>>>>>>> Korrekter und beweiskräftiger geht es nicht! >>>>>>> >>>>>>> Das wurde ignoriert weil es kein Beweis ist... >>>>>> >>>>>> Beweis für was? >>>>> >>>>> "das Korrektheit beweist!" >>>>> >>>>> Es ist allgemein bekannt, daß man mit einem Test NIEMALS die KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn der Test fehl schlägt. >>>>> Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test nicht bei der nächsten Iteration fehl schlägt. >>>>> Der *Beweis* der Korrektheit eines Algorithmus oder seiner Implementation (im Folgenden "der Code") ist eine nicht-triviale, in der Regel mathematische Tätigkeit. >>>> >>>> Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können. >>>> Das gilt jedoch nicht für kryptographische Algorithmen, die hier aufgelistet sind. >>> >>> Nein. Es gibt keinen Test, der die Korrektheit eines Codes (d.h. Algorithmus UND Implementation) *beweisen* kann! >>> Das ist allgemein bekannt und ich möchte mal behaupten, dessen sind sich die Entwickler des Codes auch bewußt. >> >> Nein, diese Entwickler sagen das Gegenteil. >> Habe ich gepostet - wurde beharrlich ignoriert. >> >> |This is a set of test vectors for conformance testing, >> |The correctness of the code on different platforms is verified by generating and comparing test vectors. > > Seufz ... Den Unterschied zwischen "verified" und "proven" ist Dir bekannt? Du und mindestens ein Anderer verstehen die Semantik der Sprache nicht richtig. 'verified' kann mit 'nachgewiesen' übersetzt werden. Der Satzgegenstand ist die 'correctness of the code'. Diese wird nachgewiesen durch Vergleich mit Test-Vektoren. Wie oft muß ich das noch schreiben. >> |We, the designers of Rabbit, hereby state that no hidden weaknesses have >> |been inserted by us in the Rabbit algorithm. >> |The key expansion stage guarantees a one-to-one correspondence be- >> |tween the key, the state and the counter, which prevents key redun- >> |dancy. It also distributes the key bits in an optimal way to prepare >> |for the the system iteration. >> >> Hatte ich bereits gepostet. >> >> Es wird die Korrektheit einer Implementation nachgewiesen. > > Nein, es wird *verifiziert*, nicht *bewiesen*. 'verified' kann mit 'nachgewiesen' übersetzt werden. to verify nachweisen to verify sth. etw. beweisen >> Und es wird ausgesagt, daß alle denkbaren Zwischenwerte bei den Testvektoren >> ebenfalls Übereinstimmen würden (one-to-one correspondence). >> Immer wieder lesen - vielleicht kommt's dann irgendwann. > > "Würden" heißt nicht "sind". Testen heißt eine Stichprobe nehmen und wenn Du Dich mal mit Statistik und Stichprobeln beschäftigst, wirst Du feststellen, daß zu jeder Stichprobengröße ein "Vertrauensintervall" für den mit Hilfe der Stichprobe bestimmten Wert gehört, also ein Bereich, innerhalb dessen der Wert liegen wird. Ich habe mich in der Vergangenheit intensiv damit beschäftigt. 1978 kaufte ich den TI59 mit mehreren Programm-Modulen. Da ist viel Mathematik und Statistik dabei. Du betreibst wieder Haarspalterei. Wenn man sich mit Zahlen wie 2^512 beschäftigt, sieht man, daß das dem Wert 10^154 entspricht. Das ist weit jenseits von Yotta:Quadrillion:10^24. (154 ~ 512/3,322) Die Zahlen sind derart groß, daß sie sich der statistischen Anwendung in der normalen Praxis entziehen. Ich kann nicht hier bei mir einen Rechner aufstellen und diesen 20 Jahre rechnen lassen. Auch nicht 2 Jahre - wohl 2 Monate. > Gehen wir hier davon aus, daß Du 100% Sicherheit haben willst, bekommst Du mit einer Stichprobe eben nur einen Bereich *um* die 100% und da es mehr als 100%ige Sicherheit nicht geben wird, eben einen Bereich unterhalb der 100%. Diese Überlegungen sind unzutreffend im Zusammenhang mit den hier relevanten Algorithmen. Diese Algorithmen arbeiten ausschließlich mit elementaren Integer-Operationen. Es gibt da eine eins-zu-eins-Korrespondenz durch den ganzen Algorithmus hindurch. >> Auch folgende Übersetzung hatte ich bereits gepostet: >> o Zuerst steht da, daß Test-Vektoren zum Testen der Übereinstimmung nachfolgend vorhanden sind. >> o Der zweite Satz sagt aus, daß die Korrektheit des Codes auf unterschiedlichen Plattformen >> . nachgewiesen wird durch generieren und vergleichen von Test-Vektoren. >> >>>>>> Diese Aussage wiederum beweist die Inkompetenz derer, die das ignorierten. >>>>>> Warum? >>>>>> Es geht um den Beweis einer korrekten Implementation! >>>>> >>>>> Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN. >>>> >>>> |This is a set of test vectors for conformance testing, >>>> >>>> Die Entwickler von kryptographischen Algorithmen haben das aber ausgesagt. >>>> Willst Du denen widersprechen? >>> >>> Nein, ich will ihnen nicht widersprechen, daß dies Test Vektoren für das "conformance testing" sind. So ein Test *beweist* eben NICHT die Korrektheit eines Codes sondern nur, daß dieser gewissen Standards entspricht: >> >> Doch, entsprechende Aussagen der Entwickler postete ich oben in Wiederholung. >> Du widersprichst den Entwicklern wiederholt. > > Nunja, schau'n 'mer mal. Unser Ältester hat mich auf die Webseite von Mette Vesterager verwiesen, er ist da etwas flotter mit, so etwas im akademischen Umfeld zu finden als ich. Ich habe Mette dann auch mal angeschrieben, mal sehen, was sie dazu sagt. Es kommt sehr darauf an, welche Worte und Sätze da genau kommuniziert werden. Damit die Kommunikation nicht fehlgeleitet sein wird. >> |The correctness of the code on different platforms is verified by generating and comparing test vectors. > > Wieder dieses Wörtchen *verified* und NICHT *proven* ... Und wieder das Nichterkennen der Semantik der Sprache. >>> https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing >>> Da steht nix von "correctness" sondern nur "meets a defined set of standards". >> >> Irrelevant. > > ... weil nicht zu Deiner Argumentation passend. Nein, weil es sich wegbewegt vom Thema der kryptographischen Algorithmen. Du willst aus dem Kontext-Thema ausbrechen, weil Dir die Aussagen der Entwickler (Wissenschaftler) der Kontext-Algorithmen nicht passen, auf die ich mich beharrlich beziehe. >>> Auch der Wikipedia-Artikel https://en.wikipedia.org/wiki/Conformance_testing sprint nicht von "correctness" sondern nur von "performs according to its specified standards.". >> >> Irrelevant. >> |The correctness of the code on different platforms is verified by generating and comparing test vectors. > > *verified* Und wieder das Nichterkennen der Semantik der Sprache. Du fährst den Entwicklern der Algorithmen ständig über den Arsch. >> Diese Aussagen sind aus der Dokumentation der aufgelisteten kryptographischen Algorithmen. >> Die von Dir gegebenen Dokumentationen sind _nicht_ aus dieser Menge - und daher irrelevant! > > ... weil Deiner Argumentation widersprechend. Nein, Du hast erkannt, daß Du im Kontext nicht mehr wirksam argumentieren kannst und willst deshalb aus dem Kontext ausbrechen. > Ganz einfach gesagt: es ist mir völlig wurscht, was die Entwickler *behaupten*, wenn sie es denn überhaupt tun. Fakt ist, daß es in der Informatik gar nicht mehr diskutiert wird, ob man mit Testen die Korrektheit *beweisen* kann, es ist Konsens, daß dem NICHT so ist. Diese Allgemeinplätze sind im Kontext eben nicht anwendbar. Das willst Du partout nicht erkennen. >>> Wie gesagt/geschrieben: Man kann mit einem noch so guten Test nicht die Korrektheit *beweisen". Man kann sein vertrauen darin durch immer längeres Test immer weiter vergrößern, eine 100% Sicherheit gibt kein Test! >>> Durch das hinzufügen von noch mehr Tests wirst Du Dich dem Ziel "100% Korrektheit bewiesen" ständig asymptotisch annähern, es aber nie erreichen. >>> >>> Im Wikipedia-Artikel zu "Software Testing" steht auch genau drin: >>> "understand the risks of software implementation." und weiter "Software testing can provide objective, independent information about the quality of software and risk of its failure to users or sponsors" Da steht also eindeutig, daß es Risiken gibt (mir fällt kein anderes Risiko ein als daß der Code Fehler enthält) und man kann durch Testen diese *Risiken* erkennen und das Vertrauen erhöhen. >> >> Alles irrelevant. >> Es geht um die Korrektheit einer Implementation der aufgeführten kryptographischen Algorithmen. > > ... undd die kann man mit Testen NICHT *beweisen*. > Man kann die Korrektheit des Algorithmus mit mathematischen Methoden beweisen und ich gehe stark davon aus, daß die Entwickler das getan haben, sonst ist der ganze Rabbit Algorithmus für dir Tonne. > Danach will man sicherstellen, daß eine Implementation fehlerfrei ist und, da man den mathematischen Beweis nicht nochmal und nochmal und nochmal für jede Implementation machen will, setzt man auf Tests um das zu *verifizieren*. Du hast absolut keine Ahnung von den konkret implementierten Algorithmen des Kontextes. Deshalb kann bei Dir auch nicht/nie die richtige Erkenntnis kommen, solange Dir dies unbekannt ist. >>>> 'conformance' heißt 'Übereinstimmung'. >>>> Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation korrekt. >>> >>> Übereinstimmung womit? >> >> Mit der Ausgabe des jeweiligen Algorithmus', mit der zugehörigen response. > > ... ausschließlich für die gegebenen Werte des "test vectors". Für Werte, die NICHT in den "test vectors" sind, kann man das zwar annehmen, und es wird in den allermeisten Fällen auch so sein, aber *beweisen* tut es das nicht. Es wird in _allen_ Fällen garantiert so sein. Du verstehst auch hier nicht die Semantik, die in der eins-zu-eins-Korrespondenz innerhalb der Algorithmen steckt. Da sind Hopfen und Malz eben verloren. >>>> Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_. >>>> Das sagen die Entwickler aus! >>>> Und Punkt. >>> >>> Tja, dann glaube das bitte weiter. >> >> Ich habe allen Grund dazu: >> |The correctness of the code on different platforms is verified by generating and comparing test vectors. > > *verified*, nicht *proven*. Und wieder das Nichterkennen der Semantik der Sprache. Das ist offenbar ein Tick von Dir. >>>>>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben. >>>>> >>>>> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist dadurch niche bewiesen, daß der Code bei der Durchführung anderer Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden, immer noch die erwarteten Ergebnisse liefert. >>>> >>>> Falsch. >>>> Die Entwickler haben geeignete Tests vorgegeben, um die Korrektheit beweisen zu können. >>>> Die Entwickler wissen, daß wenn alle Tests Übereinstimmung ergeben, auch alle weiteren >>>> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. >>> >>> Das heißt, sie können ganz genau angeben, wie viele Tests und mit welchen Werten sie diese Tests durchführen müssen, um die Korrektheit zu 100% zu beweisen? >>> Ich behaupte, daß ihnen bewußt ist, daß dies nicht möglich ist. >> >> |The correctness of the code on different platforms is verified by generating and comparing test vectors. >> Willst Du irgendwann solche Aussagen der Entwickler respektieren? > > Du verdrehst ihnen die Worte im Mund und machst aus "verified" ein "bewiesen". Nein, 'verify' kann mit 'beweisen' gültig übersetzt werden. Ich habe Aussagen der Entwickler zitiert. Inwiefern verdrehe ich den Entwicklern dadurch die Worte im Mund? >>>> Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau. >>>> Schließlich sind die Algorithmen deterministisch. >>> >>> *Jeder* auf einem Computer implementierter Algorithmus ist deterministisch. >> >> Ja. >> Aber ich meine selbstverständlich, daß die Ausgabe-Sequenzen >> der kryptographischen Algorithmen deterministisch sind. >> Gleicher Key - gleiche Sequenz. >> Wurde bereits durchgekaut. > > Ja, eben mathematisch-logisch nur für die Keys, die im "test vector" sind, und NICHT für alle anderen Keys, die NICHT im "test vector" sind. > Daher "verified", nicht "proven". Und wieder das Nichterkennen der Semantik der Sprache. Das ist offenbar ein Tick von Dir. >>> Trotzdem kann man von vielen Algorithmen z.B. nicht einmal theoretisch beweisen, daß sie jemals enden (Halteproblem). Ergo kann man dies und auch das Gegenteil auch durch die besten Tests nicht beweisen. >> >> Irrelevant. >> Es geht um die Korrektheit einer Implementation nur der aufgeführten kryptographischen Algorithmen. > > Wenn etwas *grundsätzlich* nicht funktioniert, kann es im Einzelfall auch nicht funktionieren. Es geht um die Korrektheit einer Implementation nur der aufgeführten kryptographischen Algorithmen. Das ist der Kontext! >>>> |We, the designers of Rabbit, hereby state that no hidden weaknesses have >>>> |been inserted by us in the Rabbit algorithm. >>> >>> Das beruhigt ungemein. >> >> Du versuchst, die Entwickler lächerlich zu machen. > > Sorry, aber der Satz fordert das ja geradezu heraus. Eventuell, wenn man die Dokumentationen der Entwickler nicht ausreichend kennt. >>>> |The key expansion stage guarantees a one-to-one correspondence be- >>>> |tween the key, the state and the counter, which prevents key redun- >>>> |dancy. It also distributes the key bits in an optimal way to prepare >>>> |for the the system iteration. >>>> |The correctness of the code on different platforms is verified by generating and comparing test vectors. >>> >>> Tja, das würde ich gerne mit ihnen diskutieren. >>> Ich finde gerade keine Email-Adresse, aber das bekomme ich hin! >> >> Vielleicht machtest Du Dich damit lächerlich. > > Schau'n 'mer mal ... Mail ist 'raus. Jan (unser Sohn) sei Dank für den Verweis auf Mettes Email-Adresse. > >> Ich habe etwa 100 Seiten nur zu Rabbit gelesen. >> Und ich vertraue diesen Entwicklern - die haben mich überzeugt. > > Ich zweifele ihren Code ja auch gar nicht an. Was ich anzweifele sind Deine Behauptungen, man könne durch Testen die Korrektheit beweisen und da sprechen ALLE dagegen, bis auf Du. Nein, die Entwickler sagen das auch. Du willst das jedoch nicht wahrhaben und spielst daher mit sprachlicher Semantik herum. Du kennst einfach nicht die Natur der konkret implementierten Algorithmen. Das macht es schwierig bis unmöglich, Eigenschaften zu erkennen. >>>>>> Es ist dann der Beweis erbracht, daß die vorgenommene Implementation >>>>>> werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist. >>>>> >>>>> Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei den vom Entwickler vorgegebenen Eingabedaten die erwarteten Ausgabedaten erzeugt. Nichts anderes. >>>> >>>> Erneut falsche Behauptung. >>>> Beweise zur Abwechslung doch mal Deine Behauptung. >>> >>> Wie bitte soll den durch das Testen mit von den Entwicklern vorgegebenen Test-Vektoren bewiesen werden, daß Elemente, die NICHT in den Test-Vektoren enthalten sind, auch die korrekten Ergebnisse liefern? >> >> Aufgrund des spezifischen Verhaltens des jeweiligen Algorithmus'. >> Diese Algorithmen können aufgrund ihres Aufbaus nicht anders. > > Nunja, ich verstehe jetzt von kryptologischen Algorithmen nicht sonderlich viel, aber daß sie interne an diversen Stellen die Daten der "test vector"en kräftig durcheinander würfeln, sollte klar sein. Und jetzt aus "mit dem Wert m kommt das Erwartete heraus" und "mit dem Wert n kommt das Erwartete heraus" zu schließen, daß dann auch für alle Werte zwischen m und n das Erwartete heraus kommt, ist eben ziemlich gewagt. Das ist nicht gewagt, sofern man die Algorithmen implementiert kennt. Die Entwickler sprechen auch von einer eins-zu-eins-Korrespondenz, die die Algorithmen durchläuft. Ich habe diese Korrespondenz längst identifiziert. Ich - fast alle Anderen nicht. > Wenn wir uns darauf einigen könnten, daß es nicht möglich ist, durch Testen die Korrektheit eines Codes (d.h. Algorithmus UND Implementation) zu *beweisen*, dann könnten wir diese Debatte beenden. Da die Entwickler das behaupten und ich ihnen dabei folge und deren Aussagen in der Implementation erkannt habe, muß ich bei meinem Standpunkt bleiben. [... ...] > >>>> Ich habe u.a. die Bücher von Knuth. >>> >>> Ja, die sind gut. >>> Was sagt Knuth denn zum Testen? >> >> Ich arbeite jetzt nicht diese Bücher durch... > > Brauchst Du nicht, im "Fundamental Algorithms" Steht schon im ersten Kapitel "Basic Concepts" ein Beweis und der besteht nicht aus einzelnen Werten sondern ist ein mathematisch-logischer Beweis, daß der Algorithmus (Euklids Algorithmus zur Berechnung des größten gemeinsamen Teilers) korrekt ist. Bei meiner Softcover-Ausgabe von 1973 ab Seite 14. > >> Wozu auch?, wenn ich spezifische, zum Algorithmus passende Testprozeduren habe! > > Da ist noch was: hast Du schon mal darüber nachgedacht, daß die Entwickler *selber* diese Test-Vektoren bestimmt haben? Und ist Dir vielleicht mal der Gedanke gekommen, daß man als Entwickler einem gewissen "Bias" unterworfen ist, da.h. man tendiert dazu, in eine Richtung zu denken? |The correctness of the code on different platforms is verified by generating and comparing test vectors. Da steht das Wort 'generating'. Die generieren die Test-Vektoren mittels in deren Kreisen bekannter Software. Diese Leute sind halt in jeder Hinsicht professionell! Das habe ich schon vor langer Zeit erkannt. Deshalb vertraue ich deren Arbeiten auch. >>> http://www.informit.com/articles/article.aspx?p=1193856 >>> "As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t." >>> OK, es geht um "Unit Tests", aber auch das sind Tests und er lehnt sie ab! >>> >>>> Ein mathematischer Beweis ist bei allen Algorithmen des Kontextes prinzipiell unmöglich. >>>> Fehler werden gegebenenfalls lange Zeit nach Veröffentlichung des Algo von untersuchenden Experten mitgeteilt. >>>> >>>> Die _Entwickler_ wissen, daß wenn alle Tests Übereinstimmung ergeben, auch alle weiteren >>>> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden. (s.o.) >>> >>> Das wage ich zu bezweifeln. Schau'n 'mer mal, ob unser Ältester mir die Adresse von Mette besorgen kann, dann frage ich sie. >> >> Es kann sein, daß sie als eine von vier Entwicklern nicht alle Fragen beantworten kann. > > Schau'n 'mer mal. Ich hoffe ja, daß sie meine Frage weiterleiten wird, wenn sie sie schon nicht selber beantworten kann. > >>>>>> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des Irrsinns. >>>>> >>>>> Nein, wir befinden uns hier im Bereich der Hybris. >>>> >>>> Falsch. >>>> Ich bin ganz konkret praxisbezogen ziemlich kenntnisreich auf diesem Gebiet. >>> >>> Wie gesagt: Hybris. >> >> Nein, ich bin ziemlich kenntnisreich auf diesem Gebiet. >> Das bedeutet, daß ich deutlich mehr weiß, als die große Mehrheit. >> Ein Experte bin ich nicht für diese Algorithmen - allerdings für die Sprache C. > > Irrelevant und überheblich ... eben Hybris. Und die ist insbesondere im Bereicht der Sicherheit lebensgefährlich. Ich habe 15 Jahre lang erfolgreich Software auch für Hochsicherheitsbereiche entwickelt. Auf Anhieb korrekt. Hast Du einen Tick hinsichtlich 'Hybris'? Niemand, der etwas kann, darf sagen, daß er dies kann, sonst ist er an Hybris erkrankt? > [...] > >>> Nein, in erster Instanz werden Brücken *berechnet*. Die Statiker *berechnen*, wie viel Beton und wie viel Armierung und sonstiges da 'rein muß, damit eine Brücke mit einer bestimmten Spannweite eine bestimmte Last aufnehmen kann. Am Ende wird, um das noch einmal zu *verifizieren* ein Belastungstest gemacht. Aber wenn das nicht *berechnet* ist, dann würde kein LKW-Fahrer darüber fahren wollen. >> >> Diese Berechnungen werden aber begutachtet und eventuell offiziell abgenommen. >> Das ist in "bewiesenermaßen korrekt gebaut" enthalten. >> Du willst wieder Haare spalten. > > Nein, Du willst mir partout widersprechen. Genau das habe ich geschrieben: Brücken werden nicht einfach so gebaut und dann mit LKW getestet, sie werden berechnet, daß sie der Belastung stand halten, dann werden sie gebaut und dann fährt man noch mal mit einer Kolonne LKW 'drüber um das zu ... *verifizieren*. > Leider ist "mein Statiker" (Schwiegerpapa) schon vor über 30 Jahren verstorben, sonst hätte ich ihn gefragt, wie so etwas genau abläuft. Architekten haben im Beruf viel mit Statik-Berechnungen zu tun. Die wissen z.B., daß in irgendeiner Wohnung keine Steinplatten anstelle von Teppichboden gelegt werden dürfen. Garantien gibt es da nicht, deshalb muß es Abschlußtests und zyklische Prüfungen geben. Kräne werden z.B. mit der doppelten nominellen Belastung lang genug geprüft. Autoreifen halten meist etwa 30 bar aus, bis sie platzen. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
[toc] | [prev] | [next] | [standalone]
| From | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2022-03-30 14:32 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jaj0utF2hnbU1@mid.individual.net> |
| In reply to | #319349 |
On 30.03.22 13:36, Helmut Schellong wrote: > On 03/30/2022 09:34, Josef Moellers wrote: >> >> On 30.03.22 02:02, Helmut Schellong wrote: >>> On 03/29/2022 20:04, Josef Moellers wrote: >>>> >>>> On 29.03.22 15:14, Helmut Schellong wrote: >>>>> On 03/29/2022 09:39, Josef Moellers wrote: >>>>>> >>>>>> On 28.03.22 22:29, Helmut Schellong wrote: >>>>>>> On 03/28/2022 20:23, Thomas Prufer wrote: >>>>>>>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong >>>>>>>> <rip@schellong.biz> wrote: >>>>>>>> >>>>>>>>> Es ist _ganz generell_ richtig, was Du schreibst. >>>>>>>>> Du ignorierst jedoch die konkrete Praxis mit genau den >>>>>>>>> Algorithmen, um die es hier geht. >>>>>>>>> >>>>>>>>> Diese hatte ich aufgelistet: >>>>>>>>> |Die Kern-Algorithmen sind nicht selbst entwickelt. >>>>>>>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, >>>>>>>>> sha2_512, >>>>>>>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish >>>>>>>>> implementiert. >>>>>>>>> |Diese Algorithmen sind alle kryptographisch. >>>>>>>>> >>>>>>>>> In der Implementierungsvorschrift der jeweiligen Entwickler der >>>>>>>>> Algorithmen >>>>>>>>> ist auch meist eine Testprozedur durch die Entwickler angegeben. >>>>>>>>> Diese habe ich jeweils durchgeführt! >>>>>>>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist! >>>>>>>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert. >>>>>>>>> Korrekter und beweiskräftiger geht es nicht! >>>>>>>> >>>>>>>> Das wurde ignoriert weil es kein Beweis ist... >>>>>>> >>>>>>> Beweis für was? >>>>>> >>>>>> "das Korrektheit beweist!" >>>>>> >>>>>> Es ist allgemein bekannt, daß man mit einem Test NIEMALS die >>>>>> KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich >>>>>> wenn der Test fehl schlägt. >>>>>> Du kannst so lange Testen, wie Du willst, Du kannst 100% >>>>>> Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen >>>>>> können, daß der Test nicht bei der nächsten Iteration fehl schlägt. >>>>>> Der *Beweis* der Korrektheit eines Algorithmus oder seiner >>>>>> Implementation (im Folgenden "der Code") ist eine nicht-triviale, >>>>>> in der Regel mathematische Tätigkeit. >>>>> >>>>> Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können. >>>>> Das gilt jedoch nicht für kryptographische Algorithmen, die hier >>>>> aufgelistet sind. >>>> >>>> Nein. Es gibt keinen Test, der die Korrektheit eines Codes (d.h. >>>> Algorithmus UND Implementation) *beweisen* kann! >>>> Das ist allgemein bekannt und ich möchte mal behaupten, dessen sind >>>> sich die Entwickler des Codes auch bewußt. >>> >>> Nein, diese Entwickler sagen das Gegenteil. >>> Habe ich gepostet - wurde beharrlich ignoriert. >>> >>> |This is a set of test vectors for conformance testing, >>> |The correctness of the code on different platforms is verified by >>> generating and comparing test vectors. >> >> Seufz ... Den Unterschied zwischen "verified" und "proven" ist Dir >> bekannt? > > Du und mindestens ein Anderer verstehen die Semantik der Sprache nicht > richtig. > > 'verified' kann mit 'nachgewiesen' übersetzt werden. > Der Satzgegenstand ist die 'correctness of the code'. > Diese wird nachgewiesen durch Vergleich mit Test-Vektoren. > Wie oft muß ich das noch schreiben. > Ja, von mir aus, wenn's Dich glücklich macht. Plonk.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2022-03-30 15:01 +0200 |
| Subject | Re: NIHS |
| Message-ID | <52l84hhnvo3toqm54mss06ir5kfr7o9sf1@4ax.com> |
| In reply to | #319339 |
On Wed, 30 Mar 2022 09:34:31 +0200, Josef Moellers <josef.moellers@invalid.invalid> wrote: >Ganz einfach gesagt: es ist mir völlig wurscht, was die Entwickler >*behaupten*, wenn sie es denn überhaupt tun. Fakt ist, daß es in der >Informatik gar nicht mehr diskutiert wird, ob man mit Testen die >Korrektheit *beweisen* kann, es ist Konsens, daß dem NICHT so ist. ... so wie ich (und viele andere) nicht das beweisen anfangen, wenn wer ein funktionierendes perpetuum mobile behauptet. Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2022-03-30 16:11 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jaj6pcF3kk6U1@mid.individual.net> |
| In reply to | #319355 |
Am 30.03.22 um 15:01 schrieb Thomas Prufer: >> Ganz einfach gesagt: es ist mir völlig wurscht, was die Entwickler >> *behaupten*, wenn sie es denn überhaupt tun. Fakt ist, daß es in der >> Informatik gar nicht mehr diskutiert wird, ob man mit Testen die >> Korrektheit *beweisen* kann, es ist Konsens, daß dem NICHT so ist. Das ist elementare Erkenntnistheorie. Du kannst ja auch die These "alle Schwäne sind weiß" nicht durch Testen (Beobachtung beliebig vieler weißer Schwäne) beweisen - sie ist immer noch falsch, sobald der erste schwarze Schwan um die Ecke kommt. > ... so wie ich (und viele andere) nicht das beweisen anfangen, wenn wer ein > funktionierendes perpetuum mobile behauptet. Das obendrein... Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2022-03-30 18:10 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jajdniF50jkU1@mid.individual.net> |
| In reply to | #319339 |
Am 30.03.2022 um 09:34 schrieb Josef Moellers: >>>> |We, the designers of Rabbit, hereby state that no hidden weaknesses have >>>> |been inserted by us in the Rabbit algorithm. >>> >>> Das beruhigt ungemein. >> >> Du versuchst, die Entwickler lächerlich zu machen. > > Sorry, aber der Satz fordert das ja geradezu heraus. Nun ja, nachdem ja herauskam daß RSA absichtlich Schwächen eingebaut hat um eine Hintertür zu haben, wollte man wohl sagen, daß so etwas nicht absichtlich eingebaut wurde. Versteckte, ungewollte Schwächen kann es dennoch geben. > Wie gesagt: ich gehe davon aus, daß die Entwickler die Korrektheit ihres > Algorithmus' mathematisch bewiesen haben und lediglich die Korrektheit der > Implementation mittels Tests *verifizieren*. Das Problem bei Kryptographie ist in der Regel halt eine Seitenkanalattacke, die die mathematisch korrekte Arbeitsweise durch Nebeneffekte schwächt. Dazu gehören Ablaufzeiten, Stromverbrauchsmessungen, Anzahl und Art von Speicherzugriffen und dadurch bedingte EM-Abstrahlungen etc. Spezielle Kryptoprozessoren sind seit langem erfunden und werden benutzt, sie verstecken einiges davon durch stets gleichbleibenden Stromverbrauch, stets gleichbleibend isochrone Speicherzugriffe etc. Unsere Sicherheitssoftware läuft in einem HSM mit Kryptoprozessor. Aber wir entwickeln die grundlegenden Kryptographiefunktionen nicht selber, da gibt es fertige Module für Elliptic Curves, RSA, AES, DES etc. Was von uns kommt sind die konkreten Nutzungen der Basisfunktionen und der ganze Glue-Layer drumherum, wie Padding. Zum Beispiel Umschlüsseln einer PIN wird mit 2 Anwendungsfunktionen gemacht: 1. Entschlüsseln des verschlüsselten PIN-Blockes und Neuverschlüsselung in ein verschlüsseltes Zwischenergebnis, dieses bekommt die Anwendung. Das Zwischenergebnis ist mit einem temporären Schlüssel verschlüsselt der nur in dem konkreten HSM für begrenzte Zeit zur Verfügung steht. 2. Verschlüsseln eines verschlüsselten Zwischenergebnisses zu einem neuen PIN-Block, die Anwendung bekommt als Ergebnis den neu verschlüsselten und ggf. umgeformten PIN-Block. Für diese beiden Funktionen alleine gibt es mehr als tausend Tests. Das erstellte Softwaremodul muß für jede Version sicherheitsbegutachtet und zertifiziert werden, man ist also bemüht fehlerarme Versionen zu erstellen, sonst wird es teuer (OK, das ist das geringere Problem) und es dauert jedesmal einige Zeit bis die Begutachtung durch ist (das kann größere Probleme machen). Bernd
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-03-30 18:21 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2202o$5qa$1@news.bawue.net> |
| In reply to | #319358 |
On 3/30/22 18:10, Bernd Laengerich wrote: > > Das Problem bei Kryptographie ist in der Regel halt eine > Seitenkanalattacke, die die mathematisch korrekte Arbeitsweise durch > Nebeneffekte schwächt. Dazu gehören Ablaufzeiten, > Stromverbrauchsmessungen, Anzahl und Art von Speicherzugriffen und > dadurch bedingte EM-Abstrahlungen etc. Spezielle Kryptoprozessoren sind > seit langem erfunden und werden benutzt, sie verstecken einiges davon > durch stets gleichbleibenden Stromverbrauch, stets gleichbleibend > isochrone Speicherzugriffe etc. Bisher hat sich leider oft gezeigt, daß obige Behauptungen nur bedeuten, daß man noch nicht genau genug gemessen hat. Mit Glitching hat man auch schon einigen als sicher verkauften Chips Daten entlocken können. Gerrit
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | de.sci.electronics
csiph-web