Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #369613 > unrolled thread
| Started by | Helmut Schellong <var@schellong.biz> |
|---|---|
| First post | 2026-09-29 13:06 +0200 |
| Last post | 2026-09-29 18:46 +0200 |
| Articles | 20 on this page of 190 — 21 participants |
Back to article view | Back to de.sci.electronics
random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 13:06 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 15:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 18:37 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 21:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 22:41 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 22:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 00:26 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 02:05 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 10:45 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 10:57 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:33 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-30 15:31 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 16:25 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-30 17:17 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-04 02:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 11:58 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:31 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:46 +0200
Re: random_rdtsc und random_rdrand Heinz Schmitz <sch@example.invalid> - 2026-10-05 13:17 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 14:18 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-05 14:57 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 15:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 18:44 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 11:40 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-30 01:23 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 10:19 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 05:16 +0200
Re: random_rdtsc und random_rdrand Marte Schwarz <marte.schwarz@gmx.de> - 2026-09-30 08:01 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 08:11 +0200
Re: random_rdtsc und random_rdrand Andreas Fecht <forum@aftec.de> - 2026-09-30 09:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 09:55 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:23 +0200
Re: random_rdtsc und random_rdrand Michael Schwingen <news-1513678000@discworld.dascon.de> - 2026-09-30 14:48 +0000
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 17:17 +0200
Re: random_rdtsc und random_rdrand Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-09-30 09:59 +0200
Re: random_rdtsc und random_rdrand Eric Bruecklmeier <u@5i7.de> - 2026-09-30 09:13 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:07 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:03 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 16:58 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 17:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 18:34 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 18:12 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 18:25 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 19:16 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 18:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 19:25 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 20:10 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 20:49 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 20:55 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 20:55 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 23:32 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-01 00:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-01 18:35 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-01 18:58 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 06:29 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 16:02 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 16:11 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 22:00 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 22:02 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 22:09 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 22:20 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 23:11 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 23:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 11:57 +0200
Re: random_rdtsc und random_rdrand Marte Schwarz <marte.schwarz@gmx.de> - 2026-10-03 11:30 +0200
Re: random_rdtsc und random_rdrand Heinz Schmitz <sch@example.invalid> - 2026-10-03 16:59 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:29 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-03 13:33 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-02 16:19 +0200
Re: random_rdtsc und random_rdrand Christian Weisgerber <naddy@mips.inka.de> - 2026-10-02 19:24 +0000
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-02 22:04 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-03 14:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 15:21 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:26 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 17:35 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 00:48 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 00:52 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 01:33 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 02:04 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 11:48 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 11:56 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:41 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 12:20 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 12:46 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 17:39 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:48 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:12 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 17:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 00:59 +0200
Re: random_rdtsc und random_rdrand Kai-Martin Knaak <kaimartin@invalid.invalid> - 2026-10-04 22:49 +0000
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:32 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:36 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:52 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 13:24 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 14:30 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 15:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 18:51 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-05 19:39 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-05 21:40 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-06 02:39 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-06 09:54 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 11:44 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-06 09:38 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 11:41 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-06 14:13 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-06 16:37 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-06 22:29 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-07 20:50 +0200
Re: random_rdtsc und random_rdrand Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-10-08 09:07 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-08 10:15 +0200
Re: random_rdtsc und random_rdrand Eric Bruecklmeier <u@5i7.de> - 2026-10-08 11:18 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-09 12:36 +0200
Re: random_rdtsc und random_rdrand Andreas Fecht <forum@aftec.de> - 2026-10-09 14:19 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-09 17:05 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-09 21:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-09 22:36 +0200
Re: random_rdtsc und random_rdrand Heinz Schmitz <sch@example.invalid> - 2026-10-10 10:48 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-10 11:47 +0200
Re: random_rdtsc und random_rdrand Eric Bruecklmeier <u@5i7.de> - 2026-10-10 13:41 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-09 21:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-09 22:49 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-09 21:40 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-09 22:20 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-14 12:44 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-14 23:30 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-15 08:30 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-15 09:55 +0200
Re: random_rdtsc und random_rdrand Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-10-15 13:28 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-15 14:57 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-15 17:10 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-15 17:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 02:47 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-15 18:24 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-15 23:10 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 03:03 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-16 18:12 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 20:15 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-16 21:08 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 23:19 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-16 23:42 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-17 21:02 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-17 11:16 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-17 22:31 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-18 12:23 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-18 13:02 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-19 17:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-19 19:30 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-20 01:01 +0200
Re: random_rdtsc und random_rdrand Volker Bartheld <news2026@bartheld.net> - 2026-10-18 13:11 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-18 19:03 +0200
Re: random_rdtsc und random_rdrand Volker Bartheld <news2026@bartheld.net> - 2026-10-18 19:13 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-17 21:44 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-15 17:45 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-15 23:17 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 02:40 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-16 12:38 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 17:14 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-16 18:29 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 21:01 +0200
Re: random_rdtsc und random_rdrand Stefan Reuther <stefan.news@arcor.de> - 2026-10-16 18:22 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-16 20:39 +0200
Re: random_rdtsc und random_rdrand Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-10-18 10:13 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-18 12:51 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-10-18 19:04 +0200
Re: random_rdtsc und random_rdrand Volker Bartheld <news2026@bartheld.net> - 2026-10-18 19:13 +0200
Re: random_rdtsc und random_rdrand Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-10-18 23:02 +0200
Re: random_rdtsc und random_rdrand Volker Bartheld <news2026@bartheld.net> - 2026-10-19 09:40 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-19 12:41 +0200
Re: random_rdtsc und random_rdrand Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-10-20 15:34 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-18 19:43 +0200
Re: random_rdtsc und random_rdrand Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-10-19 10:10 +0200
Re: random_rdtsc und random_rdrand Volker Bartheld <news2026@bartheld.net> - 2026-10-19 10:13 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-19 13:12 +0200
Re: random_rdtsc und random_rdrand Ralph Aichinger <ra@h5.or.at> - 2026-10-19 12:28 +0000
Re: random_rdtsc und random_rdrand Gerhard Hoffmann <dk4xp@arcor.de> - 2026-10-19 15:45 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-19 15:55 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-19 20:55 +0200
Re: random_rdtsc und random_rdrand Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-10-19 16:05 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-19 16:59 +0200
Re: random_rdtsc und random_rdrand Axel Berger <Spam@Berger-Odenthal.De> - 2026-10-19 17:20 +0200
Re: random_rdtsc und random_rdrand Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-10-20 12:52 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-18 13:59 +0200
Re: random_rdtsc und random_rdrand Andreas Fecht <forum@aftec.de> - 2026-10-15 10:29 +0200
Re: random_rdtsc und random_rdrand Eric Bruecklmeier <u@5i7.de> - 2026-10-15 10:44 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-05 14:58 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 21:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 15:52 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 18:46 +0200
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-16 21:01 +0200 |
| Message-ID | <11atsah$1i1al$1@solani.org> |
| In reply to | #369953 |
Stefan Reuther wrote on 16.10.2026 18:29: > Am 16.10.2026 um 17:14 schrieb Helmut Schellong: >> Marc Haber wrote on 16.10.2026 12:38: >>> Weil Du zu viel Zeit hast. Nimm Dir eine handelsübliche >>> Crypto-Library, wähle einen halbwegs anständigen Schlüssel und Dein >>> Problem ist gelöst, und zwar besser als Du es selbst je können wirst. >> >> Damit will ich mich nicht befassen, weil ich ahne, daß eine solche Library >> meine Vorstellungen nicht erfüllen wird. >> Erst einmal muß diese Software kostenlos sein, weil meine Software dies >> ist. >> Desweiteren müßte diese Software ein OTP verwenden, daß eine Qualität >> hat, wie >> die Zufallszahlen von meinem Kommando 'randtsc'. > > Nimm OpenSSL 0.9.6. Ist kostenlos und hat mit Sicherheit genug Bugs im > RNG, um den auf das Niveau von 'randtsc' zu bringen. 'randtsc' erzeugt Zahlen, die erkennbar besser getestet sind, als die von rdrand. Etwa 6-mal bisher festgestellt. randtsc: http://www.schellong.de/htm/out3.pdf >>> Und wie schützt Du dieses OTP vor Zugriff? Den musst Du genau so >>> schützen wie die schützenswerten Daten. Und backuppen! >> >> An meine Daten kommt niemand heran, das ist sicher. >> Seit etwa 1985 ist niemand an meine Daten heran gekommen, oder hat es >> nicht versucht. > > Niemand, den du bemerkt hättest, hat es probiert. > >> Die Frage ist, wer will unbedingt an meine Daten kommen? >> Ein internationales Spezialistenteam würde das schaffen. > > Ist dir die Funktion jedes Chips auf deinem Mainboard bekannt? Weißt du, > was die Management Engine treibt, wenn du nicht hinschaust? Solche Bedenken sind mir nicht unbekannt. Über die Jahre immer wieder was von gehört. Ich habe mich gefragt, was Copilot so macht, der ja den geöffneten Browser-Tab lesen kann. Zu FreeBSD habe ich jedenfalls Vertrauen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2026-10-16 18:22 +0200 |
| Message-ID | <11atq11.3ls.1@stefan.msgid.phost.de> |
| In reply to | #369940 |
Am 16.10.2026 um 02:40 schrieb Helmut Schellong: > Marc Haber wrote on 15.10.2026 17:45: >> Das ist ein Verfahren fürs Lehrbuch, das undiskutierbare, theoretische >> Vorteile hat, dafür aber operationale Nachteile in es unpraktikabel >> machender Größe hat. Auch in der geheimdienstlichen Praxis wurden >> One-Time-Pads höchstens für die Verschlüsselung kürzester Nachrichten >> verewendet. > > Jetzt rate mal, _warum_ ich diese Software entwickle? > Genau wegen der nicht idealen Handhabung von OTPs. > > Es ist für mich gar kein Problem, ein fettes OTP mit 10 GB gespeichert > zu haben. > Ich habe 2 x 18 TB Speicherplatz. Mindestens 35% davon frei. > > Das, was mich stört, ist, _immer wieder_ für _jede_ neuere Backup-Datei > eine neue OTP-Datei produzieren und diese verwahren zu müssen! Stell dir vor, mit kryptographischen Verfahren musst du nur eine ein paar Kilobyte große *.pem-Datei verwahren, und hast mindestens die gleiche Sicherheit! > Dies entfällt komplett durch Verwendung meiner Software. > Zudem kann ich diese eine große OTP ohne Schaden sogar verlieren oder > teilen! > Weil diese OTP nie direkt linear verwendet wird. > Jeder Flickenteppich daraus existiert nur einmal. Einen Cyphertext gegen eine OTP-Datei matchen und prüfen, bei welcher Position ein sinnvoller Klartext rauskommt ist Kryptoanalyse Grundkurs. Sobald du "diese eine große OTP verlierst oder teilst" kannst du davon ausgehen, dass alle deine Dateien entschlüsselt werden können (entsprechendes Interesse vorausgesetzt). >> Dass Du der Meinung bist, das einzige Verfahren zur sicheren >> Mehrfachverwendung von One-Time-Pads erfunden zu haben, woran sich die >> weltbesten Kryptografen der letzen hundert Jahre die Zähne ausgebissen >> haben, zeigt doch nur wie sehr Du dich überschätzt. >> >> Ich könnte die Wand hochgehen wenn ich solche Dinge von Dir lese. > > Ja, weil Du Dich pauschal nach der uralten Lehre richtest: "Das haben > wir schon immer so gemacht." > "Und da ist einer, der es anders machen will. Das ist aber schlecht! > Davon abraten muß man!" Nein, weil Marc eine Ausbildung in Kryptographie genossen und ein entsprechendes Abstraktionsvermögen hat, um zu erkennen, an welchen Stellen du Dinge tust, die schon vor Jahrhunderten probiert und verworfen (oder verbessert) wurden. Ich brauche kein 10 GB OTP, wenn ich mit (z.B. mit AES CTR) aus einem kleinen Schlüssel jederzeit eins generieren kann, das nach allen Maßstäben die gleichen Anforderungen erfüllt. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-16 20:39 +0200 |
| Message-ID | <11atqvu$1i03u$1@solani.org> |
| In reply to | #369955 |
Stefan Reuther wrote on 16.10.2026 18:22: > Am 16.10.2026 um 02:40 schrieb Helmut Schellong: >> Marc Haber wrote on 15.10.2026 17:45: >>> Das ist ein Verfahren fürs Lehrbuch, das undiskutierbare, theoretische >>> Vorteile hat, dafür aber operationale Nachteile in es unpraktikabel >>> machender Größe hat. Auch in der geheimdienstlichen Praxis wurden >>> One-Time-Pads höchstens für die Verschlüsselung kürzester Nachrichten >>> verewendet. >> >> Jetzt rate mal, _warum_ ich diese Software entwickle? >> Genau wegen der nicht idealen Handhabung von OTPs. >> >> Es ist für mich gar kein Problem, ein fettes OTP mit 10 GB gespeichert >> zu haben. >> Ich habe 2 x 18 TB Speicherplatz. Mindestens 35% davon frei. >> >> Das, was mich stört, ist, _immer wieder_ für _jede_ neuere Backup-Datei >> eine neue OTP-Datei produzieren und diese verwahren zu müssen! > > > Stell dir vor, mit kryptographischen Verfahren musst du nur eine ein > paar Kilobyte große *.pem-Datei verwahren, und hast mindestens die > gleiche Sicherheit! Wirklich? Gleich sicher wie ein OTP? Ich verschlüssele bisher, wie Du vorstehend schreibst. Ich wurde von Postings _hier_ angeregt, unknackbare OTP zu verwenden. Nun redet jedoch plötzlich jeder gegen OTPs. Dabei wurde hier vor Monaten herum genölt, daß PRNG leider immer wieder die gleiche Ausgabekette wiedergeben können. >> Dies entfällt komplett durch Verwendung meiner Software. >> Zudem kann ich diese eine große OTP ohne Schaden sogar verlieren oder >> teilen! >> Weil diese OTP nie direkt linear verwendet wird. >> Jeder Flickenteppich daraus existiert nur einmal. > > > Einen Cyphertext gegen eine OTP-Datei matchen und prüfen, bei welcher > Position ein sinnvoller Klartext rauskommt ist Kryptoanalyse Grundkurs. Die OTP-Datei habe ja nur ich, jedoch kein Angreifer. Außerdem verwende ich nur OTP mit exzellenter Gleichverteilung. Oder meinst Du die verschlüsselte Datei? > Sobald du "diese eine große OTP verlierst oder teilst" kannst du davon > ausgehen, dass alle deine Dateien entschlüsselt werden können > (entsprechendes Interesse vorausgesetzt). Lies erst mal meine erste Antwort an Dich, mit meiner aktuellen Beschreibung meines Flicken-Generators. >>> Dass Du der Meinung bist, das einzige Verfahren zur sicheren >>> Mehrfachverwendung von One-Time-Pads erfunden zu haben, woran sich die >>> weltbesten Kryptografen der letzen hundert Jahre die Zähne ausgebissen >>> haben, zeigt doch nur wie sehr Du dich überschätzt. >>> >>> Ich könnte die Wand hochgehen wenn ich solche Dinge von Dir lese. >> >> Ja, weil Du Dich pauschal nach der uralten Lehre richtest: "Das haben >> wir schon immer so gemacht." >> "Und da ist einer, der es anders machen will. Das ist aber schlecht! >> Davon abraten muß man!" > > > Nein, weil Marc eine Ausbildung in Kryptographie genossen und ein > entsprechendes Abstraktionsvermögen hat, um zu erkennen, an welchen > Stellen du Dinge tust, die schon vor Jahrhunderten probiert und > verworfen (oder verbessert) wurden. Mein Abstraktionsvermögen ist recht hoch - bei meinem Beruf... > Ich brauche kein 10 GB OTP, wenn ich mit (z.B. mit AES CTR) aus einem > kleinen Schlüssel jederzeit eins generieren kann, das nach allen > Maßstäben die gleichen Anforderungen erfüllt. Meine Aufgabenstellung, die ich mir gab, ist nun mal, ein OTP mehrfach verwenden zu können, wie ich schrieb. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-10-18 10:13 +0200 |
| Message-ID | <35v8dlt3or60j88j6efimv71f7fotsa13n@4ax.com> |
| In reply to | #369940 |
On Fri, 16 Oct 2026 02:40:04 +0200, Helmut Schellong <var@schellong.biz> wrote: >Marc Haber wrote on 15.10.2026 17:45: >> Helmut Schellong <var@schellong.biz> wrote: (...) >> Ich könnte die Wand hochgehen wenn ich solche Dinge von Dir lese. > >Ja, weil Du Dich pauschal nach der uralten Lehre richtest: "Das haben wir schon immer so gemacht." >"Und da ist einer, der es anders machen will. Das ist aber schlecht! Davon abraten muß man!" > >Alles, ohne irgendwelche konkrete Einwände zu meiner Software. >Ich habe in einem späteren Posting relativ ausführlich meine Software beschrieben. >Und warum ich sie für sicher halte. Wir hatten hier auch mal wen, der diverse Formen des Perpetuum mobiles propagierte, und auch sinngemäß sagte, die Vorschläge müsse man alle einzeln überprüfen und nachbauen. Denn eine pauschale Ablehnung wäre "das haben wir schon immer so gemacht", und man möge doch konkret die Fehler jeder einzelnen Maschine widerlegen. Klar ist der OTP verschleiert. Aber das ist "security through obscurity" -- der Haustürschlüssel mag auch "sicher" versteckt sein, wenn er eben nicht unter dem Blumentopf oder der Fußmatte liegt -- aber er liegt dann halt 20 cm unter der dritten Pflanze von links. Und zu sagen, "niemand denkt an die dritte Pflanze von links, deshalb ist das bewiesen sicher" ist ein Trugschluß. Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-18 12:51 +0200 |
| Message-ID | <11b28a5$1n949$1@solani.org> |
| In reply to | #369978 |
Thomas Prufer wrote on 18.10.2026 10:13: > On Fri, 16 Oct 2026 02:40:04 +0200, Helmut Schellong <var@schellong.biz> wrote: > >> Marc Haber wrote on 15.10.2026 17:45: >>> Helmut Schellong <var@schellong.biz> wrote: > (...) >>> Ich könnte die Wand hochgehen wenn ich solche Dinge von Dir lese. >> >> Ja, weil Du Dich pauschal nach der uralten Lehre richtest: "Das haben wir schon immer so gemacht." >> "Und da ist einer, der es anders machen will. Das ist aber schlecht! Davon abraten muß man!" >> >> Alles, ohne irgendwelche konkrete Einwände zu meiner Software. >> Ich habe in einem späteren Posting relativ ausführlich meine Software beschrieben. >> Und warum ich sie für sicher halte. > > > Wir hatten hier auch mal wen, der diverse Formen des Perpetuum mobiles > propagierte, und auch sinngemäß sagte, die Vorschläge müsse man alle einzeln > überprüfen und nachbauen. Denn eine pauschale Ablehnung wäre "das haben wir > schon immer so gemacht", und man möge doch konkret die Fehler jeder einzelnen > Maschine widerlegen. > > Klar ist der OTP verschleiert. Aber das ist "security through obscurity" -- der > Haustürschlüssel mag auch "sicher" versteckt sein, wenn er eben nicht unter dem > Blumentopf oder der Fußmatte liegt -- aber er liegt dann halt 20 cm unter der > dritten Pflanze von links. Und zu sagen, "niemand denkt an die dritte Pflanze > von links, deshalb ist das bewiesen sicher" ist ein Trugschluß. Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein Verfahren viele Vorteile bringt und absolut sicher ist. Diese Pads-on-the-fly, die meine Software produziert, sind angewandt unknackbar, genau so, wie OTPs in Standard-Verwendung. Das ist so, und es ist unwiderlegbar. Bisher wurde es auch nicht widerlegt. Es wird auch nie widerlegt werden. Ich finde Argumentationen mittels "security through obscurity" und ähnlich zum Kotzen. Ich mußte diesen pauschalen Spruch hier schon mehrmals lesen. Für mich ist das leeres Sprücheklopfen. Gestern wurde geschrieben, daß ich im Prinzip das Vingenere-Verfahren anwende. Dieses Verfahren müßte ja nun ebenfalls mit 'obscurity' belegt werden, wurde es aber nie. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-10-18 19:04 +0200 |
| Message-ID | <11b2u7d$1qt05$1@news1.tnib.de> |
| In reply to | #369981 |
Helmut Schellong <var@schellong.biz> wrote: >Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein Verfahren >viele Vorteile bringt und absolut sicher ist. >Diese Pads-on-the-fly, die meine Software produziert, sind angewandt unknackbar, >genau so, wie OTPs in Standard-Verwendung. Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2026@bartheld.net> |
|---|---|
| Date | 2026-10-18 19:13 +0200 |
| Message-ID | <b2174bd10da09d797410b9e0b23f0c8dad166ca0.camel@bartheld.net> |
| In reply to | #369990 |
On Sun, 2026-10-18 at 19:04 +0200, Marc Haber wrote: > Helmut Schellong <var@schellong.biz> wrote: > > Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein > > Verfahren > > viele Vorteile bringt und absolut sicher ist. > > Diese Pads-on-the-fly, die meine Software produziert, sind angewandt > > unknackbar, > > genau so, wie OTPs in Standard-Verwendung. > Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 endgültig abgeschaltet wird, käme da noch etwas Schwung in die Bude. Empfehle Chuck Schellong auch, das Projekt auf: https://crypto.stackexchange.com https://discuss.iacr.org https://www.metzdowd.com/mailman/listinfo/cryptography https://moderncrypto.org vorzutragen, die sind immer an bahnbrechenden Innovationen interessiert. Vielleicht geht sich sogar ein Talk auf dem diesjährigen 40C3 aus: https://events.ccc.de/congress/2026/infos/startpage.html , die bieten immer wieder eine Bühne für Kryptoexperten. Volker
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> |
|---|---|
| Date | 2026-10-18 23:02 +0200 |
| Message-ID | <20261018230223.3cc0fae3@Achmuehle.WOR> |
| In reply to | #369991 |
Hallo Volker, Du schriebst am Sun, 18 Oct 2026 19:13:21 +0200: > On Sun, 2026-10-18 at 19:04 +0200, Marc Haber wrote: > > Helmut Schellong <var@schellong.biz> wrote: > > > Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein > > > Verfahren > > > viele Vorteile bringt und absolut sicher ist. > > > Diese Pads-on-the-fly, die meine Software produziert, sind angewandt > > > unknackbar, > > > genau so, wie OTPs in Standard-Verwendung. > > Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. > > Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, > de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, > alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 Man könnte das auch mal endlich ganz ignorieren, weil die unendliche Geschichte von Behauptung und Gegenbehautung (oder gar -Nachweis) durch ein paar Leute, die Fehlinformationen nicht ausstehen können, halt nie zu einem Ende kommen kann. IMHO hat inzwischen aber auch der letzte Mitleser hier mitgekriegt, wer hier "die Lage peilt" und wer nicht - damit meine ich, ist "links liegen lassen" die beste Methode, um Falschinformation abzustellen. Auch, wenn die Gruppe hier dann nur noch 1/4 des jetzigen Umfangs haben wird... -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2026@bartheld.net> |
|---|---|
| Date | 2026-10-19 09:40 +0200 |
| Message-ID | <9d1b25a0e1a9f13c2189ccf3cb60122c90c03421.camel@bartheld.net> |
| In reply to | #369997 |
On Sun, 2026-10-18 at 23:02 +0200, Sieghard Schicktanz wrote: > Du schriebst am Sun, 18 Oct 2026 19:13:21 +0200: > > On Sun, 2026-10-18 at 19:04 +0200, Marc Haber wrote: > > > Helmut Schellong <var@schellong.biz> wrote: > > > > Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein > > > > Verfahren viele Vorteile bringt und absolut sicher ist. > > > > Diese Pads-on-the-fly, die meine Software produziert, sind angewandt > > > > unknackbar, genau so, wie OTPs in Standard-Verwendung. > > > Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. > > Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, > > de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, > > alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 > Man könnte das auch mal endlich ganz ignorieren Das wollte ich damit durch die Blume sagen, nachdem mein "Don't Feed the Trolls"-Schild offenbar wenig Beachtung fand. Ich kann das dringende Verlangen, Schwachsinn zu korrigieren, durchaus verstehen - aber manche Fälle sind einfach hoffnungslos: https://xkcd.com/386/ Keine Bühne für den tragikomischen Clown. Volker
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-19 12:41 +0200 |
| Message-ID | <11b4s3v$1p4jh$1@solani.org> |
| In reply to | #369997 |
Sieghard Schicktanz wrote on 18.10.2026 23:02: > Hallo Volker, > > Du schriebst am Sun, 18 Oct 2026 19:13:21 +0200: > >> On Sun, 2026-10-18 at 19:04 +0200, Marc Haber wrote: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein >>>> Verfahren >>>> viele Vorteile bringt und absolut sicher ist. >>>> Diese Pads-on-the-fly, die meine Software produziert, sind angewandt >>>> unknackbar, >>>> genau so, wie OTPs in Standard-Verwendung. >>> Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. >> >> Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, >> de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, >> alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 > > Man könnte das auch mal endlich ganz ignorieren, weil die unendliche > Geschichte von Behauptung und Gegenbehautung (oder gar -Nachweis) durch ein > paar Leute, die Fehlinformationen nicht ausstehen können, halt nie zu einem > Ende kommen kann. IMHO hat inzwischen aber auch der letzte Mitleser hier > mitgekriegt, wer hier "die Lage peilt" und wer nicht - damit meine ich, ist > "links liegen lassen" die beste Methode, um Falschinformation abzustellen. > Auch, wenn die Gruppe hier dann nur noch 1/4 des jetzigen Umfangs haben > wird... Eines wird hier vergessen: ich habe keine Falschinformation eingebracht. Ich habe mittels der Tabelle in allen Einzelheiten bewiesen, daß mein Verfahren sicher ist. Alle Anderen stellen platte Behauptungen auf, ohne irgendwelche Begründungen/Nachweise. Alle weiteren Eigenschaften sollten Allgemeinwissen sein, woran man hier aber zweifeln kann. Beispielsweise kann ein OTP fast beliebig aufgeteilt und neu zusammengesetzt werden. Dadurch bleiben die Sicherheit und Qualität des Pad praktisch unverändert. Der Inhalt eines OTP ist in höchster Qualität gleichverteilt. Dadurch ist ein Großteil der Arbeit bereits getan. Deshalb ändern sich durch Neuanordnung des Inhalts an kryptographischer Qualität und Sicherheit praktisch nichts. Das ist doch logisch und bekannt! Man darf es praktisch damit lediglich nicht übertreiben. Ich habe schon vor einiger Zeit darüber nachgedacht, daß an den Übergangsstellen der Flicken leichte Störungen der Qualität auftreten können, mit geringer Wahrscheinlichkeit. Wenn nun aber zwei Flicken mit z.B. 723442 | 237248 Byte aneinander stoßen, sind solche Effekte garantiert vernachlässigbar! Die Flicken eines Pad dürfen jedoch nicht z.B. 1 bis 3 Byte groß sein. Das ist ebenfalls sehr logisch. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2026-10-20 15:34 +0200 |
| Message-ID | <njp8uaFks07U1@mid.individual.net> |
| In reply to | #369991 |
Am 18.10.2026 um 19:13 schrieb Volker Bartheld: > Empfehle Chuck Schellong auch, das Projekt auf: > > https://crypto.stackexchange.com > https://discuss.iacr.org > https://www.metzdowd.com/mailman/listinfo/cryptography > https://moderncrypto.org Für einen Artikel in PoC||GTFO reicht es vermutlich nicht, die Editoren kippen vorher um... Bernd
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-18 19:43 +0200 |
| Message-ID | <11b30er$1nrvd$1@solani.org> |
| In reply to | #369990 |
Marc Haber wrote on 18.10.2026 19:04: > Helmut Schellong <var@schellong.biz> wrote: >> Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein Verfahren >> viele Vorteile bringt und absolut sicher ist. >> Diese Pads-on-the-fly, die meine Software produziert, sind angewandt unknackbar, >> genau so, wie OTPs in Standard-Verwendung. > > Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. Widerlege meine Aussage. Jedoch ohne platte Behauptung und nicht ohne Begründung. Das wirst Du nicht machen, weil das nicht geht. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-10-19 10:10 +0200 |
| Message-ID | <eujbdldoh3bo2a34o70kaglea12hls6fu6@4ax.com> |
| In reply to | #369993 |
On Sun, 18 Oct 2026 19:43:10 +0200, Helmut Schellong <var@schellong.biz> wrote: >Marc Haber wrote on 18.10.2026 19:04: >> Helmut Schellong <var@schellong.biz> wrote: >>> Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein Verfahren >>> viele Vorteile bringt und absolut sicher ist. >>> Diese Pads-on-the-fly, die meine Software produziert, sind angewandt unknackbar, >>> genau so, wie OTPs in Standard-Verwendung. >> >> Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. > >Widerlege meine Aussage. >Jedoch ohne platte Behauptung und nicht ohne Begründung. > >Das wirst Du nicht machen, weil das nicht geht. Ein OTP zB zu invertieren ergibt nicht ein neuen OTP, sondern erhöht die Entropie um ein Bit. Somit ist nicht mehr Sicherheit zu erwarten, als durch diese eine Bit eben gewonnen wird. Dasselbe gilt für ähnliche Transformation, Auswahlen usw. Thomas Prufer
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2026@bartheld.net> |
|---|---|
| Date | 2026-10-19 10:13 +0200 |
| Message-ID | <a0b2329d185601a91d10ec9a542cf70bf369904a.camel@bartheld.net> |
| In reply to | #369999 |
On Mon, 2026-10-19 at 10:10 +0200, Thomas Prufer wrote: > On Sun, 18 Oct 2026 19:43:10 +0200, Helmut Schellong <var@schellong.biz> > wrote: > > Marc Haber wrote on 18.10.2026 19:04: > > > Helmut Schellong <var@schellong.biz> wrote: > > > > Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein > > > > Verfahren viele Vorteile bringt und absolut sicher ist. > > > > Diese Pads-on-the-fly, die meine Software produziert, sind angewandt > > > > unknackbar, genau so, wie OTPs in Standard-Verwendung. > > > Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. > > Widerlege meine Aussage. Jedoch ohne platte Behauptung und nicht ohne > > Begründung. Das wirst Du nicht machen, weil das nicht geht. > Ein OTP zB zu invertieren ergibt nicht ein neuen OTP, sondern erhöht die > Entropie um ein Bit. Somit ist nicht mehr Sicherheit zu erwarten, als durch > diese eine Bit eben gewonnen wird. Dasselbe gilt für ähnliche Transformation, > Auswahlen usw. Könnte man das nicht per x'p/f'up in sci.crypt, de.comp.security.misc, de.sci.mathematik, sci.crypt.research, sci.crypt.random-numbers, alt.security.pgp, talk.politics.crypto diskutieren? Bevor das Usenet 2027 endgültig abgeschaltet wird, käme da noch etwas Schwung in die Bude. Empfehle Chuck Schellong auch, das Projekt auf: https://crypto.stackexchange.com https://discuss.iacr.org https://www.metzdowd.com/mailman/listinfo/cryptography https://moderncrypto.org vorzutragen, die sind immer an bahnbrechenden Innovationen interessiert. Vielleicht geht sich sogar ein Talk auf dem diesjährigen 40C3 aus: https://events.ccc.de/congress/2026/infos/startpage.html , die bieten immer wieder eine Bühne für Kryptoexperten. Volker
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-19 13:12 +0200 |
| Message-ID | <11b4ttv$1p5sr$1@solani.org> |
| In reply to | #369999 |
Thomas Prufer wrote on 19.10.2026 10:10: > On Sun, 18 Oct 2026 19:43:10 +0200, Helmut Schellong <var@schellong.biz> wrote: > >> Marc Haber wrote on 18.10.2026 19:04: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein Verfahren >>>> viele Vorteile bringt und absolut sicher ist. >>>> Diese Pads-on-the-fly, die meine Software produziert, sind angewandt unknackbar, >>>> genau so, wie OTPs in Standard-Verwendung. >>> >>> Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. >> >> Widerlege meine Aussage. >> Jedoch ohne platte Behauptung und nicht ohne Begründung. >> >> Das wirst Du nicht machen, weil das nicht geht. > > Ein OTP zB zu invertieren ergibt nicht ein neuen OTP, sondern erhöht die > Entropie um ein Bit. Somit ist nicht mehr Sicherheit zu erwarten, als durch > diese eine Bit eben gewonnen wird. Dasselbe gilt für ähnliche Transformation, > Auswahlen usw. Ich invertiere keinen OTP - das wäre viel zu einfach. Ich teile einen OTP in sehr viele Teilstücke auf und ordne diese zufällig neu an, so daß ein neuer einmaliger OTP entsteht. Dabei bleibt ein großer Teil des OTP-Inhalts per Zufall ohne Verwendung. Ein großer zufälliger Teil des Inhalts wird in der Byte-Folge umgedreht. Kryptographische Qualität und Sicherheit bleiben praktisch gleich. Aber es ist ein generierter einmaliger neuer OTP, weshalb die eine Quelle immer wieder verwendet werden kann. Aus anderem Posting: Alle weiteren Eigenschaften sollten Allgemeinwissen sein, woran man hier aber zweifeln kann. Beispielsweise kann ein OTP fast beliebig aufgeteilt und neu zusammengesetzt werden. Dadurch bleiben die Sicherheit und Qualität des Pad praktisch unverändert. Der Inhalt eines OTP ist in höchster Qualität gleichverteilt. Dadurch ist ein Großteil der Arbeit bereits getan. Deshalb ändern sich durch Neuanordnung des Inhalts an kryptographischer Qualität und Sicherheit praktisch nichts. Das ist doch logisch und bekannt! Man darf es praktisch damit lediglich nicht übertreiben. Ich habe schon vor einiger Zeit darüber nachgedacht, daß an den Übergangsstellen der Flicken leichte Störungen der Qualität auftreten können, mit geringer Wahrscheinlichkeit. Wenn nun aber zwei Flicken mit z.B. 723442 | 237248 Byte aneinander stoßen, sind solche Effekte garantiert vernachlässigbar! Die Flicken eines Pad dürfen jedoch nicht z.B. 1 bis 3 Byte groß sein. Das ist ebenfalls sehr logisch. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@h5.or.at> |
|---|---|
| Date | 2026-10-19 12:28 +0000 |
| Message-ID | <11b52d7$e8q8$1@gwaiyur.mb-net.net> |
| In reply to | #370002 |
Helmut Schellong <var@schellong.biz> wrote: > Ich teile einen OTP in sehr viele Teilstücke auf und ordne > diese zufällig neu an, so daß ein neuer einmaliger OTP entsteht. > Dabei bleibt ein großer Teil des OTP-Inhalts per Zufall ohne Verwendung. > Ein großer zufälliger Teil des Inhalts wird in der Byte-Folge umgedreht. > > Kryptographische Qualität und Sicherheit bleiben praktisch gleich. > Aber es ist ein generierter einmaliger neuer OTP, weshalb die eine Quelle > immer wieder verwendet werden kann. „Jesus sagte: ‚Lasst die Leute sich setzen!‘ Es gab dort nämlich viel Gras. Da setzten sie sich; es waren etwa fünftausend Männer. Dann nahm Jesus die Brote, sprach das Dankgebet und teilte an die Leute aus, so viel sie wollten; ebenso machte er es mit den Fischen. Als die Menge satt geworden war, sagte er zu seinen Jüngern: ‚Sammelt die übrig gebliebenen Brocken, damit nichts verdirbt!‘ Sie sammelten und füllten zwölf Körbe mit den Brocken, die von den fünf Gerstenbroten nach dem Essen übrig waren. Als die Menschen das Zeichen sahen, das er getan hatte, sagten sie: ‚Das ist wirklich der Prophet, der in die Welt kommen soll.‘“ – Joh 6,10–14 EU /ralph
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <dk4xp@arcor.de> |
|---|---|
| Date | 2026-10-19 15:45 +0200 |
| Message-ID | <11b56u2$umu$1@solani.org> |
| In reply to | #370003 |
Am 19.10.26 um 14:28 schrieb Ralph Aichinger: > „Jesus sagte: ‚Lasst die Leute sich setzen!‘ Es gab dort nämlich viel Gras. > Da setzten sie sich; es waren etwa fünftausend Männer. DAS muss ja eine riesige Kifferei geworden sein. Gras für 5000 Männer! /Gerhard
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-19 15:55 +0200 |
| Message-ID | <11b57gf$v5l$1@solani.org> |
| In reply to | #370005 |
Am 19.10.2026 um 15:45 schrieb Gerhard Hoffmann: > Am 19.10.26 um 14:28 schrieb Ralph Aichinger: > >> „Jesus sagte: ‚Lasst die Leute sich setzen!‘ Es gab dort nämlich viel >> Gras. >> Da setzten sie sich; es waren etwa fünftausend Männer. > DAS muss ja eine riesige Kifferei geworden sein. > Gras für 5000 Männer! "Chuck" Helmut war unter den 5000 Männern, hatte aber noch was Härteres dabei - Hero-in, oder so. :) -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-10-19 20:55 +0200 |
| Message-ID | <slrn11dcptr.i676.als@mordor.angband.thangorodrim.de> |
| In reply to | #370006 |
Leo Baumann <ib@leobaumann.de> wrote: > Am 19.10.2026 um 15:45 schrieb Gerhard Hoffmann: >> Am 19.10.26 um 14:28 schrieb Ralph Aichinger: >> >>> „Jesus sagte: ‚Lasst die Leute sich setzen!‘ Es gab dort nämlich viel >>> Gras. >>> Da setzten sie sich; es waren etwa fünftausend Männer. >> DAS muss ja eine riesige Kifferei geworden sein. >> Gras für 5000 Männer! > > "Chuck" Helmut war unter den 5000 Männern, hatte aber noch was Härteres > dabei - Hero-in, oder so. "Heroin - eine Handelsmarke der Bayer AG." HTH, 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 | Thomas Prufer <prufer.public@mnet-online.de.invalid> |
|---|---|
| Date | 2026-10-19 16:05 +0200 |
| Message-ID | <kj8cdlhgdb1llj50rde85cldsc4hms2feo@4ax.com> |
| In reply to | #370002 |
On Mon, 19 Oct 2026 13:12:21 +0200, Helmut Schellong <var@schellong.biz> wrote: >Thomas Prufer wrote on 19.10.2026 10:10: >> On Sun, 18 Oct 2026 19:43:10 +0200, Helmut Schellong <var@schellong.biz> wrote: >> >>> Marc Haber wrote on 18.10.2026 19:04: >>>> Helmut Schellong <var@schellong.biz> wrote: >>>>> Ich habe das längst durch analysiert und kam zu dem Ergebnis, daß mein Verfahren >>>>> viele Vorteile bringt und absolut sicher ist. >>>>> Diese Pads-on-the-fly, die meine Software produziert, sind angewandt unknackbar, >>>>> genau so, wie OTPs in Standard-Verwendung. >>>> >>>> Das ist halt leeres Sprücheklopfen, und obendrein unrichtig. >>> >>> Widerlege meine Aussage. >>> Jedoch ohne platte Behauptung und nicht ohne Begründung. >>> >>> Das wirst Du nicht machen, weil das nicht geht. >> >> Ein OTP zB zu invertieren ergibt nicht ein neuen OTP, sondern erhöht die >> Entropie um ein Bit. Somit ist nicht mehr Sicherheit zu erwarten, als durch >> diese eine Bit eben gewonnen wird. Dasselbe gilt für ähnliche Transformation, >> Auswahlen usw. > >Ich invertiere keinen OTP - das wäre viel zu einfach. >Ich teile einen OTP in sehr viele Teilstücke auf und ordne >diese zufällig neu an, so daß ein neuer einmaliger OTP entsteht. >Dabei bleibt ein großer Teil des OTP-Inhalts per Zufall ohne Verwendung. >Ein großer zufälliger Teil des Inhalts wird in der Byte-Folge umgedreht. > >Kryptographische Qualität und Sicherheit bleiben praktisch gleich. >Aber es ist ein generierter einmaliger neuer OTP, weshalb die eine Quelle >immer wieder verwendet werden kann. Es ist ein wiederverwendeter OTP, mit einigen Bits Zufall aufgehübscht -- "ordne diese zufällig neu an". Und damit ist die ist die kryptographische Sicherheit auf dies einige Bits Zufall reduziert. Invertieren ist eine einfache, anschauliche Art des Zufalls. Ein Stück rückwärts lesen ist ein wenig komplexer, bringt aber auch nur wenig mehr Zufall rein. Aber das magst ned verstehen, oder kannst es nicht, oder... Thomas Prufer
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | de.sci.electronics
csiph-web