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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 19:04 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1ve63$3u4k$1@solani.org> |
| In reply to | #319323 |
On 03/29/2022 17:58, Hanno Foest wrote: > Am 29.03.22 um 17:33 schrieb Helmut Schellong: > >> Ich habe in der Industrie 15 Jahre lang sicherheitskritische Software entwickelt. >> Beispielsweise für ukrainische und russische Atomkraftwerke. > > Tschernobyl... Quatsch, das Unglück war 1986, ich war in der betreffenden Firma ab 2000. Die Software wurde ab etwa 2003 entwickelt, mit kyrillischen Displays. >> Man hat mir beste Arbeitszeugnisse ausgestellt. > > Insbesondere die Realität. Von 1968 bis 1979. Von 1984 bis 2016. >> |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. >> >> Auch Englisch kannst Du offenbar nicht richtig. >> 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. > > Das ist scheissegal was da steht, Nein, es ist gar nicht egal, was da steht. Jemand Anderer hat nämlich darüber gelogen oder war nicht in der Lage, richtig zu verstehen. du kannst zB. nicht zeigen, daß es bei deiner Implementierung keine Seitenkanäle gibt, da evtl. noch nicht mal bekannt ist, welche das in Zukunft sein könnten. > > Ich habe bereits gepostet, daß ich alle diese Algorithmen nur von und zu lokaler Festplatte benutze. Die dämlichen Seitenkanäle können folglich keinen Effekt haben. Die dämlichen Seitenkanäle können wohl auch grundlegend im Zusammenhang mit diesen Algorithmen keinen Effekt haben. Das ist eine ins Leere laufende Behauptung. -- 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-03-29 20:34 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jah1ppFlkjcU1@mid.individual.net> |
| In reply to | #319326 |
On 29.03.22 19:04, Helmut Schellong wrote: >> Das ist scheissegal was da steht, > > Nein, es ist gar nicht egal, was da steht. Doch, da du eh nicht fähig bist, es richtig zu verstehen. > du kannst zB. nicht zeigen, daß es bei deiner Implementierung keine > Seitenkanäle gibt, > da evtl. noch nicht mal bekannt ist, welche das in Zukunft sein könnten. >> > Ich habe bereits gepostet, daß ich alle diese Algorithmen > nur von und zu lokaler Festplatte benutze. Ok, wenn praktisch niemand irgendwo deinen binären Sondermüll benutzt, ist dessen Schadensreichweite natürlich begrenzt. 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 | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-30 02:10 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2075s$4c93$1@solani.org> |
| In reply to | #319330 |
On 03/29/2022 20:34, Hanno Foest wrote: > On 29.03.22 19:04, Helmut Schellong wrote: > >>> Das ist scheissegal was da steht, >> >> Nein, es ist gar nicht egal, was da steht. > > Doch, da du eh nicht fähig bist, es richtig zu verstehen. Das ist eine haltlose Behauptung. >> du kannst zB. nicht zeigen, daß es bei deiner Implementierung keine Seitenkanäle gibt, >> da evtl. noch nicht mal bekannt ist, welche das in Zukunft sein könnten. >>> >> Ich habe bereits gepostet, daß ich alle diese Algorithmen >> nur von und zu lokaler Festplatte benutze. > > Ok, wenn praktisch niemand irgendwo deinen binären Sondermüll benutzt, ist dessen Schadensreichweite natürlich begrenzt. > > Ja, so ist das. Ich habe bisher mehrfach http://www.schellong.de/htm/rabbit.bish.html gepostet. Darin ist erkennbar, wie genau ich mehrere Algorithmen benutze. Ich benutze das Skript erfolgreich. Es funktioniert makellos. -- 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 09:57 +0200 |
| Subject | Re: NIHS |
| Message-ID | <17jfwc7l1q5l8.dlg@news.bartheld.net> |
| In reply to | #319280 |
On Mon, 28 Mar 2022 20:23:42 +0200, 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. In der
>> Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
Die natürlich Seitenkanalangriffe einschließt. Die Implementierung des
Dual_EC-DRBG mit falschen Startwerten absolviert natürlich ebenfalls
alle Tests erfolgreich. Und wenn ich mir https://cryptopp.com/ so
ansehe, dann fällt mir auf der Einstiegsseite gleich ein Typo "ECDSA,
Determinsitic ECDSA (RFC 6979)" auf, da werden sich die Buben im
--------^
Laufzeitverhalten ihrer Unittests garantiert keinen Bruch gehoben haben.
Und jetzt kommt irgendwer daher, der mal ein C-Buch geschrieben hat und
präsentiert mir einen neuartigen Zufallszahlengenerator, der als Quelle
nur die PID nebst time() verwendet.
>> 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!
double pow(double x, double y) { return 1; }
TEST(Math, TestPow) { EXPECT_DOUBLE_EQ(pow(1, 2), 1); }
Läuft!
> 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.
Hinreichend vs. notwendig. Mittelstufenmathematik.
>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
Aber vielleicht bald Deine schwache Implementierung.
>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines
>> jeden Algorithmus, diesen zu 'knacken' oder Schwächen zu entdecken.
Jup. Alle Supercomputer dieser Welt sind mit nichts anderem beschäftigt,
als Herrn Schellong nachzuweisen, was für Böcke er mit seiner
bish-Shell geschossen hat, die - zumindest in der Windows-Version noch
nicht einmal digital signiert ist. Klar.
>> 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.
Tscha.
>> 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")
Genau. Und zwar in Kursivschrift, mit Ausrufezeichen!
>> 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?
Genau. Und zwar in Kursivschrift, ohne Ausrufezeichen diesmal.
>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte
>> Länge, innerhalb derer (sogar) die kryptographische Qualität
>> gesichert ist.
Was ist denn die kryptografische Qualität?
>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich
>> --> deterministisch. Andernfalls könnte nicht verschlüsselt und
>> entschlüsselt werden!
Hmmmm. Vielleicht mal zum Thema "Padding" schlau machen und warum man
dafür gerne irgendwelche Zufallszahlen benutzt [1].
>> Deshalb ist auch hier eine
>> übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis für
>> eine korrekte Implementation.
> äh, nein, sorry.
Hachja. Was solls. Wieder eine halbe Stunde Zeit verschwendet.
Volker
[1] https://www.di-mgt.com.au/cryptopad.html
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 16:28 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1v535$3ne1$1@solani.org> |
| In reply to | #319299 |
On 03/29/2022 09:57, Volker Bartheld wrote:
> On Mon, 28 Mar 2022 20:23:42 +0200, 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. In der
>>> Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
Ich schrieb:
|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 natürlich Seitenkanalangriffe einschließt. Die Implementierung des
> Dual_EC-DRBG mit falschen Startwerten absolviert natürlich ebenfalls
> alle Tests erfolgreich. Und wenn ich mir https://cryptopp.com/ so
> ansehe, dann fällt mir auf der Einstiegsseite gleich ein Typo "ECDSA,
> Determinsitic ECDSA (RFC 6979)" auf, da werden sich die Buben im
> --------^
> Laufzeitverhalten ihrer Unittests garantiert keinen Bruch gehoben haben.
Dieser Algorithmus ist doch seit vielen Jahren korrumpiert; hat mich nie interessiert.
Außerdem geht um eine korrekte Implementation gemäß einer Referenz-Implementation.
Desweiteren habe ich zu beinahe allen Algorithmen mehrere Quellen.
Beispielsweise RFC + PDF1 + PDF2.
Bei diesen Algorithmen habe ich daher garantiert keine falschen Konstanten implementiert.
Das wäre auch wegen der weltweiten Verbreitung längst aufgefallen.
Falsche Konstanten würden bei meinen Algorithmen zu abweichenden Ausgaben führen.
Aufgrund der Verwendung der Konstanten im Code.
Ein Tipp-Fehler im Plain-Text ist kein Nachweis für schlampige Arbeit im Pseudo-Code.
Deine Begründungen sind folglich irrelevant.
> Und jetzt kommt irgendwer daher, der mal ein C-Buch geschrieben hat und
> präsentiert mir einen neuartigen Zufallszahlengenerator, der als Quelle
> nur die PID nebst time() verwendet.
Alles falsch.
Ich habe drei Editionen eines C-Buches geschrieben.
Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut.
Es ist kein neuartiger Zufallszahlengenerator - ich habe ihn aus dem Netz.
03/24/2022 14:44
-----------------------------------------------------------------
[C-Code]
Der seed ist nicht durch ein Argument beeinflußbar.
Er basiert auf den Eingaben:
Prozeß-ID zufällig, unique
Zeit dauerhaft aufsteigend, in Sekunden
Array[Zeit] ungerade Zahlen <128 'wv[]'
Stack-Speicherinhalt buf[256], nicht vorhersagbar
-----------------------------------------------------------------
Wie kommt es, daß nun zum zweiten Mal behauptet wird, ich hätte
nur PID und time() als Eingabe verwendet?
http://www.schellong.de/htm/rand.htm#Seed
Im vorstehenden Code sind neben [C-Code] auch diese 4 Eingabequellen
angegeben und im Text beschrieben.
Auch den Link habe ich nicht zum ersten Mal 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!
>
> double pow(double x, double y) { return 1; }
> TEST(Math, TestPow) { EXPECT_DOUBLE_EQ(pow(1, 2), 1); }
>
> Läuft!
Irrelevant - und Quatsch.
>> 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.
>
> Hinreichend vs. notwendig. Mittelstufenmathematik.
Irrelevant + Quatsch.
Es geht hier um die von den Entwicklern angegebenen beweiskräftigen Test-Prozeduren.
>>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>
> Aber vielleicht bald Deine schwache Implementierung.
Wieso ist meine Implementierung schwach?
Die habe ich doch gar nicht gepostet!
Bist Du nun dem Schwachsinn verfallen?
>>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines
>>> jeden Algorithmus, diesen zu 'knacken' oder Schwächen zu entdecken.
>
> Jup. Alle Supercomputer dieser Welt sind mit nichts anderem beschäftigt,
> als Herrn Schellong nachzuweisen, was für Böcke er mit seiner
> bish-Shell geschossen hat, die - zumindest in der Windows-Version noch
> nicht einmal digital signiert ist. Klar.
Das ist dummer, falscher und irrelevanter Quatsch, den Du da geschrieben hast.
>>> 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.
>
> Tscha.
Schwachsinnige und irrelevante Bemerkung.
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!
Was mit MD5 passierte, ist irrelevant - weil anderer und älterer Algorithmus.
>>> 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")
>
> Genau. Und zwar in Kursivschrift, mit Ausrufezeichen!
Erneut irrelevanter Schwachsinn.
>>> 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?
>
> Genau. Und zwar in Kursivschrift, ohne Ausrufezeichen diesmal.
Erneut irrelevanter Schwachsinn.
>>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte
>>> Länge, innerhalb derer (sogar) die kryptographische Qualität
>>> gesichert ist.
>
> Was ist denn die kryptografische Qualität?
Das will ich hier nicht beantworten, weil viel zu aufwendig
angesichts des Schwachsinns, der hier verbreitet wird.
>>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich
>>> --> deterministisch. Andernfalls könnte nicht verschlüsselt und
>>> entschlüsselt werden!
>
> Hmmmm. Vielleicht mal zum Thema "Padding" schlau machen und warum man
> dafür gerne irgendwelche Zufallszahlen benutzt [1].
Irrelevanter Quatsch.
>>> Deshalb ist auch hier eine
>>> übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis für
>>> eine korrekte Implementation.
>> äh, nein, sorry.
>
> Hachja. Was solls. Wieder eine halbe Stunde Zeit verschwendet.
>
>
Die Entwickler haben das in ihren Dokumentationen geschrieben (von mir gepostet).
So ist das eben - Widerspruch ist da schlicht albern.
--
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 | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2022-03-29 11:21 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jag1ciFfedhU1@mid.individual.net> |
| In reply to | #319280 |
Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
> Also ist der triviale und offensichtlich falsche Algorithmus:
>
> if <Testvektor> then return <test result>
>
> bewiesenermaßen korrekt? ("reductio ad absurdum")
Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
aber alsbald einer besseren Implementierung weichen müsste...
> if <Testvektor1> then return <test result1>
> else if <Testvektor2> then return <test result2>
> usw.
...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
Entwicklung. Bei Kryptographie erst wenn Experten dauerhaft keine
Schwachstellen finden konnten.
Bernd
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-03-29 13:44 +0200 |
| Subject | Re: NIHS |
| Message-ID | <sw3yh8e4c7ri$.dlg@news.bartheld.net> |
| In reply to | #319302 |
On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:
> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
> aber alsbald einer besseren Implementierung weichen müsste...
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
> Entwicklung.
Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
Experten...
> Bei Kryptographie erst wenn Experten dauerhaft keine
> Schwachstellen finden konnten.
... bedienen darf. Nennt man dann "Peer-Review" usw.
Sobald ein Code Closed Source ist und da aus "Geheimhaltungsgründen"
niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung - drübersehen
darf, beginnt es schwer nach Fisch zu riechen. Das soll übrigens nicht
heißen, daß Open Source zwingend besser ist, denn unter den Freiwilligen
muß sich erstmal jemand finden, der die Zeit, Lust und Kompetenz auf/für
so eine Begutachtung hat.
Speziell bei kryptografischen Fragestellungen ist "Security by Obscurity"
eine Falle, in die von NIHS und dem Dunning-Kruger-Effekt Herausgeforderte
immer gerne tappen.
Da findet man dann in der Hall of Shame Perlen wie...
bool CheckLicense(const License& lic)
{
// [...]
if(lic.password="MyTopSecretPassword") return true;
// [...]
}
... oder:
std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::ostringstream o;
o << SysId << ExpireDays << "Magic";
MyMD5::MD5Hash md5(o.str());
return md5.str();
}
, vielleicht auch (in einer C++ Wrapper-DLL):
_declspec (dllexport) int __cdecl MyLicense::getExpireDays(char* feature)
{
int days = MyLicense::ExpireDays(feature, m_License);
switch(days)
{
-1: return -1;
eFOREVER: return INT_MAX;
default: return days;
}
}
. Was kann da schon groß schiefgehen?
Ich würde Helmuts Erzeugnisse schon aus dem Grund nicht benutzen, aus dem
man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet oder gar
ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner dübelt. Und
wenn ich mir das Copyright auf http://www.schellong.de/lizenz.htm ansehe,
vermute ich im Quellcode bestimmt nichts als Bleeding-Edge-Technologie.
Volker
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-03-29 14:42 +0200 |
| Subject | Re: NIHS |
| Message-ID | <h6aiyhliyarq.dlg@news.bartheld.net> |
| In reply to | #319302 |
On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:
> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
> aber alsbald einer besseren Implementierung weichen müsste...
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
> Entwicklung.
Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
Experten...
> Bei Kryptographie erst wenn Experten dauerhaft keine
> Schwachstellen finden konnten.
... bedienen dürfen. Nennt man dann "Peer-Review" usw.
Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung - drübersehen
darf, beginnt es schwer nach Fisch zu riechen. Das soll übrigens nicht
heißen, daß open Source zwingend besser ist, denn unter den Freiwilligen
muß sich erstmal jemand finden, der die Zeit, Lust und Kompetenz auf/für
so eine Begutachtung hat.
Speziell bei kryptografischen Fragestellungen ist "Security by Obscurity"
eine Falle, in die von NIHS und dem Dunning-Kruger-Effekt Herausgeforderte
immer gerne tappen.
Da findet man dann in der Hall of Shame Perlen wie...
bool CheckLicense(const License& lic)
{
// [...]
if(lic.password=="MyTopSecretPassword") return true;
// [...]
}
... oder:
std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::ostringstream o;
o << SysId << ExpireDays << "Magic";
MyMD5::MD5Hash md5(o.str());
return md5.str();
}
, vielleicht auch (in einer C++ Wrapper-DLL):
_declspec (dllexport) int __cdecl MyLicense::getExpireDays(char* feature)
{
int days = MyLicense::ExpireDays(feature, m_License);
switch(days)
{
-1: return -1;
eFOREVER: return INT_MAX;
default: return days;
}
}
. Was kann da schon groß schiefgehen?
Ich würde Helmuts Erzeugnisse schon aus dem Grund nicht benutzen, aus dem
man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet oder gar
ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner dübelt. Und
wenn ich mir das Copyright auf http://www.schellong.de/lizenz.htm ansehe,
vermute ich im Quellcode bestimmt nichts als Bleeding-Edge-Technologie.
Volker
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-29 17:02 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t1v71j$3ou5$1@solani.org> |
| In reply to | #319312 |
On 03/29/2022 14:42, Volker Bartheld wrote:
> On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:
>> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>>> Also ist der triviale und offensichtlich falsche Algorithmus:
>>> if <Testvektor> then return <test result>
>>> bewiesenermaßen korrekt? ("reductio ad absurdum")
>> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
>> aber alsbald einer besseren Implementierung weichen müsste...
>>> if <Testvektor1> then return <test result1>
>>> else if <Testvektor2> then return <test result2>
>>> usw.
>> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
>> Entwicklung.
>
> Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
> von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
> Experten...
>
>> Bei Kryptographie erst wenn Experten dauerhaft keine
>> Schwachstellen finden konnten.
>
> ... bedienen dürfen. Nennt man dann "Peer-Review" usw.
>
> Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
> niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung - drübersehen
> darf, beginnt es schwer nach Fisch zu riechen. Das soll übrigens nicht
> heißen, daß open Source zwingend besser ist, denn unter den Freiwilligen
> muß sich erstmal jemand finden, der die Zeit, Lust und Kompetenz auf/für
> so eine Begutachtung hat.
>
> Speziell bei kryptografischen Fragestellungen ist "Security by Obscurity"
> eine Falle, in die von NIHS und dem Dunning-Kruger-Effekt Herausgeforderte
> immer gerne tappen.
>
> Da findet man dann in der Hall of Shame Perlen wie...
>
> bool CheckLicense(const License& lic)
> {
> // [...]
> if(lic.password=="MyTopSecretPassword") return true;
> // [...]
> }
>
> ... oder:
>
> std::string ComputeLicense(const std::string& SysId, int ExpireDays)
> {
> std::ostringstream o;
> o << SysId << ExpireDays << "Magic";
> MyMD5::MD5Hash md5(o.str());
> return md5.str();
> }
>
> , vielleicht auch (in einer C++ Wrapper-DLL):
>
> _declspec (dllexport) int __cdecl MyLicense::getExpireDays(char* feature)
> {
> int days = MyLicense::ExpireDays(feature, m_License);
> switch(days)
> {
> -1: return -1;
> eFOREVER: return INT_MAX;
> default: return days;
> }
> }
>
> . Was kann da schon groß schiefgehen?
>> Ich würde Helmuts Erzeugnisse schon aus dem Grund nicht benutzen, aus dem
Es sind nicht meine Erzeugnisse!
Ganz zu Anfang und später schrieb ich, daß ich diese Algorithmen nicht selbst entwickelt habe.
Keinen davon.
Jetzt schreibe ich das erneut.
Was ist so schwer daran zu verstehen?
Und so etwas wie die vorstehenden Code-Beispiele würde ich niemals übernehmen!
> man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet oder gar
> ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner dübelt. Und
> wenn ich mir das Copyright auf http://www.schellong.de/lizenz.htm ansehe,
> vermute ich im Quellcode bestimmt nichts als Bleeding-Edge-Technologie.
>
>
Man kann von der lizenz.htm nicht auf die Qualität des Quellcodes schließen.
Das ist massiv unprofessionell - Einfach horrender Quatsch!
Viel wichtiger sind http://www.schellong.de/txt/version.txt http://www.schellong.de/htm/bishmnk.htm
--
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:13 +0200 |
| Subject | Re: NIHS |
| Message-ID | <zitexpppu53d$.dlg@news.bartheld.net> |
| In reply to | #319302 |
On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:
> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
> aber alsbald einer besseren Implementierung weichen müsste...
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
> Entwicklung.
Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
Experten...
> Bei Kryptographie erst wenn Experten dauerhaft keine
> Schwachstellen finden konnten.
... bedienen dürfen. Nennt man dann "Peer-Review" usw.
Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung -
drübersehen darf, beginnt es schwer nach Fisch zu riechen. Das soll
übrigens nicht heißen, daß open Source zwingend besser ist, denn unter
den Freiwilligen muß sich erstmal jemand finden, der die Zeit, Lust und
Kompetenz auf/für so eine Begutachtung hat.
Speziell bei kryptografischen Fragestellungen ist "Security by
Obscurity" eine Falle, in die von NIHS und dem Dunning-Kruger-Effekt
Herausgeforderte immer gerne tappen.
Da findet man dann in der Hall of Shame Perlen wie...
bool CheckLicense(const License& lic)
{
// [...]
if(lic.password=="MyTopSecretPassword") return true;
// [...]
}
... oder:
std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::ostringstream o;
o << SysId << ExpireDays << "Magic";
MyMD5::MD5Hash md5(o.str());
return md5.str();
}
, vielleicht auch (in einer C++ Wrapper-DLL):
_declspec (dllexport) int __cdecl MyLicense::getExpireDays(char*
feature)
{
int days = MyLicense::ExpireDays(feature, m_License);
switch(days)
{
case -1: return -1;
case eFOREVER: return INT_MAX;
default: return days;
}
}
. Was kann da schon groß schiefgehen?
Ich würde Helmuts Erzeugnisse schon aus dem Grund nicht benutzen, aus
dem man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet
oder gar ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner
dübelt. Und wenn ich mir das Copyright auf
http://www.schellong.de/lizenz.htm ansehe, vermute ich im Quellcode
bestimmt nichts als Bleeding-Edge-Technologie.
Volker
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2022-03-29 23:35 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jahcdnFnj4lU1@mid.individual.net> |
| In reply to | #319325 |
Am 29.03.2022 um 18:13 schrieb Volker Bartheld:
>> Bei Kryptographie erst wenn Experten dauerhaft keine
>> Schwachstellen finden konnten.
>
> ... bedienen dürfen. Nennt man dann "Peer-Review" usw.
Ja, aber gerade bei Kryptographie ist das Feld viel größer. Attacken werden
teils erst Jahre oder Jahrzehnte nach der Entwicklung, Implementierung und
Benutzung der Algorithmen gefunden, und nur zum Teil auf Grund schnellerer
Rechner. Ein Algorithmus ist in der Regel nicht per se "sicher" oder
"unsicher", im allgemeinen gibt es eine Abschätzung wie lange ein Algorithmus
sicher ist. Irgendwann sind die Rechner halt so schnell daß man vieles einfach
per brute force knacken kann, eine Abschätzung darüber wie lange das dauern
wird zeigt die sinnvolle Lebensdauer an. Und die kann sehr schnell gegen 0
sinken, wenn unerwartet Attacken entdeckt werden.
> Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
> niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung -
> drübersehen darf, beginnt es schwer nach Fisch zu riechen. Das soll
> übrigens nicht heißen, daß open Source zwingend besser ist, denn unter
> den Freiwilligen muß sich erstmal jemand finden, der die Zeit, Lust und
> Kompetenz auf/für so eine Begutachtung hat.
Bei closed source stellt sich das Problem gar nicht, da ja keiner den Code
prüfen kann. "Beweis" der Sicherheit durch Aufstampfen, kennen wir. Davon hält
man genau eines: Abstand.
> bool CheckLicense(const License& lic)
> {
> // [...]
> if(lic.password=="MyTopSecretPassword") return true;
> // [...]
> }
Haha, erinnert mich ein wenig an den Pen-Tester, der nach Tagen
freudestrahlend zu mir kam und meinte, er hätte jetzt *DIE* Lücke im
disassemblierten Code gefunden (Hätte er gefragt, hätte er ja auch den Source
mit Kommentaren und Erklärung dazu bekommen, aber das war wohl
wissenschaftlicher Forschergeist). Da wäre ein Passwort im Klartext im Code!
Ja genau! Ich habe ihn dann etwas lapidar auf Kapitel x in Handbuch y
verwiesen, in dem genau beschrieben war, daß der keystore aus
implementatorischen Gründen ein Passwort verlangt, dieses daher im Programm ja
vorliegen muß und das feste Passwort "abc" wie folgt verwendet wird.
Er war ein bisschen geknickt, hatte er doch kurz davor genau dieses geforderte
Sicherheitshandbuch mit allen Algorithmen validiert.
Bernd
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-03-30 02:28 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2087e$4cp7$1@solani.org> |
| In reply to | #319331 |
On 03/29/2022 23:35, Bernd Laengerich wrote:
> Am 29.03.2022 um 18:13 schrieb Volker Bartheld:
>
>>> Bei Kryptographie erst wenn Experten dauerhaft keine
>>> Schwachstellen finden konnten.
>>
>> ... bedienen dürfen. Nennt man dann "Peer-Review" usw.
>
> Ja, aber gerade bei Kryptographie ist das Feld viel größer. Attacken werden teils erst Jahre oder Jahrzehnte nach der Entwicklung, Implementierung und Benutzung der Algorithmen gefunden, und nur zum Teil auf Grund schnellerer Rechner. Ein Algorithmus ist in der Regel nicht per se "sicher" oder "unsicher", im allgemeinen gibt es eine Abschätzung wie lange ein Algorithmus sicher ist. Irgendwann sind die Rechner halt so schnell daß man vieles einfach per brute force knacken kann, eine Abschätzung darüber wie lange das dauern wird zeigt die sinnvolle Lebensdauer an. Und die kann sehr schnell gegen 0 sinken, wenn unerwartet Attacken entdeckt werden.
Du beschreibst hier korrekt die (Zwangs-)Lage bei kryptographischen Algorithmen.
Unerwartete Attacken können aber auch dauerhaft ausbleiben.
Brute force liefert nicht garantiert ein Knacken.
Beispielsweise Rabbit hat seit 2003 _keine_ Schwäche offenbart.
>> Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
>> niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung -
>> drübersehen darf, beginnt es schwer nach Fisch zu riechen. Das soll
>> übrigens nicht heißen, daß open Source zwingend besser ist, denn unter
>> den Freiwilligen muß sich erstmal jemand finden, der die Zeit, Lust und
>> Kompetenz auf/für so eine Begutachtung hat.
>
> Bei closed source stellt sich das Problem gar nicht, da ja keiner den Code prüfen kann. "Beweis" der Sicherheit durch Aufstampfen, kennen wir. Davon hält man genau eines: Abstand.
>
>> bool CheckLicense(const License& lic)
>> {
>> // [...]
>> if(lic.password=="MyTopSecretPassword") return true;
>> // [...]
>> }
>
> Haha, erinnert mich ein wenig an den Pen-Tester, der nach Tagen freudestrahlend zu mir kam und meinte, er hätte jetzt *DIE* Lücke im disassemblierten Code gefunden (Hätte er gefragt, hätte er ja auch den Source mit Kommentaren und Erklärung dazu bekommen, aber das war wohl wissenschaftlicher Forschergeist). Da wäre ein Passwort im Klartext im Code! Ja genau! Ich habe ihn dann etwas lapidar auf Kapitel x in Handbuch y verwiesen, in dem genau beschrieben war, daß der keystore aus implementatorischen Gründen ein Passwort verlangt, dieses daher im Programm ja vorliegen muß und das feste Passwort "abc" wie folgt verwendet wird.
> Er war ein bisschen geknickt, hatte er doch kurz davor genau dieses geforderte Sicherheitshandbuch mit allen Algorithmen validiert.
>
>
Schwachsinns-Code.
Ich verschleiere solche Daten u.a. durch a='p', b='a', c='s', d='w';
411] strings /u/bin/bish
FreeBSD
FreeBSD
AWAVSPH
AWAVAUATSPI
ffffff.
...
--
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:16 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hmhb$1ad21$1@news1.tnib.de> |
| In reply to | #319278 |
Helmut Schellong <rip@schellong.biz> wrote: >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. Warum eigentlich kein AES? Hat es irgendwelche Auswirkungen auf die Sicherheit, dass Rabbit nur für 128-bit-Keys spezifiziert zu sein scheint? -- -------------------------------------- !! 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:42 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hrhp$f4j0$1@solani.org> |
| In reply to | #319561 |
On 04/05/2022 17:16, Marc Haber wrote: > Helmut Schellong <rip@schellong.biz> wrote: >> 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. > > Warum eigentlich kein AES? Hat es irgendwelche Auswirkungen auf die > Sicherheit, dass Rabbit nur für 128-bit-Keys spezifiziert zu sein > scheint? > AES ist älter und gilt als _theoretisch_ 'gebrochen'. Rabbit hat keine Schwäche und auch keine erfolgreiche Attacke. Rabbit hat neben dem Key (128 Bit) noch den IV mit 64 weiteren Bits. Es kommt nicht nur auf die Key-Länge an, sondern auf alle Längen. Der interne Zustand hat 513 Bit, was auch sicherheitsrelevant ist. Das alles ist ausführlich in der .pdf beschrieben. Dragon hat Key&IV = 128 oder Key&IV = 256. -- 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 | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-04-05 18:44 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hrm7$5qk$1@news.bawue.net> |
| In reply to | #319564 |
On 4/5/22 18:42, Helmut Schellong wrote: > On 04/05/2022 17:16, Marc Haber wrote: >> Helmut Schellong <rip@schellong.biz> wrote: >>> 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. >> >> Warum eigentlich kein AES? Hat es irgendwelche Auswirkungen auf die >> Sicherheit, dass Rabbit nur für 128-bit-Keys spezifiziert zu sein >> scheint? >> > > AES ist älter und gilt als _theoretisch_ 'gebrochen'. Quelle? Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-05 18:51 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t2hs1s$f4vq$1@solani.org> |
| In reply to | #319565 |
On 04/05/2022 18:44, Gerrit Heitsch wrote: > On 4/5/22 18:42, Helmut Schellong wrote: >> On 04/05/2022 17:16, Marc Haber wrote: >>> Helmut Schellong <rip@schellong.biz> wrote: >>>> 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. >>> >>> Warum eigentlich kein AES? Hat es irgendwelche Auswirkungen auf die >>> Sicherheit, dass Rabbit nur für 128-bit-Keys spezifiziert zu sein >>> scheint? >>> >> >> AES ist älter und gilt als _theoretisch_ 'gebrochen'. > > Quelle? > > https://de.wikipedia.org/wiki/Advanced_Encryption_Standard#Schw%C3%A4chen_und_Angriffe https://de.wikipedia.org/wiki/Rabbit_%28Algorithmus%29 https://de.wikipedia.org/wiki/Rabbit_(Algorithmus)#Sicherheit -- 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 | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-04-06 18:36 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jb5trvFm8ftU1@mid.individual.net> |
| In reply to | #319565 |
Gerrit Heitsch: > On 4/5/22 18:42, Helmut Schellong wrote: >> On 04/05/2022 17:16, Marc Haber wrote: >>> Helmut Schellong <rip@schellong.biz> wrote: >>>> 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. >>> >>> Warum eigentlich kein AES? Hat es irgendwelche Auswirkungen auf die >>> Sicherheit, dass Rabbit nur für 128-bit-Keys spezifiziert zu sein >>> scheint? >>> >> >> AES ist älter und gilt als _theoretisch_ 'gebrochen'. > > Quelle? <https://www.cl.cam.ac.uk/~rja14/serpent.html> <https://eprint.iacr.org/2002/044> Bruce Schneier hat über Angriffe auf AES auch schon mal geschrieben: <https://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html> <https://www.schneier.com/blog/archives/2009/07/another_new_aes.html> -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-04-23 20:12 +0200 |
| Subject | Re: NIHS |
| Message-ID | <t41fi9$1b0td$1@solani.org> |
| In reply to | #319564 |
On 04/05/2022 18:42, Helmut Schellong wrote: > On 04/05/2022 17:16, Marc Haber wrote: >> Helmut Schellong <rip@schellong.biz> wrote: >>> 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. >> >> Warum eigentlich kein AES? Hat es irgendwelche Auswirkungen auf die >> Sicherheit, dass Rabbit nur für 128-bit-Keys spezifiziert zu sein >> scheint? >> > > AES ist älter und gilt als _theoretisch_ 'gebrochen'. > Rabbit hat keine Schwäche und auch keine erfolgreiche Attacke. > Rabbit hat neben dem Key (128 Bit) noch den IV mit 64 weiteren Bits. > Es kommt nicht nur auf die Key-Länge an, sondern auf alle Längen. > Der interne Zustand hat 513 Bit, was auch sicherheitsrelevant ist. > Das alles ist ausführlich in der .pdf beschrieben. > > Dragon hat Key&IV = 128 oder Key&IV = 256. > > 256 bit: viele Jahre Brute-force mit Quanten-Computern, erst recht mit Super-Computern. Es ist anzunehmen, daß 128+64 = 192 Bits auch sicher vor Quanten-Computern sind. Was kostet es, einen Quanten-Computer so lange zu mieten? Ich verschlüssele mehrfach hintereinander, mit verschiedenen Algorithmen und Schlüsseln. Auch mit einem selbst entwickelten Algorithmus. Da erübrigt sich jeder erdenkliche Entschlüsselungsversuch. http://www.schellong.de/htm/dragon.c.html#beweis -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz
[toc] | [prev] | [next] | [standalone]
| From | Laurenz Trossel <me@example.invalid> |
|---|---|
| Date | 2022-04-23 23:59 +0000 |
| Subject | Re: NIHS |
| Message-ID | <t423sn$1vfb$1@gioia.aioe.org> |
| In reply to | #320412 |
On 2022-04-23, Helmut Schellong <rip@schellong.biz> wrote: > Ich verschlüssele mehrfach hintereinander, mit verschiedenen Algorithmen und Schlüsseln. > Auch mit einem selbst entwickelten Algorithmus. > Da erübrigt sich jeder erdenkliche Entschlüsselungsversuch. Cryptochef, bist du's?
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2022-04-24 11:55 +0200 |
| Subject | Re: NIHS |
| Message-ID | <jckl3vFl60vU2@mid.individual.net> |
| In reply to | #320415 |
Am 24.04.2022 um 01:59 schrieb Laurenz Trossel: > On 2022-04-23, Helmut Schellong <rip@schellong.biz> wrote: > >> Ich verschlüssele mehrfach hintereinander, mit verschiedenen Algorithmen und Schlüsseln. >> Auch mit einem selbst entwickelten Algorithmus. >> Da erübrigt sich jeder erdenkliche Entschlüsselungsversuch. > > Cryptochef, bist du's? Irgendwie erinnert er mich immer an den Profiklaus von d.r.f.
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | de.sci.electronics
csiph-web