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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-01 18:10 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2784n$8kuc$1@solani.org> |
| In reply to | #319399 |
On 04/01/2022 13:36, Enrik Berkhan wrote: > Helmut Schellong <rip@schellong.biz> wrote: >> Grotesk ist die Behauptung, daß kryptographische Algorithmen nicht selbst >> implementiert werden sollen, weil dann Seitenkanäle negativ wirksam werden können. >> Ein falsch implementierter Algorithmus bedarf keines Seitenkanalwirkens, um schädlich >> zu wirken, sondern er generiert direkt defekte Ausgabedaten. >> Einfach absurd! > > Grotesk und absurd ist vor allem dein fundiertes Missverständnis der > Begriffe. > Platte Behauptung ohne Begründung (wie fast immer). https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be ============================================================== Why is it wrong to *implement* myself a known, published, widely believed to be secure crypto algorithm? I know the general advice that we should never design¹ a cryptographic algorithm. It has been talked about very extensively on this site and on the websites of professionals of such caliber as Bruce Schneier. However, the general advice goes further than that: It says that we should not even implement algorithms designed by wiser than us, but rather, stick to well known, well tested implementations made by professionals. The reason why you want to avoid implementing cryptographic algorithms yourself is because of side-channel attacks: Eine Seitenkanalattacke (englisch side-channel attack; korrekter übersetzt, aber unüblich: Nebenkanal-Angriff), auch Seitenkanalangriff, bezeichnet eine kryptoanalytische Methode, die die physische Implementierung eines Kryptosystems in einem Gerät (Chipkarte, Security-Token, Hardware-Sicherheitsmodul etc.) oder in einer Software ausnutzt. Dabei wird nicht das kryptographische Verfahren selbst, sondern nur eine bestimmte Implementierung angegriffen, d. h. andere Implementierungen des Verfahrens sind von dem Angriff nicht betroffen. Das Prinzip beruht darauf, ein kryptographisches Gerät bei der Ausführung der kryptologischen Algorithmen zu beobachten und Korrelationen zwischen den beobachteten Daten und dem verwendeten Schlüssel zu finden. Diese charakteristische Information kann durch die Analyse der Laufzeit des Algorithmus, des Energieverbrauchs des Prozessors während der Berechnungen oder der elektromagnetischen Ausstrahlung gewonnen werden. Aktive, invasive Angriffe bestehen darin, in das Gerät einzugreifen und Fehler bei der Ausführung des kryptologischen Algorithmus einzubringen. Um dies zu verhindern, ist eine Seitenkanalanalyse daher Bestandteil der Schwachstellenanalyse in der Common-Criteria-Zertifizierung von Chipkarten und ähnlichen Geräten. How does this relate to my Crypto code? Cryptographic code looks very different from "regular" code. When looking at the above example, it doesn't seem wrong in any significant way. ... ============================================================== Die dargestellten Textteile reichen bereits aus, um den Artikel beiseite legen zu können. Der Inhalt ist schlicht irrelevant. o Meine Verwendung auf privaten lokalen Festplatten oder im privaten Webspace ist nicht betroffen. o Meine Implementationen wurden mittels Testprozeduren der Entwickler geprüft. o Bei den von mir verwendeten Implementationen von kryptographischen Algorithmen sind Korrelationen . zwischen Daten und Schlüssel garantiert nicht feststellbar. o "Cryptographic code looks very different from 'regular' code." . Die vorstehende Aussage ist absurd. Mein Verstehen ist vollständig. Das derjenigen, die behaupten, ich würde nicht verstehen, ist offenbar sehr bruchstückhaft. -- 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-04-05 17:03 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hlo4$f09s$2@solani.org> |
| In reply to | #319412 |
On 04/01/2022 18:10, Helmut Schellong wrote: > On 04/01/2022 13:36, Enrik Berkhan wrote: >> Helmut Schellong <rip@schellong.biz> wrote: >>> Grotesk ist die Behauptung, daß kryptographische Algorithmen nicht selbst >>> implementiert werden sollen, weil dann Seitenkanäle negativ wirksam werden können. >>> Ein falsch implementierter Algorithmus bedarf keines Seitenkanalwirkens, um schädlich >>> zu wirken, sondern er generiert direkt defekte Ausgabedaten. >>> Einfach absurd! >> >> Grotesk und absurd ist vor allem dein fundiertes Missverständnis der >> Begriffe. >> > > Platte Behauptung ohne Begründung (wie fast immer). > > https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be > ============================================================== > Why is it wrong to *implement* myself a known, published, widely believed to be secure crypto algorithm? > > I know the general advice that we should never design¹ a cryptographic algorithm. > It has been talked about very extensively on this site and on the websites of professionals > of such caliber as Bruce Schneier. > > However, the general advice goes further than that: It says that we should not even implement > algorithms designed by wiser than us, but rather, stick to well known, well tested implementations > made by professionals. > > The reason why you want to avoid implementing cryptographic algorithms yourself > is because of side-channel attacks: > > Eine Seitenkanalattacke (englisch side-channel attack; korrekter übersetzt, aber unüblich: > Nebenkanal-Angriff), auch Seitenkanalangriff, bezeichnet eine kryptoanalytische Methode, die > die physische Implementierung eines Kryptosystems in einem Gerät (Chipkarte, Security-Token, > Hardware-Sicherheitsmodul etc.) oder in einer Software ausnutzt. > Dabei wird nicht das kryptographische Verfahren selbst, sondern nur eine bestimmte Implementierung > angegriffen, d. h. andere Implementierungen des Verfahrens sind von dem Angriff nicht betroffen. > > Das Prinzip beruht darauf, ein kryptographisches Gerät bei der Ausführung der kryptologischen Algorithmen > zu beobachten und Korrelationen zwischen den beobachteten Daten und dem verwendeten Schlüssel zu finden. > Diese charakteristische Information kann durch die Analyse der Laufzeit des Algorithmus, des Energieverbrauchs > des Prozessors während der Berechnungen oder der elektromagnetischen Ausstrahlung gewonnen werden. > Aktive, invasive Angriffe bestehen darin, in das Gerät einzugreifen und Fehler bei der Ausführung > des kryptologischen Algorithmus einzubringen. > Um dies zu verhindern, ist eine Seitenkanalanalyse daher Bestandteil der > Schwachstellenanalyse in der Common-Criteria-Zertifizierung von Chipkarten und ähnlichen Geräten. > > How does this relate to my Crypto code? > Cryptographic code looks very different from "regular" code. > When looking at the above example, it doesn't seem wrong in any significant way. > ... > ============================================================== > > Die dargestellten Textteile reichen bereits aus, um den Artikel beiseite legen zu können. > Der Inhalt ist schlicht irrelevant. > > o Meine Verwendung auf privaten lokalen Festplatten oder im privaten Webspace ist nicht betroffen. > o Meine Implementationen wurden mittels Testprozeduren der Entwickler geprüft. > o Bei den von mir verwendeten Implementationen von kryptographischen Algorithmen sind Korrelationen > . zwischen Daten und Schlüssel garantiert nicht feststellbar. > o "Cryptographic code looks very different from 'regular' code." > . Die vorstehende Aussage ist absurd. > > Mein Verstehen ist vollständig. > Das derjenigen, die behaupten, ich würde nicht verstehen, ist offenbar sehr bruchstückhaft. > > |5.2 Security |The design of Rabbit makes the most wide-spread attacks against stream |ciphers inapplicable. |Both algebraic attacks ([10] and subsequent work) and correlation attacks ([19] |and subsequent work) against stream ciphers are targeting designs with internal |linear structures, which are not prevalent in Rabbit. |Also the Time-Memory-Data tradeoffs ([5] and subsequent work) are not applicable |due to the large internal state of 513 bits. |Nonetheless, Rabbit has been evaluated against all known attack techniques |both from stream and block cipher cryptanalysis, and it has been |carefully optimized in order to avoid any weaknesses towards them. |We are thus optimistic that any attack against Rabbit would have to be based |on a completely new attack technique. Rabbit hat auch entsprechend seit Veröffentlichung 2003 keine Schwächen gezeigt. Erst recht gab es keine erfolgreiche Attacke. Deshalb wird Rabbit auch in Experten-Kreisen oft ausdrücklich empfohlen. Der Inhalt des Artikels unter dem obigen Link ist schlicht nicht anwendbar auf Rabbit! Der Artikel ist völlig allgemein und theoretisch. Ich habe begonnen, den /Dragon/-Algorithmus zu implementieren. Der benutzt ein 1024 Bit breites nichtlinear rückgekoppeltes Schieberegister (NLFSR). -- 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 | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-04-05 17:13 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hmb4$1acml$1@news1.tnib.de> |
| In reply to | #319557 |
Helmut Schellong <rip@schellong.biz> wrote: >Der benutzt ein 1024 Bit breites nichtlinear rückgekoppeltes Schieberegister (NLFSR). Und? Er kann dennoch wirklich schlecht sein. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-05 18:22 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hqb7$f3la$1@solani.org> |
| In reply to | #319559 |
On 04/05/2022 17:13, Marc Haber wrote: > Helmut Schellong <rip@schellong.biz> wrote: >> Der benutzt ein 1024 Bit breites nichtlinear rückgekoppeltes Schieberegister (NLFSR). > > Und? Er kann dennoch wirklich schlecht sein. > Prinzipiell ja - theoretisch. In der Praxis ist er jedoch tatsächlich nicht schlecht, sondern sehr gut. Dragon (2005) könnte ein klein wenig weniger gut als Rabbit (2003) sein. Ja, aber hinsichtlich welcher Eigenschaft?... -- 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-04-06 08:59 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jb4s2gFfrgbU1@mid.individual.net> |
| In reply to | #319557 |
Ich wollte eigentlich nicht mehr, aber ... On 05.04.22 17:03, Helmut Schellong wrote: > Rabbit hat auch entsprechend seit Veröffentlichung 2003 keine Schwächen > gezeigt. > Erst recht gab es keine erfolgreiche Attacke. > Deshalb wird Rabbit auch in Experten-Kreisen oft ausdrücklich empfohlen. Ich hab' mich mal in meinem Umkreis umgehört: 1) einer meiner Kollegen in der Security-Gruppe (also in einer anderen Gruppe als meiner, "System Boot and Init") schreibt "Ich hab gerade mal etwas nachgelesen und nicht sofort etwas schlechtes gefunden, aber ich wuesste nicht, warum man den nutzen sollte anstatt der ueblichen Verdaechtigen. Bei Crypto will man eigentlich keine Exoten." 2) mein "persönlicher" Security-Experte (Sohn, forscht an der Universität des Saarlandes) sagt sinngemäß das Selbe. Mein' ja nur, Josef
[toc] | [prev] | [next] | [standalone]
| From | Enrik Berkhan <Enrik.Berkhan@inka.de> |
|---|---|
| Date | 2022-04-06 09:58 +0000 |
| Subject | Re: NIHS |
| Message-ID | <t2jo7r$bcl4$1@starfleet.inka.de> |
| In reply to | #319574 |
Josef Moellers <josef.moellers@invalid.invalid> wrote: > Ich wollte eigentlich nicht mehr, aber ... :-) > On 05.04.22 17:03, Helmut Schellong wrote: >> Rabbit hat auch entsprechend seit Veröffentlichung 2003 keine Schwächen >> gezeigt. >> Erst recht gab es keine erfolgreiche Attacke. >> Deshalb wird Rabbit auch in Experten-Kreisen oft ausdrücklich empfohlen. > > Ich hab' mich mal in meinem Umkreis umgehört: > > 1) einer meiner Kollegen in der Security-Gruppe (also in einer anderen > Gruppe als meiner, "System Boot and Init") schreibt > "Ich hab gerade mal etwas nachgelesen und nicht sofort > etwas schlechtes gefunden, aber ich wuesste nicht, warum man den nutzen > sollte anstatt der ueblichen Verdaechtigen. Bei Crypto will man > eigentlich keine Exoten." > > 2) mein "persönlicher" Security-Experte (Sohn, forscht an der > Universität des Saarlandes) sagt sinngemäß das Selbe. Insbesondere kann das "hat seit 2003 keine Schwächen gezeigt" ja auch damit zu tun haben, dass der Algorithmus im Vergleich zu anderen wenig verwendet wird. Muss nicht so sein, ist aber möglich. Gruß, Enrik
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-06 13:45 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2jufp$gce9$1@solani.org> |
| In reply to | #319584 |
On 04/06/2022 11:58, Enrik Berkhan wrote: > Josef Moellers <josef.moellers@invalid.invalid> wrote: >> Ich wollte eigentlich nicht mehr, aber ... > > :-) > >> On 05.04.22 17:03, Helmut Schellong wrote: >>> Rabbit hat auch entsprechend seit Veröffentlichung 2003 keine Schwächen >>> gezeigt. >>> Erst recht gab es keine erfolgreiche Attacke. >>> Deshalb wird Rabbit auch in Experten-Kreisen oft ausdrücklich empfohlen. >> >> Ich hab' mich mal in meinem Umkreis umgehört: >> >> 1) einer meiner Kollegen in der Security-Gruppe (also in einer anderen >> Gruppe als meiner, "System Boot and Init") schreibt >> "Ich hab gerade mal etwas nachgelesen und nicht sofort >> etwas schlechtes gefunden, aber ich wuesste nicht, warum man den nutzen >> sollte anstatt der ueblichen Verdaechtigen. Bei Crypto will man >> eigentlich keine Exoten." >> >> 2) mein "persönlicher" Security-Experte (Sohn, forscht an der >> Universität des Saarlandes) sagt sinngemäß das Selbe. > > Insbesondere kann das "hat seit 2003 keine Schwächen gezeigt" ja auch > damit zu tun haben, dass der Algorithmus im Vergleich zu anderen wenig > verwendet wird. Muss nicht so sein, ist aber möglich. > > https://en.wikipedia.org/wiki/Rabbit_(cipher)#Security A small bias in the output of Rabbit exists,[7] resulting in a distinguisher with 2^247 complexity discovered by Jean-Philippe Aumasson in December 2006. Even though this distinguisher was improved to 2^158 in 2008,[8] it's not a threat to Rabbit's security because its complexity is significantly higher than the brute-force of the key space (2^128). Allerdings bei Dragon wurde eine Methode gefunden, die eher zum Ziel führt als brute-force. Dennoch kann Dragon noch als sicher bezeichnet werden - ist aber nicht so gut wie Rabbit. Es wurde auch der maximale KeyStream (2^64 bit) bei der Angriffsanalyse weit überschritten! Quasi entspricht das den MaximumRatings in einem Datenblatt, die stark überschritten wurden. Ergebnisschwächen unter _solchen_ Bedingungen sind wohl ungültig. Bei AES sind unter dem Thema 'Sicherheit' viiiel mehr Texte zu finden (< brute-force). -- 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 | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-04-06 22:38 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2ktov$1ftn1$1@news1.tnib.de> |
| In reply to | #319587 |
Helmut Schellong <rip@schellong.biz> wrote: >Bei AES sind unter dem Thema 'Sicherheit' viiiel mehr Texte zu finden Das liegt daran dass AES in etwa eine Million mal verbreiteter ist. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-06 23:31 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2l0rd$h35e$1@solani.org> |
| In reply to | #319619 |
On 04/06/2022 22:38, Marc Haber wrote: > Helmut Schellong <rip@schellong.biz> wrote: >> Bei AES sind unter dem Thema 'Sicherheit' viiiel mehr Texte zu finden > > Das liegt daran dass AES in etwa eine Million mal verbreiteter ist. > ============================================================================================ Rijndael überzeugte im AES-Wettbewerb durch seine mathematisch elegante und einfache Struktur sowie durch seine Effizienz. Allerdings sahen manche Kryptographen gerade darin ein Problem: Die S-Boxen lassen sich algebraisch einfach beschreiben, und sie sind die einzige nichtlineare Komponente der Chiffre. Dadurch lässt sich der gesamte Algorithmus als Gleichungssystem beschreiben. Durch die einfache Schlüsseleinteilung würden mit einem beliebigen Rundenschlüssel auch 128 Bit des Verfahrensschlüssels kompromittiert. Ein weiterer Kritikpunkt war die relativ geringe Sicherheitsmarge, die nach damaligem Stand der Analyse nur drei (bei 128 Bit Schlüssellänge) bis fünf Runden (bei 256 Bit Schlüssellänge) betrug. ============================================================================================ Diese Kritik gehört in die Kategorie 'Beurteilung und Analyse', hat also nichts oder kaum etwas mit Verbreitung zu tun. Vergleichbare Kritikpunkte gibt es bei Rabbit jedoch gar nicht. Dessen Analyse sieht gut aus. Ich habe mich für Rabbit als meinen Hauptalgorithmus entschieden, weil der in einem offiziellen Wettbewerb unter 34 Algorithmen Platz 1 belegte und zu den 4 empfohlenen gehört. Wie http://www.schellong.de/htm/rabbit_kern.c.html zeigt, ist Rabbit angenehm zu implementieren. Und Rabbit ist sehr schnell und kompakt. -- 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-04-06 13:18 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2jsua$gbeq$1@solani.org> |
| In reply to | #319574 |
On 04/06/2022 08:59, Josef Moellers wrote: > Ich wollte eigentlich nicht mehr, aber ... > > On 05.04.22 17:03, Helmut Schellong wrote: > >> Rabbit hat auch entsprechend seit Veröffentlichung 2003 keine Schwächen gezeigt. >> Erst recht gab es keine erfolgreiche Attacke. >> Deshalb wird Rabbit auch in Experten-Kreisen oft ausdrücklich empfohlen. > > Ich hab' mich mal in meinem Umkreis umgehört: > > 1) einer meiner Kollegen in der Security-Gruppe (also in einer anderen Gruppe als meiner, "System Boot and Init") schreibt > "Ich hab gerade mal etwas nachgelesen und nicht sofort > etwas schlechtes gefunden, aber ich wuesste nicht, warum man den nutzen > sollte anstatt der ueblichen Verdaechtigen. Bei Crypto will man eigentlich keine Exoten." > > 2) mein "persönlicher" Security-Experte (Sohn, forscht an der Universität des Saarlandes) sagt sinngemäß das Selbe. > > Mein' ja nur, > Der nachfolgende Text hört sich ganz anders an. Ein Exot ist Rabbit gewiß nicht. Und Platz 1 (mit Salsa20) unter 34 Kandidaten ist eine absolute Empfehlung. ================================================================================================================= Rabbit ist eine 2003 von Martin Boesgaard, Mette Vesterager, Thomas Pedersen, Jesper Christiansen und Ove Scavenius (Cryptico A/S, Dänemark) entwickelte Stromchiffre mit einer Schlüssellänge von 128 bit (entsprechend 16 Zeichen). Rabbit (zu deutsch Hase) wurde entwickelt, um schneller zu sein, als damals existierende Verfahren. Dies soll sich wohl auch im Namen ausdrücken. Rabbit war Kandidat beim eStream Projekt des ECRYPT-Netzwerkes, einem Kryptowettbewerb, der von 2004 bis 2008 lief und das Ziel verfolgte, Vorschläge für neue Stromchiffren entgegenzunehmen, kryptologisch zu untersuchen und zu bewerten und so empfehlenswerte Verfahren zu finden. Das eStream Projekt lief über drei Phasen: Phase 1, die bis März 2006 lief, war eine allgemeine Beurteilung und Analyse der eingereichten 34 Kandidaten. Hier wurden offensichtliche Schwächen erkannt. Phase 2, im August 2006 gestartet, untersuchte die Kandidaten, die weitergekommen waren insbesondere auch auf Design und Performance und beinhaltete weitere Kryptoanalysen. Phase 3 schließlich, im April 2007 gestartet und im April 2008 beendet, verglich die übrigen 14 Kandidaten miteinander und kürte die besten als empfehlenswert: vier in der Kategorie Software-Implementierung und drei in der Kategorie Hardware-Implementierung. Rabbit schaffte es bis in Phase 3 des Wettbewerbs und wurde auch als einer der sieben empfehlenswerten Algorithmen eingestuft. Neben Salsa20 belegte Rabbit den ersten Platz bei den Software-Verfahren. Rabbit ist für die Implementierung in Software optimiert. Rabbit ist für kommerziellen und nicht-kommerziellen Gebrauch freigegeben. Es sind bisher keine Schwächen in Rabbit bekannt geworden, die einen Angriff ermöglichen, der effizienter als ein Brute-Force-Attack wäre. Ein 128-Bit-Schlüssel macht es robust gegen Brute-Force-Angriffe. Es ist auch ziemlich einfach zu implementieren und erfordert eine minimale Speicherung von Zuständen. Im Vergleich zum Advanced Encryption Standard für Geräte mit geringer Leistung ergeben sich in der Schnelligkeit und der Robustheit Vorteile für den Rabbit-Algorithmus. Bislang wurden keine Schwachstellen in der Rabbit-Verschlüsselung gefunden. Der Rabbit-Algorithmus findet unter anderem in der quelloffenen SSL/TLS-Programmbibliothek WolfSSL Anwendung, ================================================================================================================= -- 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-04-15 03:28 +0200 |
| Subject | Spezifische beweiskräftige Stichproben (was: NIHS) |
| Message-ID | <t3ahno$tn9e$1@solani.org> |
| In reply to | #319396 |
On 04/01/2022 12:54, Helmut Schellong wrote: > On 04/01/2022 11:48, Volker Bartheld wrote: >> On Fri, 1 Apr 2022 11:18:41 +0200, Hanno Foest wrote: >>> On 01.04.22 11:03, Volker Bartheld wrote: >>>> Oder ob in der Hardware eine Backdoor eingebaut wurde. >>> [URLs] >>> Da fehlt noch der Klassiker: >>> https://sharps.org/wp-content/uploads/BECKER-CHES.pdf >> >> Richtig. Danke! Den hatte ich vergessen. Eine echte Perle. Sind natürlich >> in der Gesamtschau alles recht ausgefuchste Sachen, derer sich Experten >> annehmen müssen und meilenweit von der Aussage entfernt, man könnte anhand >> einer Stichprobe die "korrekte" Implementierung eines Algorithmus (was auch >> immer unter korrekt zu verstehen ist, das Stichwort "Seitenkanalattacke" >> wurde ja bereits gegeben und nicht verstanden) beweisen. > > Ein Algorithmus ist korrekt implementiert, wenn für jede mögliche Eingabe > dessen Ausgabe übereinstimmend mit der Referenz-Implementation ist. > Vorstehend die allgemeine Antwort. > > Bei ganz bestimmten Algorithmen können aufgrund von deren spezifischen Eigenschaften > Stichproben beweiskräftig die Korrektheit einer Implementation bestätigen. > Die jeweiligen Entwickler können eine geeignete Testprozedur festlegen. > Die allgemeinen Regeln sind dann im betreffenden Kontext nicht anwendbar. > > Die Angelegenheit mit den beweiskräftigen Stichproben ist nun genügend geklärt. Am Beispiel des dragon-Algorithmus. Der Key hat 256 Bits, kann also 2^256 = 2^(2^8) verschiedene Werte annehmen. Zu jedem dieser Werte gehört ein bestimmter jeweils komplett unterschiedlicher Keystream. Der Keystream hat eine maximale Länge von 2^64 Bit, kann also <2^(2^64) verschiedene Werte annehmen. Die Testausgabe umfaßt 1024 Bit (Stichprobe). Das ist also der kurze Beginn eines Keystreams. Diffusor: |All the keystream words and feedback words are dependent on all input words, |both at the bit level and word level. A single bit change in any of the six input |words results in completely different keystream and feedback words. Zu beachten ist hier das Wort 'completely'. Es liegt ein deterministischer Keystream von Bit 0 bis Bit 2^64-1 vor. Die Testausgabe hat 1024 Bit (Stichprobe). Wenn diese übereinstimmt, muß auch der Rest übereinstimmen, weil der Algorithmus es nicht hergibt, daß die ersten 1024 Bit übereinstimmen, jedoch danach fehlende Übereinstimmungen vorkommen können. Jedenfalls nicht bei mehreren Stichproben. Das ist dem Algorithmus inhärent. Es geht um den Beweis einer korrekten Implementation! Beispiel: Zuweisung von 'b' und 'c' nach dem Schieben statt vor dem Schieben hat nur die ersten 4x64 Bit von 1024 gleich belassen (256). Die restlichen 12x64 Bit der Ausgabe waren bereits völlig anders! Es wurden etwa 40 subtile Änderungen (Fehler) am Algorithmus vorgenommen. Key und Iv blieben dabei konstant. Fast alle Änderungen hatten einen vollkommen anderen Keystream zur Folge. Eine Änderung am Algorithmus wirkt (etwa) so, als wäre ein anderer Key eingesetzt. Je näher eine Änderung der Erzeugung des Endresultates kam [1], desto länger wurde der beginnende Teil der Stichprobe, der gegenüber dem Zustand vor der Änderung gleich blieb. Maximal blieben genau 256 Bits zu Beginn der Stichprobe gleich, die restlichen 1024-256 waren dann bereits komplett unterschiedlich. Manchmal blieben nur 64 Bits vorne gleich, 1024-64 komplett unterschiedliche folgten. Meistens blieben nicht mal 8 Bits vorne gleich. Der Diffusor des Algorithmus läßt es nicht zu, daß /Brüche/ innerhalb eines Keystreams vorkommen. Bei echtem Zufall ist das vorstellbar, aber nicht bei einer deterministischen Pseudo-Zufallsfolge. Beweiskräftige Stichproben liegen hiermit nur für den dragon-Algorithmus vor. Es wird jedoch so sein, daß dies auf alle kryptographischen Stromverschlüsselungen und Hash-Algorithmen ausgedehnt werden kann. Wenn von mehreren Referenz-Dateien Hash-Werte gezogen werden und alle diese Werte übereinstimmend mit den Referenz-Werten sind, ist die Korrektheit der Implementation bewiesen. Eine fehlerhafte Implementation kann nicht solche Übereinstimmungen in Gesamtheit generieren. [1] Position im Implementations-Code. -- 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 | Rupert Haselbeck <mein-rest-muell@gmx.de> |
|---|---|
| Date | 2022-04-15 11:26 +0200 |
| Subject | Re: Spezifische beweiskräftige Stichproben |
| Message-ID | <uaqnii-n9c.ln1@nntp.haselbeck-net.de> |
| In reply to | #320065 |
Helmut Schellong schrieb: > Es wurden etwa 40 subtile Änderungen (Fehler) am Algorithmus vorgenommen. > Key und Iv blieben dabei konstant. > Fast alle Änderungen hatten einen vollkommen anderen Keystream zur Folge. > Eine Änderung am Algorithmus wirkt (etwa) so, als wäre ein anderer Key > eingesetzt. > Je näher eine Änderung der Erzeugung des Endresultates kam [1], desto > länger > wurde der beginnende Teil der Stichprobe, der gegenüber dem Zustand vor > der Änderung gleich blieb. > Maximal blieben genau 256 Bits zu Beginn der Stichprobe gleich, die > restlichen > 1024-256 waren dann bereits komplett unterschiedlich. > Manchmal blieben nur 64 Bits vorne gleich, 1024-64 komplett > unterschiedliche folgten. > Meistens blieben nicht mal 8 Bits vorne gleich. Du hast also keinerlei Ahnung, wie die Verschlüsselung überhaupt funktioniert, auf welchen mathematischen Grundlagen sie beruht?! > Beweiskräftige Stichproben liegen hiermit nur für den dragon-Algorithmus > vor. > Es wird jedoch so sein, daß dies auf alle kryptographischen > Stromverschlüsselungen und Hash-Algorithmen ausgedehnt werden kann. Das müsste nicht unterstellt sondern bewiesen werden! > Wenn von mehreren Referenz-Dateien Hash-Werte gezogen werden und alle > diese Werte > übereinstimmend mit den Referenz-Werten sind, ist die Korrektheit der > Implementation bewiesen. Nein, natürlich ist sie das nicht > Eine fehlerhafte Implementation kann nicht solche Übereinstimmungen in > Gesamtheit generieren. Das ist - natürlich - falsch! MfG Rupert
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-15 15:26 +0200 |
| Subject | Re: Spezifische beweiskräftige Stichproben |
| Message-ID | <t3brqc$udhh$1@solani.org> |
| In reply to | #320074 |
On 04/15/2022 11:26, Rupert Haselbeck wrote: > Helmut Schellong schrieb: >> Es wurden etwa 40 subtile Änderungen (Fehler) am Algorithmus vorgenommen. >> Key und Iv blieben dabei konstant. >> Fast alle Änderungen hatten einen vollkommen anderen Keystream zur Folge. >> Eine Änderung am Algorithmus wirkt (etwa) so, als wäre ein anderer Key eingesetzt. >> Je näher eine Änderung der Erzeugung des Endresultates kam [1], desto länger >> wurde der beginnende Teil der Stichprobe, der gegenüber dem Zustand vor >> der Änderung gleich blieb. >> Maximal blieben genau 256 Bits zu Beginn der Stichprobe gleich, die restlichen >> 1024-256 waren dann bereits komplett unterschiedlich. >> Manchmal blieben nur 64 Bits vorne gleich, 1024-64 komplett unterschiedliche folgten. >> Meistens blieben nicht mal 8 Bits vorne gleich. > > Du hast also keinerlei Ahnung, wie die Verschlüsselung überhaupt funktioniert, auf welchen mathematischen Grundlagen sie beruht?! > >> Beweiskräftige Stichproben liegen hiermit nur für den dragon-Algorithmus vor. >> Es wird jedoch so sein, daß dies auf alle kryptographischen Stromverschlüsselungen und Hash-Algorithmen ausgedehnt werden kann. > > Das müsste nicht unterstellt sondern bewiesen werden! > >> Wenn von mehreren Referenz-Dateien Hash-Werte gezogen werden und alle diese Werte >> übereinstimmend mit den Referenz-Werten sind, ist die Korrektheit der Implementation bewiesen. > > Nein, natürlich ist sie das nicht > >> Eine fehlerhafte Implementation kann nicht solche Übereinstimmungen in Gesamtheit generieren. > > Das ist - natürlich - falsch! > > Du solltest am Besten mal die Dokumentationen zum Algorithmus lesen und verstehen, den Algorithmus implementieren und betreiben, und viele Untersuchungen anstellen, so wie ich das tat. Die Entwickler der Algorithmen schreiben selbst von einem 'Beweis'. (Entsprechende Texte hatte ich vor langer Zeit gepostet.) Du bist ein professioneller Pauschal-Lügner, so wie Leute im Kreml. -- 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 | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2022-04-15 22:03 +0200 |
| Subject | Re: Spezifische beweiskräftige Stichproben |
| Message-ID | <bejj5hpjufihv6bpnra6j6dfc94khb1pjt@4ax.com> |
| In reply to | #320080 |
On Fri, 15 Apr 2022 15:26:46 +0200, Helmut Schellong <rip@schellong.biz> wrote: >Du solltest am Besten mal die Dokumentationen zum Algorithmus lesen und verstehen, >den Algorithmus implementieren und betreiben, und viele Untersuchungen anstellen, >so wie ich das tat. > >Die Entwickler der Algorithmen schreiben selbst von einem 'Beweis'. >(Entsprechende Texte hatte ich vor langer Zeit gepostet.) Du verhältst dich so: einer, der jahrelange Untersuchungen zu seinem perpetuum mobile angestellt hat, an diesem gebastelt und optimiert hat, sagt zu einem Physiker, der dessen Funktionsfähigkeit sofort in Abrede stellt: bevor der Physiker die Funktion verneinen darf, muß er *dieses* perpetuum mobile erst verstehen, den Aufbau implementieren und betreiben, und viele Untersuchungen anstellen, bevor er sich ein Urteil bilden dürfe! Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-15 23:32 +0200 |
| Subject | Re: Spezifische beweiskräftige Stichproben |
| Message-ID | <t3co9l$utpn$1@solani.org> |
| In reply to | #320092 |
On 04/15/2022 22:03, Thomas Prufer wrote: > On Fri, 15 Apr 2022 15:26:46 +0200, Helmut Schellong <rip@schellong.biz> wrote: > >> Du solltest am Besten mal die Dokumentationen zum Algorithmus lesen und verstehen, >> den Algorithmus implementieren und betreiben, und viele Untersuchungen anstellen, >> so wie ich das tat. >> >> Die Entwickler der Algorithmen schreiben selbst von einem 'Beweis'. >> (Entsprechende Texte hatte ich vor langer Zeit gepostet.) > > Du verhältst dich so: einer, der jahrelange Untersuchungen zu seinem perpetuum > mobile angestellt hat, an diesem gebastelt und optimiert hat, sagt zu einem > Physiker, der dessen Funktionsfähigkeit sofort in Abrede stellt: bevor der > Physiker die Funktion verneinen darf, muß er *dieses* perpetuum mobile erst > verstehen, den Aufbau implementieren und betreiben, und viele Untersuchungen > anstellen, bevor er sich ein Urteil bilden dürfe! > > > Es ist anders herum: Ich bin hier der 'Physiker'. Und Du weißt auch, daß das so ist. -- 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 | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2022-04-01 13:58 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jao7maF2jcaU2@mid.individual.net> |
| In reply to | #319395 |
On 01.04.22 11:48, Volker Bartheld wrote: > Ich finde ja eigentlich diejenigen Sabotagemöglichkeiten (die > sicherheitsrelevante Kompromittierung eines Systems ist ja auch eine > Variante von Sabotage) am spannendsten, wo der Saboteur (gerne auch > Insider) einfach nur eine Zeile anscheinend vollkommen harmlosen Code > einfügen muß (Sleep z. B.), ein bisserl was an der Ausführungsreihenfolge > oder den Startparametern drehen oder die Specs grenzwertig auslegen muß. > > Also ohne nachweisbaren Vorsatz, jeder tat sein Möglichstes. AKA "Bugdoor". Heartbleed ist da Referenzklasse. 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 | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2022-04-01 19:24 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t27cfk$mum$1@dont-email.me> |
| In reply to | #319401 |
Hanno Foest schrieb: > > AKA "Bugdoor". Heartbleed ist da Referenzklasse. Der war aber open-source. Jeder konnte nachschauen und den Bug beheben, falls der ihm nicht gepasst hat. Jeder seriöse Hobbykryptologe wird als erstes den Kernel auf Asseblerebene kontrollieren, damit das nicht passiert. Davon sollten wir ausgehen. -- mfg Rolf Bombach, leicht gereizt, sorry.
[toc] | [prev] | [next] | [standalone]
| From | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| Date | 2022-04-01 08:44 +0200 |
| Subject | Re: NIHS |
| Message-ID | <janlauFtmh0U1@mid.individual.net> |
| In reply to | #319373 |
On 31.03.22 12:59, Marc Haber wrote: > Josef Moellers <josef.moellers@invalid.invalid> wrote: >> 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. > > Die theoretische Informatik wird Dir da seit 40 Jahren vehement > widersprechen. Seltsam ... tut sie nicht. > Die Problematik ist halt, dass die formale Verifikation eines > Programms auf Spezifikationsgerechtheit und korrekter Implementation > schreiend aufwendig ist und nur dann Sinn ergibt, wenn man das > Programm dann mit einem verifizierten Compiler übersetzt, mit > verifizierten Libraries linkt und auf einer mit verifizierter Firmware > versorgten verifizierten CPU ausführt. Es wird da eine zweistufige Vorgehensweise geben: 1) Die Korrektheit des Algorithmus' wird formal mathematisch-logisch bewiesen 2) Jede Implementation wird mittels aufwendiger Tests *verifiziert*. D.h. es besteht immer noch die Möglichkeit, daß ein *Implementation* nicht korrekt ist. Für einen sicherheitskritischen Algorithmus, wie es ein verschlüsselungsverfahren ist, erwarte ich Ersteres. > Und _DAS_ ist ein Beschaffungsproblem. Im Endeffekt ist alles eine Kostenfrage. Auch der formale Beweis der Korrektheit eines Algorithmus und dann auch noch der Implementation scheitert i.d.R. an den Kosten. Josef
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2022-03-30 14:57 +0200 |
| Subject | Re: NIHS |
| Message-ID | <vlk84h5qko8r4prfjifp6iulk6ekdo79ho@4ax.com> |
| In reply to | #319314 |
On Tue, 29 Mar 2022 15:14:21 +0200, Helmut Schellong <rip@schellong.biz> wrote: >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. Das ist falsch, denn der Algorithmus if Testverktor1 then return (Ergebnis-Testvektor1) else if Testverktor2 then return (Ergebnis-Testvektor2) else ... usw usf. else return(42) erfüllt die Tests, ist aber augenscheinlich falsch, denn es liefert 42 für alle nicht-Testvektoren. Obiges ist ein *Beweis*, merke ich hier an... Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-30 15:07 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t21km7$586a$1@solani.org> |
| In reply to | #319354 |
On 03/30/2022 14:57, Thomas Prufer wrote: > On Tue, 29 Mar 2022 15:14:21 +0200, Helmut Schellong <rip@schellong.biz> wrote: > >> 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. > > Das ist falsch, denn der Algorithmus > > if Testverktor1 then return (Ergebnis-Testvektor1) > else > if Testverktor2 then return (Ergebnis-Testvektor2) > else ... usw usf. > else return(42) > > erfüllt die Tests, ist aber augenscheinlich falsch, denn es liefert 42 für alle > nicht-Testvektoren. > > Obiges ist ein *Beweis*, merke ich hier an... > > > Ich sehe einen Syntax-Fehler... -- 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]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | de.sci.electronics
csiph-web