Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #369166 > unrolled thread
| Started by | Helmut Schellong <var@schellong.biz> |
|---|---|
| First post | 2026-09-08 19:00 +0200 |
| Last post | 2026-09-12 15:31 +0200 |
| Articles | 20 on this page of 227 — 17 participants |
Back to article view | Back to de.sci.electronics
Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-08 19:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-08 22:34 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 07:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-09 13:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 16:22 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-09 16:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 17:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:22 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-10 07:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-10 16:47 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 18:12 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-09 17:20 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 18:20 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:21 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 01:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 07:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 13:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 15:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 17:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 20:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 00:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 18:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 21:30 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 12:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 22:06 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-13 15:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 20:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 08:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 09:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 14:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:39 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 23:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-13 15:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 22:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 23:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 23:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 23:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 00:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-13 15:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 21:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-13 22:30 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 23:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 11:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 11:56 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-14 16:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 17:31 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 19:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 22:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-15 23:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-16 12:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-17 00:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 11:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-14 19:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 22:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-15 09:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:39 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-14 10:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 11:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-15 08:25 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-16 08:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-16 13:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-16 18:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-16 23:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-17 08:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 15:07 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 09:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 11:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 12:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 11:07 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 11:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 22:12 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 01:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 09:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 14:24 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 20:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-14 16:25 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-13 15:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 21:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 11:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 12:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 13:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 16:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 19:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 22:46 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-15 09:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-17 13:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Axel Berger <Spam@Berger-Odenthal.De> - 2026-09-17 14:24 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-17 16:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 08:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 08:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 11:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-18 09:53 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 22:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 12:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 22:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Christian Weisgerber <naddy@mips.inka.de> - 2026-09-18 14:53 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 18:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-18 22:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 00:37 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 02:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-19 09:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 14:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-19 15:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 20:37 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 15:16 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-17 15:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 17:25 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-17 20:37 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 21:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-17 21:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 22:05 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-17 21:47 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 10:36 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-14 16:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 17:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-12 06:55 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:55 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 23:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-10 19:04 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 01:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 10:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 11:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 14:51 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Axel Berger <Spam@Berger-Odenthal.De> - 2026-09-10 15:35 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Hergen Lehmann <hlehmann-usenet26@snafu.de> - 2026-09-10 16:24 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Axel Berger <Spam@Berger-Odenthal.De> - 2026-09-10 21:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-16 06:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-10 22:20 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 16:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 15:45 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2026-09-11 18:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 20:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 08:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 15:57 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:10 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-09 18:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 18:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:18 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 00:42 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 07:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 09:55 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-10 22:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-11 00:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 08:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-12 09:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 09:31 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-12 13:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 15:46 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-12 15:56 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-24 18:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 16:29 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 23:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 14:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 16:51 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 00:22 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 09:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Heinz Schmitz <sch@example.invalid> - 2026-09-09 09:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2026-09-09 09:21 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 15:07 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 15:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-09 17:21 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 18:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 07:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-11 09:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-11 09:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-11 15:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 11:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 19:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 21:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 12:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:55 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:05 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-09 23:30 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 02:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 10:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 15:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 20:18 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 01:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-10 23:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-11 10:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 09:05 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-14 20:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-14 20:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-15 09:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-09-15 09:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Heinz Schmitz <sch@example.invalid> - 2026-09-21 14:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2026-09-11 18:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 20:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 08:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 09:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 10:45 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 14:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 14:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:51 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-09-11 18:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 20:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 21:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-09-12 13:47 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 15:31 +0200
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-14 19:28 +0200 |
| Message-ID | <slrn11agbm4.u96o.als@mordor.angband.thangorodrim.de> |
| In reply to | #369407 |
Helmut Schellong <var@schellong.biz> wrote:
> Alexander Schreiber wrote on 14.09.2026 16:49:
>> Helmut Schellong <var@schellong.biz> wrote:
>
>>> prüft die Zufallsqualität der ausgegebenen Bitfolge.
>>> Wenn hier keine gute Qualität gegeben ist, ist der ausgebende Algorithmus Schrott.
>>
>> Das trifft aber genauso gut auf gute PRNGs zu. Aber hey, PRNG oder
>> Verschlüsselung, was ist am Ende schon der Unterschied ...
>
> A Statistical Test Suite for
> Random and Pseudorandom
> Number Generators for
> Cryptographic Applications
>
> Das ist der Titel der Dokumentation.
>
> Also ...für kryptographische Applikationen.
> Immerhin.
Ja, aber für RNGs und PRNGs, nicht für Verschlüsselungsalgorithmen, das
steht _direkt_ in dem von Dir zitiertem Block.
Der Unterschied zwischen (P)RNG und Verschlüsselungsalgorithmus ist
Dir aber schon klar, oder?
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-14 22:52 +0200 |
| Message-ID | <1189mqo$73mq$1@solani.org> |
| In reply to | #369417 |
Alexander Schreiber wrote on 14.09.2026 19:28: > Helmut Schellong <var@schellong.biz> wrote: >> Alexander Schreiber wrote on 14.09.2026 16:49: >>> Helmut Schellong <var@schellong.biz> wrote: >> >>>> prüft die Zufallsqualität der ausgegebenen Bitfolge. >>>> Wenn hier keine gute Qualität gegeben ist, ist der ausgebende Algorithmus Schrott. >>> >>> Das trifft aber genauso gut auf gute PRNGs zu. Aber hey, PRNG oder >>> Verschlüsselung, was ist am Ende schon der Unterschied ... >> >> A Statistical Test Suite for >> Random and Pseudorandom >> Number Generators for >> Cryptographic Applications >> >> Das ist der Titel der Dokumentation. >> >> Also ...für kryptographische Applikationen. >> Immerhin. > > Ja, aber für RNGs und PRNGs, nicht für Verschlüsselungsalgorithmen, das > steht _direkt_ in dem von Dir zitiertem Block. > > Der Unterschied zwischen (P)RNG und Verschlüsselungsalgorithmus ist > Dir aber schon klar, oder? Natürlich. Eine Krypto-Verschlüsselung ist ohne Generator nicht möglich. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-15 09:54 +0200 |
| Message-ID | <slrn11ahudo.1a3sn.als@mordor.angband.thangorodrim.de> |
| In reply to | #369423 |
Helmut Schellong <var@schellong.biz> wrote:
> Alexander Schreiber wrote on 14.09.2026 19:28:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Alexander Schreiber wrote on 14.09.2026 16:49:
>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>
>>>>> prüft die Zufallsqualität der ausgegebenen Bitfolge.
>>>>> Wenn hier keine gute Qualität gegeben ist, ist der ausgebende Algorithmus Schrott.
>>>>
>>>> Das trifft aber genauso gut auf gute PRNGs zu. Aber hey, PRNG oder
>>>> Verschlüsselung, was ist am Ende schon der Unterschied ...
>>>
>>> A Statistical Test Suite for
>>> Random and Pseudorandom
>>> Number Generators for
>>> Cryptographic Applications
>>>
>>> Das ist der Titel der Dokumentation.
>>>
>>> Also ...für kryptographische Applikationen.
>>> Immerhin.
>>
>> Ja, aber für RNGs und PRNGs, nicht für Verschlüsselungsalgorithmen, das
>> steht _direkt_ in dem von Dir zitiertem Block.
>>
>> Der Unterschied zwischen (P)RNG und Verschlüsselungsalgorithmus ist
>> Dir aber schon klar, oder?
>
> Natürlich.
> Eine Krypto-Verschlüsselung ist ohne Generator nicht möglich.
Wie schon geschrieben: Der übliche grobe Unfug von jemanden ohne Ahnung.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-15 15:39 +0200 |
| Message-ID | <118bhp0$agjo$1@solani.org> |
| In reply to | #369427 |
Alexander Schreiber wrote on 15.09.2026 09:54: > Helmut Schellong <var@schellong.biz> wrote: >> Alexander Schreiber wrote on 14.09.2026 19:28: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Alexander Schreiber wrote on 14.09.2026 16:49: >>>>> Helmut Schellong <var@schellong.biz> wrote: >>>> >>>>>> prüft die Zufallsqualität der ausgegebenen Bitfolge. >>>>>> Wenn hier keine gute Qualität gegeben ist, ist der ausgebende Algorithmus Schrott. >>>>> >>>>> Das trifft aber genauso gut auf gute PRNGs zu. Aber hey, PRNG oder >>>>> Verschlüsselung, was ist am Ende schon der Unterschied ... >>>> >>>> A Statistical Test Suite for >>>> Random and Pseudorandom >>>> Number Generators for >>>> Cryptographic Applications >>>> >>>> Das ist der Titel der Dokumentation. >>>> >>>> Also ...für kryptographische Applikationen. >>>> Immerhin. >>> >>> Ja, aber für RNGs und PRNGs, nicht für Verschlüsselungsalgorithmen, das >>> steht _direkt_ in dem von Dir zitiertem Block. >>> >>> Der Unterschied zwischen (P)RNG und Verschlüsselungsalgorithmus ist >>> Dir aber schon klar, oder? >> >> Natürlich. >> Eine Krypto-Verschlüsselung ist ohne Generator nicht möglich. > > Wie schon geschrieben: Der übliche grobe Unfug von jemanden ohne Ahnung. Die wahren in der Praxis vorliegenden Definitionen sind Euch unbekannt. Ihr stolpert deshalb blind herum und kommt ständig zu falschen Schlüssen und Einschätzungen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-14 10:11 +0200 |
| Message-ID | <c0bfaltlhe31j3c2ltmi2vujgi3ac0q60e@4ax.com> |
| In reply to | #369380 |
On Sun, 13 Sep 2026 21:26:22 +0200, Helmut Schellong <var@schellong.biz> wrote: >Diese Suite wurde vom NIST extra dafür entwickelt, um kryptographische Algorithmen zu prüfen. >Du aber findest es lächerlich, daß das NIST ihrer Suite diese Aufgabe zuweist. > >Ich habe nicht behauptet, daß die von mir implementierten kryptographischen Algorithmen >sicher sind, weil sie die Tests der Suite bestanden haben. Hmja, ich meine doch, so um 2022... Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-14 11:38 +0200 |
| Message-ID | <1188fat$8b6f$1@solani.org> |
| In reply to | #369387 |
Thomas Prufer wrote on 14.09.2026 10:11: > On Sun, 13 Sep 2026 21:26:22 +0200, Helmut Schellong <var@schellong.biz> wrote: > >> Diese Suite wurde vom NIST extra dafür entwickelt, um kryptographische Algorithmen zu prüfen. >> Du aber findest es lächerlich, daß das NIST ihrer Suite diese Aufgabe zuweist. >> >> Ich habe nicht behauptet, daß die von mir implementierten kryptographischen Algorithmen >> sicher sind, weil sie die Tests der Suite bestanden haben. > > Hmja, ich meine doch, so um 2022... Ich hatte damals in irgendeine Newsgroup etwas zu meinen NIST-Tests gepostet. Aber ich kann mich nicht erinnern, sinngemäß gesagt zu haben: "Durch die bestandenen Tests mit der NIST-Suite habe ich hier folglich sichere Algorithmen vorliegen." Wollte ich das verifizieren, müßte ich meinen alten PC von vor 2003 in Betrieb nehmen. "Hmja, ich meine doch, so um 2022..." Diffuser geht's kaum. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-22r1a.pdf ---------------------------------------------------------------------------------------------------------------- This paper discusses some aspects of selecting and testing random and pseudorandom number generators. The outputs of such generators may be used in many cryptographic applications, such as the generation of key material. Generators suitable for use in cryptographic applications may need to meet stronger requirements than for other applications. In particular, their outputs must be unpredictable in the absence of knowledge of the inputs. Some criteria for characterizing and selecting appropriate generators are discussed in this document. The subject of statistical testing and its relation to cryptanalysis is also discussed, and some recommended statistical tests are provided. These tests may be useful as a first step in determining whether or not a generator is suitable for a particular cryptographic application. However, no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis. The design and cryptanalysis of generators is outside the scope of this paper. ---------------------------------------------------------------------------------------------------------------- Wie ich bereits berichtete - aktuell erneut. Es bleibt jedoch nicht hängen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-15 08:25 +0200 |
| Message-ID | <n0phaltbdrgbps8omh28fkc2lr25q38f9i@4ax.com> |
| In reply to | #369394 |
On Mon, 14 Sep 2026 11:38:54 +0200, Helmut Schellong <var@schellong.biz> wrote:
>Thomas Prufer wrote on 14.09.2026 10:11:
>> On Sun, 13 Sep 2026 21:26:22 +0200, Helmut Schellong <var@schellong.biz> wrote:
>>
>>> Diese Suite wurde vom NIST extra dafür entwickelt, um kryptographische Algorithmen zu prüfen.
>>> Du aber findest es lächerlich, daß das NIST ihrer Suite diese Aufgabe zuweist.
>>>
>>> Ich habe nicht behauptet, daß die von mir implementierten kryptographischen Algorithmen
>>> sicher sind, weil sie die Tests der Suite bestanden haben.
>>
>> Hmja, ich meine doch, so um 2022...
>
>Ich hatte damals in irgendeine Newsgroup etwas zu meinen NIST-Tests gepostet.
>Aber ich kann mich nicht erinnern, sinngemäß gesagt zu haben: "Durch die bestandenen
>Tests mit der NIST-Suite habe ich hier folglich sichere Algorithmen vorliegen."
>
>Wollte ich das verifizieren, müßte ich meinen alten PC von vor 2003 in Betrieb nehmen.
>
>"Hmja, ich meine doch, so um 2022..."
>
>Diffuser geht's kaum.
Du hast damals folgenden Schluss gezogen: Mein Algorithmus (ich mein es war AES)
verschlüsselt die Testvektoren korrekt, also ist dies ein Beweis dafür: "Der
Algorithmus ist korrekt implementiert." Und dieser Schluss ist falsch.
Ich zitiere meine damalige Antwort:
>On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote:
>
>>Es ist _ganz generell_ richtig, was Du schreibst.
>>Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>>
>>Diese hatte ich aufgelistet:
>> |Die Kern-Algorithmen sind nicht selbst entwickelt.
>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
>> |Diese Algorithmen sind alle kryptographisch.
>>
>>In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>>ist auch meist eine Testprozedur durch die Entwickler angegeben.
>>Diese habe ich jeweils durchgeführt!
>>Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>>Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>>Korrekter und beweiskräftiger geht es nicht!
>
>Das wurde ignoriert weil es kein Beweis ist...
>
>>Desweiteren ist abhängig vom Algorithmus meist ein einziger Test tatsächlich beweiskräftig.
>
>Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.
>
>>Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>>Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
>>zu 'knacken' oder Schwächen zu entdecken.
>>Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
>>Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!
>
>Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und Kollisionen in
>Sekunden gefunden wurden. Das Zeigen *einer* solchen Kollision war ein Beweis,
>aber: andersrum gilt nicht.
>
>>Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für eine korrekte Implementation/!
>
>Also ist der triviale und offensichtlich falsche Algorithmus:
>
>if <Testvektor> then return <test result>
>
>bewiesenermaßen korrekt? ("reductio ad absurdum")
>
>>Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene Test-Inputs angegeben, um
>>wirklich _jeden Zweifel_ auszuräumen.
>>Ich habe stets alle diese Tests durchgeführt - mit übereinstimmendem Ergebnis.
>
>Also ist der triviale und offensichtlich falsche Algorithmus:
>
>if <Testvektor1> then return <test result1>
>else if <Testvektor2> then return <test result2>
>usw.
>bewiesenermaßen korrekt?
>
>>Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
>>derer (sogar) die kryptographische Qualität gesichert ist.
>>Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
>>Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
>>Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
>>für eine korrekte Implementation.
>
>äh, nein, sorry.
>
>
>Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-15 15:17 +0200 |
| Message-ID | <118bggu$afoj$1@solani.org> |
| In reply to | #369424 |
Thomas Prufer wrote on 15.09.2026 08:25:
> On Mon, 14 Sep 2026 11:38:54 +0200, Helmut Schellong <var@schellong.biz> wrote:
>
>> Thomas Prufer wrote on 14.09.2026 10:11:
>>> On Sun, 13 Sep 2026 21:26:22 +0200, Helmut Schellong <var@schellong.biz> wrote:
>>>
>>>> Diese Suite wurde vom NIST extra dafür entwickelt, um kryptographische Algorithmen zu prüfen.
>>>> Du aber findest es lächerlich, daß das NIST ihrer Suite diese Aufgabe zuweist.
>>>>
>>>> Ich habe nicht behauptet, daß die von mir implementierten kryptographischen Algorithmen
>>>> sicher sind, weil sie die Tests der Suite bestanden haben.
>>>
>>> Hmja, ich meine doch, so um 2022...
>>
>> Ich hatte damals in irgendeine Newsgroup etwas zu meinen NIST-Tests gepostet.
>> Aber ich kann mich nicht erinnern, sinngemäß gesagt zu haben: "Durch die bestandenen
>> Tests mit der NIST-Suite habe ich hier folglich sichere Algorithmen vorliegen."
>>
>> Wollte ich das verifizieren, müßte ich meinen alten PC von vor 2003 in Betrieb nehmen.
>>
>> "Hmja, ich meine doch, so um 2022..."
>>
>> Diffuser geht's kaum.
>
> Du hast damals folgenden Schluss gezogen: Mein Algorithmus (ich mein es war AES)
> verschlüsselt die Testvektoren korrekt, also ist dies ein Beweis dafür: "Der
> Algorithmus ist korrekt implementiert." Und dieser Schluss ist falsch.
http://www.schellong.de/htm/dragon.c.html
Zeile 140: buf[nk++]^= k, nb-=sizeof(k);
Die erste Hälfte der vorstehenden Zeile im C-Code stellt
die _vollständige_ Ver- und Entschlüsselungs-Operation dar!
Es ist eine simple XOR-Verknüpfung.
Mehr ist da nicht!
Die weiteren ungefähr 200 Zeilen dienen als Zufallszahlen-Generator.
Folglich hat der Generator einen Anteil von über 99%.
Das gilt prinzipiell für die meisten solchen Algorithmen.
Z.B. 'rabbit' ist ebenfalls eine Strom-Chiffre.
Es ist klar erkennbar, welch massive Täuschung der hiesigen Leser vorgenommen wurde und wird.
Beweise und konkrete Realität zählen hier nicht, sondern Behauptungen einiger Weniger.
Und mit AES hatte und habe ich nichts am Hut!
> Ich zitiere meine damalige Antwort:
>
>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@schellong.biz> wrote:
>>
>>> Es ist _ganz generell_ richtig, was Du schreibst.
>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>>>
>>> Diese hatte ich aufgelistet:
>>> |Die Kern-Algorithmen sind nicht selbst entwickelt.
>>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
>>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
>>> |Diese Algorithmen sind alle kryptographisch.
>>>
>>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
>>> Diese habe ich jeweils durchgeführt!
>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>>> Korrekter und beweiskräftiger geht es nicht!
>>
>> Das wurde ignoriert weil es kein Beweis ist...
Es ist aber doch ein Beweis!
Du verhöhnst und beleidigst die Entwickler, die das extra vorbereiten zwecks Verifizierung!
>>> 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.
Doch, es ist ein Beweis.
In der Datei steht die Überschrift: "Beweis einer korrekten Implementation".
Die Krypto-Entwickler bereiten Solches vor, um den Nachweis
einer korrekten Implementation erbringen zu können!
>>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
>>> zu 'knacken' oder Schwächen zu entdecken.
>>> Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
>>> Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!
>>
>> Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und Kollisionen in
>> Sekunden gefunden wurden. Das Zeigen *einer* solchen Kollision war ein Beweis,
>> aber: andersrum gilt nicht.
Was schrieb ich oben?
"Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'."
Ich mußte schon oft Schwächen in Deutsch feststellen.
So lange ein Algorithmus nicht korrumpiert werden konnte, bleibt er ungebrochen!
>>> 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")
Ein korrektes Testergebnis ist kein zufälliges Ergebnis!
Ein Zufall wäre hier genau so unwahrscheinlich, wie ein zufällig
sofort gefundener korrekter Key bei BruteForce.
>>> 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?
Du machst es Dir zu einfach.
In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht.
>>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
>>> derer (sogar) die kryptographische Qualität gesichert ist.
>>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
>>> Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
>>> Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
>>> für eine korrekte Implementation.
>>
>> äh, nein, sorry.
Aber selbstverständlich ist sie das!
Solange es sich nicht um echten Hardware-Zufall handelt.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-16 08:44 +0200 |
| Message-ID | <7qdkallp5epovosvvorqiaq8ads8ldvk73@4ax.com> |
| In reply to | #369429 |
On Tue, 15 Sep 2026 15:17:40 +0200, Helmut Schellong <var@schellong.biz> wrote: >Du machst es Dir zu einfach. >In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht. Wenn es sich wer einfach macht, dann der, welcher "Beweis" mit "Stichprobe" gleichsetzt... Und dann gibt es noch den Unterschied zwischen dem formalen Beweis der Korrektheit eines Algorithmus, und der Tauglichkeit des Algorithmus. Aber da bist du unbelehrbar, bewiesen durch wiederholte Testfälle. Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-16 13:58 +0200 |
| Message-ID | <118e08c$c8ga$1@solani.org> |
| In reply to | #369435 |
Thomas Prufer wrote on 16.09.2026 08:44: > On Tue, 15 Sep 2026 15:17:40 +0200, Helmut Schellong <var@schellong.biz> wrote: > >> Du machst es Dir zu einfach. >> In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht. > > Wenn es sich wer einfach macht, dann der, welcher "Beweis" mit "Stichprobe" > gleichsetzt... > > Und dann gibt es noch den Unterschied zwischen dem formalen Beweis der > Korrektheit eines Algorithmus, und der Tauglichkeit des Algorithmus. > > Aber da bist du unbelehrbar, bewiesen durch wiederholte Testfälle. Ich bin gar nicht unbelehrbar, sondern folge den Beweisen in der Realität. In diesem Teil-Thread wurden Aussagen von mir immer wieder mir als angeblichem Urheber angedichtet. Dabei stammen diese Aussagen von Mitgliedern von Krypto-Teams: 'dragon': ... um die Korrektheit von Implementationen feststellen zu können: The correctness of the code on different platforms is verified by generating and comparing test vectors. Essentially all of the algorithms included have been verified for correctness by independent implementation, confirming the test vectors specified. 'rabbit': https://datatracker.ietf.org/doc/html/rfc4503 A Description of the Rabbit Stream Cipher Algorithm https://datatracker.ietf.org/doc/html/rfc4503#appendix-A.1 Die Krypto-Entwickler-Teams geben (stets) ein Prüfverfahren bekannt, um die Korrektheit einer Implementation feststellen zu können: Testvektoren. Selbstverständlich ist die Korrektheit durch einen Gleichlauf BEWIESEN! -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-16 18:15 +0200 |
| Message-ID | <8lflal9japl0j7moagrpv49oju8ab2lpr4@4ax.com> |
| In reply to | #369437 |
On Wed, 16 Sep 2026 13:58:31 +0200, Helmut Schellong <var@schellong.biz> wrote:
>Thomas Prufer wrote on 16.09.2026 08:44:
>> On Tue, 15 Sep 2026 15:17:40 +0200, Helmut Schellong <var@schellong.biz> wrote:
>>
>>> Du machst es Dir zu einfach.
>>> In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht.
>>
>> Wenn es sich wer einfach macht, dann der, welcher "Beweis" mit "Stichprobe"
>> gleichsetzt...
>>
>> Und dann gibt es noch den Unterschied zwischen dem formalen Beweis der
>> Korrektheit eines Algorithmus, und der Tauglichkeit des Algorithmus.
>>
>> Aber da bist du unbelehrbar, bewiesen durch wiederholte Testfälle.
>
>Ich bin gar nicht unbelehrbar, sondern folge den Beweisen in der Realität.
>
>In diesem Teil-Thread wurden Aussagen von mir immer wieder mir
>als angeblichem Urheber angedichtet.
>Dabei stammen diese Aussagen von Mitgliedern von Krypto-Teams:
>
>'dragon':
>... um die Korrektheit von Implementationen feststellen zu können:
>The correctness of the code on different platforms is verified by generating and comparing test vectors.
>Essentially all of the algorithms included have been verified for correctness by independent implementation,
>confirming the test vectors specified.
>
>'rabbit':
>
>https://datatracker.ietf.org/doc/html/rfc4503
>
>A Description of the Rabbit Stream Cipher Algorithm
>
>https://datatracker.ietf.org/doc/html/rfc4503#appendix-A.1
>
>Die Krypto-Entwickler-Teams geben (stets) ein Prüfverfahren bekannt, um die
>Korrektheit einer Implementation feststellen zu können: Testvektoren.
>
>Selbstverständlich ist die Korrektheit durch einen Gleichlauf BEWIESEN!
Nein.
Claude Haiku 4.5:
Are the test vectors in rfc 4503 sufficient to prove that a Rabbit Stream Cipher
Algorithm implementation is correct?
Based on RFC 4503, the test vectors are useful for conformance testing but not
necessarily sufficient for comprehensive correctness proof.
What RFC 4503 Provides
The RFC includes two types of test data:
Type Content Purpose
Appendix A: Test Vectors 3 keys without IV setup, 3 IVs
with same key; each produces 3 output blocks (48 bytes) Conformance testing of
cipher output
Appendix B: Debugging Vectors Inner state snapshots after key expansion, after
each iteration, and after IV expansion Debugging intermediate states and
tracing the algorithm
Limitations for Proof of Correctness
The test vectors are insufficient alone because:
Limited coverage — Only a handful of keys and IVs are tested (6 total
scenarios), representing a minuscule fraction of the 2¹²8 possible keys and 264
possible IVs.
Small sample size — Each scenario produces only 3 output blocks (48 bytes).
A single bug could coincidentally produce correct output for these specific
inputs while failing on others.
Stated purpose — RFC 4503 explicitly describes them as "a set of test
vectors for conformance testing," not comprehensive proof of correctness.
No edge case coverage — The vectors don't systematically test boundary
conditions, state transitions, or algorithmic corner cases.
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-16 23:38 +0200 |
| Message-ID | <118f27u$aods$1@solani.org> |
| In reply to | #369438 |
Thomas Prufer wrote on 16.09.2026 18:15: > On Wed, 16 Sep 2026 13:58:31 +0200, Helmut Schellong <var@schellong.biz> wrote: > >> Thomas Prufer wrote on 16.09.2026 08:44: >>> On Tue, 15 Sep 2026 15:17:40 +0200, Helmut Schellong <var@schellong.biz> wrote: >>> >>>> Du machst es Dir zu einfach. >>>> In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht. >>> >>> Wenn es sich wer einfach macht, dann der, welcher "Beweis" mit "Stichprobe" >>> gleichsetzt... >>> >>> Und dann gibt es noch den Unterschied zwischen dem formalen Beweis der >>> Korrektheit eines Algorithmus, und der Tauglichkeit des Algorithmus. >>> >>> Aber da bist du unbelehrbar, bewiesen durch wiederholte Testfälle. >> >> Ich bin gar nicht unbelehrbar, sondern folge den Beweisen in der Realität. >> >> In diesem Teil-Thread wurden Aussagen von mir immer wieder mir >> als angeblichem Urheber angedichtet. >> Dabei stammen diese Aussagen von Mitgliedern von Krypto-Teams: >> >> 'dragon': >> ... um die Korrektheit von Implementationen feststellen zu können: >> The correctness of the code on different platforms is verified by generating and comparing test vectors. >> Essentially all of the algorithms included have been verified for correctness by independent implementation, >> confirming the test vectors specified. >> >> 'rabbit': >> >> https://datatracker.ietf.org/doc/html/rfc4503 >> >> A Description of the Rabbit Stream Cipher Algorithm >> >> https://datatracker.ietf.org/doc/html/rfc4503#appendix-A.1 >> >> Die Krypto-Entwickler-Teams geben (stets) ein Prüfverfahren bekannt, um die >> Korrektheit einer Implementation feststellen zu können: Testvektoren. >> >> Selbstverständlich ist die Korrektheit durch einen Gleichlauf BEWIESEN! > > Nein. > > Claude Haiku 4.5: > > Are the test vectors in rfc 4503 sufficient to prove that a Rabbit Stream Cipher > Algorithm implementation is correct? > > Based on RFC 4503, the test vectors are useful for conformance testing but not > necessarily sufficient for comprehensive correctness proof. > > What RFC 4503 Provides > > The RFC includes two types of test data: > Type Content Purpose > Appendix A: Test Vectors 3 keys without IV setup, 3 IVs > with same key; each produces 3 output blocks (48 bytes) Conformance testing of > cipher output > Appendix B: Debugging Vectors Inner state snapshots after key expansion, after > each iteration, and after IV expansion Debugging intermediate states and > tracing the algorithm > > Limitations for Proof of Correctness > > The test vectors are insufficient alone because: > > Limited coverage — Only a handful of keys and IVs are tested (6 total > scenarios), representing a minuscule fraction of the 2¹²8 possible keys and 264 > possible IVs. > > Small sample size — Each scenario produces only 3 output blocks (48 bytes). > A single bug could coincidentally produce correct output for these specific > inputs while failing on others. > > Stated purpose — RFC 4503 explicitly describes them as "a set of test > vectors for conformance testing," not comprehensive proof of correctness. > > No edge case coverage — The vectors don't systematically test boundary > conditions, state transitions, or algorithmic corner cases. Ich widerspreche Claude Haiku ganz klar. Er spekuliert ja auch nur - theoretisch. Die Testvektoren sind jeweils die _allerersten_ Bytes, die vom Generator ausgegeben werden. Dabei kann der Rabbit-Generator 2^68 Bytes ausgeben, bevor die Qualität sinkt. Jeder unterschiedliche Key erzeugt einen vollkommen anderen Byte-Strom. Mit gleichem Key ist der Strom stets der gleiche - garantiert, von Byte 0 bis Byte 2^68-1. Andernfalls könnte nicht entschlüsselt werden! Der Algorithmus ist ein deterministischer Algorithmus, da er nur _elementare_ Integer-Operationen verwendet, zumeist bitweise Operationen. Die Sensitivität ist von den Hash-Generatoren bekannt. Jedes einzelne geänderte Bit in der Eingabe verändert den Hash komplett. So ist das auch beim Rabbit-Code der Fall. Ich sehe das im Rabbit-Code deutlich. Jede semantische Code-Veränderung wirkt etwa so, als ob ein anderer Key verwendet wird. http://www.schellong.de/htm/rabbit_kern.c.html z.B. in den Zeilen 35, 36 -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-17 08:41 +0200 |
| Message-ID | <mb2nalppo8ru8cj5cqhjh0slj7e9ec0kv2@4ax.com> |
| In reply to | #369439 |
On Wed, 16 Sep 2026 23:38:36 +0200, Helmut Schellong <var@schellong.biz> wrote: >Thomas Prufer wrote on 16.09.2026 18:15: >> On Wed, 16 Sep 2026 13:58:31 +0200, Helmut Schellong <var@schellong.biz> wrote: >> >>> Thomas Prufer wrote on 16.09.2026 08:44: >>>> On Tue, 15 Sep 2026 15:17:40 +0200, Helmut Schellong <var@schellong.biz> wrote: >>>> >>>>> Du machst es Dir zu einfach. >>>>> In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht. >>>> >>>> Wenn es sich wer einfach macht, dann der, welcher "Beweis" mit "Stichprobe" >>>> gleichsetzt... >>>> >>>> Und dann gibt es noch den Unterschied zwischen dem formalen Beweis der >>>> Korrektheit eines Algorithmus, und der Tauglichkeit des Algorithmus. >>>> >>>> Aber da bist du unbelehrbar, bewiesen durch wiederholte Testfälle. >>> >>> Ich bin gar nicht unbelehrbar, sondern folge den Beweisen in der Realität. >>> >>> In diesem Teil-Thread wurden Aussagen von mir immer wieder mir >>> als angeblichem Urheber angedichtet. >>> Dabei stammen diese Aussagen von Mitgliedern von Krypto-Teams: >>> >>> 'dragon': >>> ... um die Korrektheit von Implementationen feststellen zu können: >>> The correctness of the code on different platforms is verified by generating and comparing test vectors. >>> Essentially all of the algorithms included have been verified for correctness by independent implementation, >>> confirming the test vectors specified. >>> >>> 'rabbit': >>> >>> https://datatracker.ietf.org/doc/html/rfc4503 >>> >>> A Description of the Rabbit Stream Cipher Algorithm >>> >>> https://datatracker.ietf.org/doc/html/rfc4503#appendix-A.1 >>> >>> Die Krypto-Entwickler-Teams geben (stets) ein Prüfverfahren bekannt, um die >>> Korrektheit einer Implementation feststellen zu können: Testvektoren. >>> >>> Selbstverständlich ist die Korrektheit durch einen Gleichlauf BEWIESEN! >> >> Nein. >> >> Claude Haiku 4.5: >> >> Are the test vectors in rfc 4503 sufficient to prove that a Rabbit Stream Cipher >> Algorithm implementation is correct? >> >> Based on RFC 4503, the test vectors are useful for conformance testing but not >> necessarily sufficient for comprehensive correctness proof. >> >> What RFC 4503 Provides >> >> The RFC includes two types of test data: >> Type Content Purpose >> Appendix A: Test Vectors 3 keys without IV setup, 3 IVs >> with same key; each produces 3 output blocks (48 bytes) Conformance testing of >> cipher output >> Appendix B: Debugging Vectors Inner state snapshots after key expansion, after >> each iteration, and after IV expansion Debugging intermediate states and >> tracing the algorithm >> >> Limitations for Proof of Correctness >> >> The test vectors are insufficient alone because: >> >> Limited coverage — Only a handful of keys and IVs are tested (6 total >> scenarios), representing a minuscule fraction of the 2¹²8 possible keys and 264 >> possible IVs. >> >> Small sample size — Each scenario produces only 3 output blocks (48 bytes). >> A single bug could coincidentally produce correct output for these specific >> inputs while failing on others. >> >> Stated purpose — RFC 4503 explicitly describes them as "a set of test >> vectors for conformance testing," not comprehensive proof of correctness. >> >> No edge case coverage — The vectors don't systematically test boundary >> conditions, state transitions, or algorithmic corner cases. > >Ich widerspreche Claude Haiku ganz klar. >Er spekuliert ja auch nur - theoretisch. > >Die Testvektoren sind jeweils die _allerersten_ Bytes, die vom Generator ausgegeben werden. >Dabei kann der Rabbit-Generator 2^68 Bytes ausgeben, bevor die Qualität sinkt. > >Jeder unterschiedliche Key erzeugt einen vollkommen anderen Byte-Strom. >Mit gleichem Key ist der Strom stets der gleiche - garantiert, von Byte 0 bis Byte 2^68-1. >Andernfalls könnte nicht entschlüsselt werden! > >Der Algorithmus ist ein deterministischer Algorithmus, da er nur _elementare_ >Integer-Operationen verwendet, zumeist bitweise Operationen. > >Die Sensitivität ist von den Hash-Generatoren bekannt. >Jedes einzelne geänderte Bit in der Eingabe verändert den Hash komplett. > >So ist das auch beim Rabbit-Code der Fall. >Ich sehe das im Rabbit-Code deutlich. >Jede semantische Code-Veränderung wirkt etwa so, als ob ein anderer Key verwendet wird. > >http://www.schellong.de/htm/rabbit_kern.c.html z.B. in den Zeilen 35, 36 Claude zitiert RFC 4503: >> Stated purpose — RFC 4503 explicitly describes them as "a set of test >> vectors for conformance testing," not comprehensive proof of correctness. Und was du im Code siehst ist für einen Beweis unerheblich. Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-17 15:07 +0200 |
| Message-ID | <118golk$e7dd$1@solani.org> |
| In reply to | #369441 |
Thomas Prufer wrote on 17.09.2026 08:41: > On Wed, 16 Sep 2026 23:38:36 +0200, Helmut Schellong <var@schellong.biz> wrote: > >> Thomas Prufer wrote on 16.09.2026 18:15: >>> On Wed, 16 Sep 2026 13:58:31 +0200, Helmut Schellong <var@schellong.biz> wrote: >>> >>>> Thomas Prufer wrote on 16.09.2026 08:44: >>>>> On Tue, 15 Sep 2026 15:17:40 +0200, Helmut Schellong <var@schellong.biz> wrote: >>>>> >>>>>> Du machst es Dir zu einfach. >>>>>> In der Theorie ist ja alles so einfach - in der konkreten Realität jedoch nicht. >>>>> >>>>> Wenn es sich wer einfach macht, dann der, welcher "Beweis" mit "Stichprobe" >>>>> gleichsetzt... >>>>> >>>>> Und dann gibt es noch den Unterschied zwischen dem formalen Beweis der >>>>> Korrektheit eines Algorithmus, und der Tauglichkeit des Algorithmus. >>>>> >>>>> Aber da bist du unbelehrbar, bewiesen durch wiederholte Testfälle. >>>> >>>> Ich bin gar nicht unbelehrbar, sondern folge den Beweisen in der Realität. >>>> >>>> In diesem Teil-Thread wurden Aussagen von mir immer wieder mir >>>> als angeblichem Urheber angedichtet. >>>> Dabei stammen diese Aussagen von Mitgliedern von Krypto-Teams: >>>> >>>> 'dragon': >>>> ... um die Korrektheit von Implementationen feststellen zu können: >>>> The correctness of the code on different platforms is verified by generating and comparing test vectors. >>>> Essentially all of the algorithms included have been verified for correctness by independent implementation, >>>> confirming the test vectors specified. >>>> >>>> 'rabbit': >>>> >>>> https://datatracker.ietf.org/doc/html/rfc4503 >>>> >>>> A Description of the Rabbit Stream Cipher Algorithm >>>> >>>> https://datatracker.ietf.org/doc/html/rfc4503#appendix-A.1 >>>> >>>> Die Krypto-Entwickler-Teams geben (stets) ein Prüfverfahren bekannt, um die >>>> Korrektheit einer Implementation feststellen zu können: Testvektoren. >>>> >>>> Selbstverständlich ist die Korrektheit durch einen Gleichlauf BEWIESEN! >>> >>> Nein. >>> >>> Claude Haiku 4.5: >>> >>> Are the test vectors in rfc 4503 sufficient to prove that a Rabbit Stream Cipher >>> Algorithm implementation is correct? >>> >>> Based on RFC 4503, the test vectors are useful for conformance testing but not >>> necessarily sufficient for comprehensive correctness proof. >>> >>> What RFC 4503 Provides >>> >>> The RFC includes two types of test data: >>> Type Content Purpose >>> Appendix A: Test Vectors 3 keys without IV setup, 3 IVs >>> with same key; each produces 3 output blocks (48 bytes) Conformance testing of >>> cipher output >>> Appendix B: Debugging Vectors Inner state snapshots after key expansion, after >>> each iteration, and after IV expansion Debugging intermediate states and >>> tracing the algorithm >>> >>> Limitations for Proof of Correctness >>> >>> The test vectors are insufficient alone because: >>> >>> Limited coverage — Only a handful of keys and IVs are tested (6 total >>> scenarios), representing a minuscule fraction of the 2¹²8 possible keys and 264 >>> possible IVs. >>> >>> Small sample size — Each scenario produces only 3 output blocks (48 bytes). >>> A single bug could coincidentally produce correct output for these specific >>> inputs while failing on others. >>> >>> Stated purpose — RFC 4503 explicitly describes them as "a set of test >>> vectors for conformance testing," not comprehensive proof of correctness. >>> >>> No edge case coverage — The vectors don't systematically test boundary >>> conditions, state transitions, or algorithmic corner cases. >> >> Ich widerspreche Claude Haiku ganz klar. >> Er spekuliert ja auch nur - theoretisch. >> >> Die Testvektoren sind jeweils die _allerersten_ Bytes, die vom Generator ausgegeben werden. >> Dabei kann der Rabbit-Generator 2^68 Bytes ausgeben, bevor die Qualität sinkt. >> >> Jeder unterschiedliche Key erzeugt einen vollkommen anderen Byte-Strom. >> Mit gleichem Key ist der Strom stets der gleiche - garantiert, von Byte 0 bis Byte 2^68-1. >> Andernfalls könnte nicht entschlüsselt werden! >> >> Der Algorithmus ist ein deterministischer Algorithmus, da er nur _elementare_ >> Integer-Operationen verwendet, zumeist bitweise Operationen. >> >> Die Sensitivität ist von den Hash-Generatoren bekannt. >> Jedes einzelne geänderte Bit in der Eingabe verändert den Hash komplett. >> >> So ist das auch beim Rabbit-Code der Fall. >> Ich sehe das im Rabbit-Code deutlich. >> Jede semantische Code-Veränderung wirkt etwa so, als ob ein anderer Key verwendet wird. >> >> http://www.schellong.de/htm/rabbit_kern.c.html z.B. in den Zeilen 35, 36 > > > > > Claude zitiert RFC 4503: > >>> Stated purpose — RFC 4503 explicitly describes them as "a set of test >>> vectors for conformance testing," not comprehensive proof of correctness. 'conformance' bedeutet: Übereinstimmung, Erfüllung. Eine Korrektheit zu verlangen, ist hier als semantisch gleich anzusehen. > Und was du im Code siehst ist für einen Beweis unerheblich. In Wirklichkeit ist genau DAS das Wichtigste. Als ich den 'dragon'-Algorithmus sah, erkannte ich sofort die beiden großen konstanten Arrays und deren Verwendung im Zentrum des Code. Da wußte ich, daß 'dragon' wohl besser als 'rabbit' sein wird. Genau so ist es: 'dragon' zeigt im NIST-Test ein erkennbar besseres Bild. Die Kern-Operation in 'rabbit' ist nicht so stark wie die in 'dragon'. 49 ü 6= 13.983.816 256 ü 6= 368.532.802.176 256 ü 8= 409.663.695.276.000 Vorstehend wird ein Eindruck vermittelt, wie extrem stark Änderungen die Wahrscheinlichkeiten verändern. Krypto-Algorithmen besitzen eine enorme exponentielle Empfindlichkeit. Claude Haiku scheint nicht viel darüber zu wissen - wohl ein Theoretiker. Ich hatte 2020/21 untersucht, wie viele Übereinstimmungen ich in 100 MB Random-Daten finde. Gesucht hatte ich nach 2, 3, 4, 6 Byte langen übereinstimmenden Folgen. Ich meine, bereits zwei oder mehr Folgen aus 6 Byte waren in den Daten gar nicht enthalten! Jedoch die Test-Vektoren, die Haiku als ungenügend erklärt, haben eine Länge von 2×128 Byte! Ich kann mich seiner Einschätzung überhaupt nicht anschließen, daß ein _nicht_ semantisch übereinstimmender Code auch nur 128 Byte der Test-Vektoren wiedergeben könnte. Wie professionelle Kryptographen-Teams arbeiten: =============================================================================================================== In der Kryptographie sind Konzentration und Diffusion zwei fundamentale Prinzipien, die von Claude Shannon im Jahr 1949 eingeführt wurden, um die Sicherheit von Verschlüsselungsverfahren (insbesondere symmetrischen Blockchiffren wie AES) zu gewährleisten. Sie dienen dazu, statistische Muster im Geheimtext zu zerstören, damit Angreifer keine Rückschlüsse auf den Klartext oder den Schlüssel ziehen können. Hier ist die genaue Bedeutung der beiden Begriffe im direkten Vergleich: Konzept * Hauptziel * Typische Umsetzung * Funktionsweise Konzentration (Confusion) Zusammenhang zwischen Schlüssel und Geheimtext so komplex wie möglich machen. Substitution (Ersetzung von Zeichen/Bits durch andere, z. B. über S-Boxen). Wenn sich ein Bit des Schlüssels ändert, ändert sich der gesamte Geheimtext völlig unvorhersehbar. Diffusion (Diffusion) Statistische Strukturen des Klartexts über den gesamten Geheimtext verstreuen. Permutation / Transposition (Vertauschen, Durchmischen oder Lineartransformationen). Wenn sich ein einzelnes Bit im Klartext ändert, ändert sich (idealwerweise) etwa die Hälfte aller Bits im Geheimtext (Lawineneffekt). -------------------------------------------------------------------------------------------------------------- Moderne Verschlüsselungsverfahren nutzen sogenannte Substitutions-Permutations-Netzwerke (SPN). Dabei werden Konzentration und Diffusion in mehreren Runden hintereinander ausgeführt: Runden-Schlüssel addieren: Der geheime Schlüssel wird eingebracht. Substitution (Konzentration): Bits werden durch eine S-Box ersetzt. Das bricht lineare Zusammenhänge auf. Permutation (Diffusion): Die ersetzten Bits werden wild im Block hin- und hergeschoben, damit sich die Änderung in der nächsten Runde auf viele andere S-Boxen verteilt. Durch das mehrmalige Wiederholen dieser Runden wird der Geheimtext so stark "durchgemischt", dass er von zufälligem Rauschen nicht mehr zu unterscheiden ist. =============================================================================================================== -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-18 09:02 +0200 |
| Message-ID | <m0opalph44edf571djf6dp1d0dnimn3c6s@4ax.com> |
| In reply to | #369445 |
On Thu, 17 Sep 2026 15:07:01 +0200, Helmut Schellong <var@schellong.biz> wrote: >> Claude zitiert RFC 4503: >> >>>> Stated purpose — RFC 4503 explicitly describes them as "a set of test >>>> vectors for conformance testing," not comprehensive proof of correctness. > >'conformance' bedeutet: Übereinstimmung, Erfüllung. >Eine Korrektheit zu verlangen, ist hier als semantisch gleich anzusehen. > ... denn du bist Muttersprachler in Englisch, oder so? Da folgen weitere Testvektoren zum debuggen -- die bräuchte es meinem laienhaften Verständnis nach nicht, wenn die Testvektoren die Korrektheit mathematisch beweisen würden. >> Und was du im Code siehst ist für einen Beweis unerheblich. > >In Wirklichkeit ist genau DAS das Wichtigste. > >Als ich den 'dragon'-Algorithmus sah, erkannte ich sofort die beiden großen >konstanten Arrays und deren Verwendung im Zentrum des Code. > >Da wußte ich, daß 'dragon' wohl besser als 'rabbit' sein wird. Du siehst am Array die Stärke der Verschlüsselung? Und vielleicht deren Knackbarkeit, und am Enden die Korrektheit der Implementation auch noch? "Chuck" Schellong ist wohl doch keine Übertreibung. Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-18 11:03 +0200 |
| Message-ID | <118iupb$dbii$1@solani.org> |
| In reply to | #369459 |
Thomas Prufer wrote on 18.09.2026 09:02: > On Thu, 17 Sep 2026 15:07:01 +0200, Helmut Schellong <var@schellong.biz> wrote: > > >>> Claude zitiert RFC 4503: >>> >>>>> Stated purpose — RFC 4503 explicitly describes them as "a set of test >>>>> vectors for conformance testing," not comprehensive proof of correctness. >> >> 'conformance' bedeutet: Übereinstimmung, Erfüllung. >> Eine Korrektheit zu verlangen, ist hier als semantisch gleich anzusehen. >> > > ... denn du bist Muttersprachler in Englisch, oder so? Nicht nötig - ich habe auf einem Sprachen-Portal nachgeschaut. > Da folgen weitere Testvektoren zum debuggen -- die bräuchte es meinem > laienhaften Verständnis nach nicht, wenn die Testvektoren die Korrektheit > mathematisch beweisen würden. Die Testvektoren sind beweiskräftig - es sind deterministische Algorithmen. >>> Und was du im Code siehst ist für einen Beweis unerheblich. >> >> In Wirklichkeit ist genau DAS das Wichtigste. >> >> Als ich den 'dragon'-Algorithmus sah, erkannte ich sofort die beiden großen >> konstanten Arrays und deren Verwendung im Zentrum des Code. >> >> Da wußte ich, daß 'dragon' wohl besser als 'rabbit' sein wird. > > Du siehst am Array die Stärke der Verschlüsselung? Ja, durchaus auch das. Aber ich meine deren Verwendung, wie sie einbezogen werden, wie ich schrieb: . "deren Verwendung im Zentrum des Code" Die konstanten Arrays sind übrigens keine S-Boxen, wie es im Netz behauptet wird. > Und vielleicht deren Knackbarkeit, und am Enden die Korrektheit der > Implementation auch noch? Dragon hat 256 Bits für Key wie auch für IV. Der ist eh unknackbar. > "Chuck" Schellong ist wohl doch keine Übertreibung. Richtig. Ich arbeitete im Berufsleben als Entwicklungsingenieur und beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - das ist mein Metier. Deshalb 'sehe' ich vieles innerhalb von Sekunden. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-09-18 12:26 +0200 |
| Message-ID | <ka4qal5n7m0v2qu9fp78aega4f883eehag@4ax.com> |
| In reply to | #369461 |
On Fri, 18 Sep 2026 11:03:44 +0200, Helmut Schellong <var@schellong.biz> wrote: >Die Testvektoren sind beweiskräftig - es sind deterministische Algorithmen. Von theoretischer Informatik hast du keine Ahnung. >Ich arbeitete im Berufsleben als Entwicklungsingenieur und beherrsche etwa >20 Programmiersprachen mehr oder weniger gut - das ist mein Metier. >Deshalb 'sehe' ich vieles innerhalb von Sekunden. Aha. An dir ist ein Kryptanalytiker verloren gegangen? Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-18 11:07 +0200 |
| Message-ID | <slrn11apvr6.3iukp.als@frodo.angband.thangorodrim.de> |
| In reply to | #369459 |
Thomas Prufer <prufer.public@mnet-online.de.invalid> wrote: > On Thu, 17 Sep 2026 15:07:01 +0200, Helmut Schellong <var@schellong.biz> wrote: > > >>> Claude zitiert RFC 4503: >>> >>>>> Stated purpose — RFC 4503 explicitly describes them as "a set of test >>>>> vectors for conformance testing," not comprehensive proof of correctness. >> >>'conformance' bedeutet: Übereinstimmung, Erfüllung. >>Eine Korrektheit zu verlangen, ist hier als semantisch gleich anzusehen. >> > > ... denn du bist Muttersprachler in Englisch, oder so? Offensichtlich nicht und das merkt man ;-) Zumal die schellongisierte "Übersetzung" direkt dem zitierten Originaltext widerspricht. > Da folgen weitere Testvektoren zum debuggen -- die bräuchte es meinem > laienhaften Verständnis nach nicht, wenn die Testvektoren die Korrektheit > mathematisch beweisen würden. > > >>> Und was du im Code siehst ist für einen Beweis unerheblich. >> >>In Wirklichkeit ist genau DAS das Wichtigste. >> >>Als ich den 'dragon'-Algorithmus sah, erkannte ich sofort die beiden großen >>konstanten Arrays und deren Verwendung im Zentrum des Code. >> >>Da wußte ich, daß 'dragon' wohl besser als 'rabbit' sein wird. > > Du siehst am Array die Stärke der Verschlüsselung? > > Und vielleicht deren Knackbarkeit, und am Enden die Korrektheit der > Implementation auch noch? > > "Chuck" Schellong ist wohl doch keine Übertreibung. Tja, wo sich andere mühsam mit mathematisch aufwendiger Kryptoanalysis rumplagen müssen, sieht Helmut "Chuck" Schellong schon auf den ersten Blick die Qualität der Verschlüsselung. Unser Held! SCNR, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-18 11:41 +0200 |
| Message-ID | <118j109$dd73$1@solani.org> |
| In reply to | #369462 |
Alexander Schreiber wrote on 18.09.2026 11:07: > Thomas Prufer <prufer.public@mnet-online.de.invalid> wrote: >> On Thu, 17 Sep 2026 15:07:01 +0200, Helmut Schellong <var@schellong.biz> wrote: >> >> >>>> Claude zitiert RFC 4503: >>>> >>>>>> Stated purpose — RFC 4503 explicitly describes them as "a set of test >>>>>> vectors for conformance testing," not comprehensive proof of correctness. >>> >>> 'conformance' bedeutet: Übereinstimmung, Erfüllung. >>> Eine Korrektheit zu verlangen, ist hier als semantisch gleich anzusehen. >>> >> >> ... denn du bist Muttersprachler in Englisch, oder so? > > Offensichtlich nicht und das merkt man ;-) > Zumal die schellongisierte "Übersetzung" direkt dem zitierten Originaltext > widerspricht. Ich habe conformance von 'dict.leo.org' übersetzen lassen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-18 22:12 +0200 |
| Message-ID | <slrn11ar6q5.3dk3v.als@mordor.angband.thangorodrim.de> |
| In reply to | #369464 |
Helmut Schellong <var@schellong.biz> wrote:
> Alexander Schreiber wrote on 18.09.2026 11:07:
>> Thomas Prufer <prufer.public@mnet-online.de.invalid> wrote:
>>> On Thu, 17 Sep 2026 15:07:01 +0200, Helmut Schellong <var@schellong.biz> wrote:
>>>
>>>
>>>>> Claude zitiert RFC 4503:
>>>>>
>>>>>>> Stated purpose — RFC 4503 explicitly describes them as "a set of test
>>>>>>> vectors for conformance testing," not comprehensive proof of correctness.
>>>>
>>>> 'conformance' bedeutet: Übereinstimmung, Erfüllung.
>>>> Eine Korrektheit zu verlangen, ist hier als semantisch gleich anzusehen.
>>>>
>>>
>>> ... denn du bist Muttersprachler in Englisch, oder so?
>>
>> Offensichtlich nicht und das merkt man ;-)
>> Zumal die schellongisierte "Übersetzung" direkt dem zitierten Originaltext
>> widerspricht.
>
> Ich habe conformance von 'dict.leo.org' übersetzen lassen.
Du schuldest mir eine Tischkante, schon wieder.
Immerhin bietet leo da mehrere Varianten an, weil die korrekte Übersetzung
auch durchaus vom Kontext abhängt. Hier wäre eher "Konformität" im Sinne
von "erfüllt grundlegende Anforderungen" passender als "Übereinstimmung",
letzteres ist schlichtweg falsch. Ein Wörterbuch (und mehr ist leo nicht)
ist halt ohne hinreichende Kenntnis der Sprache nur sehr begrenzt hilfreich.
Das, was Google translate da ausspuckt, passt schon eher:
"Ausgewiesener Zweck – RFC 4503 beschreibt sie ausdrücklich als „eine
Menge von Testvektoren für Konformitätstests“, nicht als umfassenden
Korrektheitsnachweis."
Aber besser als sich auf Wörterbücher/Übersetzungsdienste zu verlassen
ist es, die Sprache zu können. Und nebenbei: Die RFCs sind sehr bewusst
formuliert und RFC2119 existiert aus Gründen.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | de.sci.electronics
csiph-web