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 167 — 17 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 Volker Bartheld <news2026@bartheld.net> - 2026-10-18 13:11 +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 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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-16 23:19 +0200 |
| Message-ID | <11au4d4$1i6qo$1@solani.org> |
| In reply to | #369960 |
Marc Haber wrote on 16.10.2026 21:08: > Helmut Schellong <var@schellong.biz> wrote: >> Ich habe mir allerdings die Aufgabe gestellt, ein OTP mehrfach benutzbar zu machen. >> Und das habe ich nachweislich geschafft. > > Du möchtest die kostenfrei flächendeckend verfügbaren, perfekt runden, > gefederten Räder nicht nutzen und fährst statt dessen mit einem > unregelmäßig geschmiedeten Fünfeck herum. > > Das kannst Du machen. Aber dann lacht man Dich halt aus. So ist das, wenn einer solche Arbeiten aus sportlichen Gründen angeht. Ich muß halt meine Grütze trainieren. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-10-16 23:42 +0200 |
| Message-ID | <11au5on$1ikte$1@news1.tnib.de> |
| In reply to | #369963 |
Helmut Schellong <var@schellong.biz> wrote: >Marc Haber wrote on 16.10.2026 21:08: >> Helmut Schellong <var@schellong.biz> wrote: >>> Ich habe mir allerdings die Aufgabe gestellt, ein OTP mehrfach benutzbar zu machen. >>> Und das habe ich nachweislich geschafft. >> >> Du möchtest die kostenfrei flächendeckend verfügbaren, perfekt runden, >> gefederten Räder nicht nutzen und fährst statt dessen mit einem >> unregelmäßig geschmiedeten Fünfeck herum. >> >> Das kannst Du machen. Aber dann lacht man Dich halt aus. > >So ist das, wenn einer solche Arbeiten aus sportlichen Gründen angeht. >Ich muß halt meine Grütze trainieren. Als sportliche Arbeit ohne den Willen das jemals produktiv einzusetzen ist das sicher ganz gutes Training. Aber Du solltest als nächstes trainieren, Deine Grenzen zu erkennen. Grüße Marc -- ---------------------------------------------------------------------------- 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 | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-17 21:02 +0200 |
| Message-ID | <11b0go3$1m2su$1@solani.org> |
| In reply to | #369964 |
Marc Haber wrote on 16.10.2026 23:42: > Helmut Schellong <var@schellong.biz> wrote: >> Marc Haber wrote on 16.10.2026 21:08: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Ich habe mir allerdings die Aufgabe gestellt, ein OTP mehrfach benutzbar zu machen. >>>> Und das habe ich nachweislich geschafft. >>> >>> Du möchtest die kostenfrei flächendeckend verfügbaren, perfekt runden, >>> gefederten Räder nicht nutzen und fährst statt dessen mit einem >>> unregelmäßig geschmiedeten Fünfeck herum. >>> >>> Das kannst Du machen. Aber dann lacht man Dich halt aus. >> >> So ist das, wenn einer solche Arbeiten aus sportlichen Gründen angeht. >> Ich muß halt meine Grütze trainieren. > > Als sportliche Arbeit ohne den Willen das jemals produktiv einzusetzen > ist das sicher ganz gutes Training. Aber Du solltest als nächstes > trainieren, Deine Grenzen zu erkennen. Schon wieder Behauptungen. Ich werde das ganz sicher produktiv einsetzen. Aber ich weiß nicht, ob ich dann langzeitig dabei bleibe. Trotzdem sind sportliche Gründe dabei. Nach dem Motto: das will ich doch mal sehen, ich werde das ganz sicher schaffen. Meine Grenzen kenne ich. In den letzten paar Jahren habe ich keine Grenze gesehen, sondern alles souverän geschafft. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2026-10-17 11:16 +0200 |
| Message-ID | <11avle9.3u8.1@stefan.msgid.phost.de> |
| In reply to | #369956 |
Am 16.10.2026 um 20:15 schrieb Helmut Schellong: > Stefan Reuther wrote on 16.10.2026 18:12: >> Am 16.10.2026 um 03:03 schrieb Helmut Schellong: >>> Die Liste oben ist nur ein lesbarer Ausdruck, ein Service. >>> Zum Entschlüsseln brauche ich eine binäre Version dieser Tabelle. >> >> >> Verzeih mir, ich hab im Informatikstudium gelernt, zu abstrahieren. >> "Diese Tabelle" und "eine binäre Version dieser Tabelle" ist das >> gleiche. Es braucht nur einen Perl-Dreizeiler, um zu konvertieren. > > Das stimmt. > Jedoch hast Du auch was von Vingenere-Chiffre geschrieben: > Du hast (fast) behauptet, mein Generator sei ein Vingenere-Mechanismus. > Das liegt jedoch Welten von der Wirklichkeit entfernt. Vingenere sagt: man nehme ein Codewort, das Codewort wählt, mit welchem Teil der Codetabelle welcher Teil des Klartexts verschlüsselt wird. Du sagst: man nehme ein Codewort (deine Arbeitstabelle), das Codewort wählt, mit welchem Teil der Codetabelle (dein "OTP") welcher Teil des Klartexts verschlüsselt wird. Dein Alphabet ist größer als es bei Vingenere war, aber das Prinzip ist das gleiche. >>> Was ist daran kompliziert? >>> Man ruft das Kommando auf, und - Patsch - ist alles fertig. >>> Die Tabelle oben ist in Millisekunden fertig... >> >> Stand der Technik ist: man kann sowas ohne eine solche Tabelle >> erledigen. Ohne 10 GByte "OTP". Mit nur einem (z.B.) 4096-Bit-Schlüssel. >> Erwiesen sicher nach dem Stand der Technik. > > Ich habe mir allerdings die Aufgabe gestellt, ein OTP mehrfach benutzbar > zu machen. Dann ist es kein OTP mehr. D'ooh. > Und das habe ich nachweislich geschafft. Hat halt in etwa den Wert von "ich habe mir die Aufgabe gestellt, elektrische Geräte (z.B. Vapes) zu bauen, die man nicht mehr aufladen muss" und als Lösung ein Einmal-Wegwerfgerät zu erfinden: kann man ignoranten Kunden andrehen, bringt aber die Menschheit nicht weiter. > Wurde mit dem OTP verknüpft? Wirklich? Dem kann eigentlich nicht > zugestimmt werden! Kann es ohne das OTP entschlüsselt werden? Nein? Dann ist OTP entweder Teil des Schlüssels, oder Teil des Algorithmus. Darf das OTP publiziert werden? Nein? Dann ist es Teil des Schlüssels. Und nach allen Maßstäben brauchbare Sicherheit bekommt man mit (z.B.) 3072-Bit-RSA, ohne, dass man ein 80000000000-Bit-OTP austauschen muss. >> Wenn der Zweck ist: Daten schwieriger handhabbar zu machen ohne >> ernsthaften Gewinn an Vertraulichkeit oder Verfügbarkeit, dann ja. > > Die Daten werden allerdings durch den Flicken-Generator beträchtlich > und eindeutig _besser_ handhabbar gemacht, wie ich schrieb. > Beispiel: Die aufzubewahrende Kontroll-Datei ist oft etwa 15000 Byte klein. ...und ist ohne die 10 GByte OTP nichts wert. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-17 22:31 +0200 |
| Message-ID | <11b0lug$1m6q7$1@solani.org> |
| In reply to | #369968 |
Stefan Reuther wrote on 17.10.2026 11:16: > Am 16.10.2026 um 20:15 schrieb Helmut Schellong: >> Stefan Reuther wrote on 16.10.2026 18:12: >>> Am 16.10.2026 um 03:03 schrieb Helmut Schellong: >>>> Die Liste oben ist nur ein lesbarer Ausdruck, ein Service. >>>> Zum Entschlüsseln brauche ich eine binäre Version dieser Tabelle. >>> >>> >>> Verzeih mir, ich hab im Informatikstudium gelernt, zu abstrahieren. >>> "Diese Tabelle" und "eine binäre Version dieser Tabelle" ist das >>> gleiche. Es braucht nur einen Perl-Dreizeiler, um zu konvertieren. >> >> Das stimmt. >> Jedoch hast Du auch was von Vingenere-Chiffre geschrieben: >> Du hast (fast) behauptet, mein Generator sei ein Vingenere-Mechanismus. >> Das liegt jedoch Welten von der Wirklichkeit entfernt. > > Vingenere sagt: man nehme ein Codewort, das Codewort wählt, mit welchem > Teil der Codetabelle welcher Teil des Klartexts verschlüsselt wird. > > Du sagst: man nehme ein Codewort (deine Arbeitstabelle), das Codewort > wählt, mit welchem Teil der Codetabelle (dein "OTP") welcher Teil des > Klartexts verschlüsselt wird. > > Dein Alphabet ist größer als es bei Vingenere war, aber das Prinzip ist > das gleiche. Es kann ein gleiches Grund-Prinzip in den beiden Maschinen gesehen werden. Mein Ding ist allerdings sehr viel komplexer als das von Vingenere. Es hat mehrere Ebenen der Verschleierung. Es basiert umfassend (restlos) auf hochqualitativem Zufall. Es ist vielleicht 100000-fach größer. Ich kann die Größe noch vervielfachen - aber warum sollte ich? Die Wirkung ist bereits gut genug. Die Verschleierungswirkung könnte Billionen-fach größer sein. Wie ich sagte - dazwischen liegen Welten. >>>> Was ist daran kompliziert? >>>> Man ruft das Kommando auf, und - Patsch - ist alles fertig. >>>> Die Tabelle oben ist in Millisekunden fertig... >>> >>> Stand der Technik ist: man kann sowas ohne eine solche Tabelle >>> erledigen. Ohne 10 GByte "OTP". Mit nur einem (z.B.) 4096-Bit-Schlüssel. >>> Erwiesen sicher nach dem Stand der Technik. >> >> Ich habe mir allerdings die Aufgabe gestellt, ein OTP mehrfach benutzbar >> zu machen. > > Dann ist es kein OTP mehr. D'ooh. Die OTP-Datei an sich ist ein echtes OTP. Jedoch erzeuge ich aus dessen Inhalt beliebig viele temporäre Pads 'on the fly', die einmalig sind. Man kann allerdings nach einer Entschlüsselung die Datei mit einer erneuten Entschlüsselung wieder verschlüsseln - das toggelt halt. >> Und das habe ich nachweislich geschafft. > [...] > Darf das OTP publiziert werden? Nein? Dann ist es Teil des Schlüssels. > Und nach allen Maßstäben brauchbare Sicherheit bekommt man mit (z.B.) > 3072-Bit-RSA, ohne, dass man ein 80000000000-Bit-OTP austauschen muss. Ich muß keine OTP-Datei jemals austauschen. Das erspart mir meine Software. >>> Wenn der Zweck ist: Daten schwieriger handhabbar zu machen ohne >>> ernsthaften Gewinn an Vertraulichkeit oder Verfügbarkeit, dann ja. >> >> Die Daten werden allerdings durch den Flicken-Generator beträchtlich >> und eindeutig _besser_ handhabbar gemacht, wie ich schrieb. >> Beispiel: Die aufzubewahrende Kontroll-Datei ist oft etwa 15000 Byte klein. > > ...und ist ohne die 10 GByte OTP nichts wert. Stimmt. Die 10 GB muß aufbewahrt werden, und die Kontrolldatei (8192x16) ebenso. Aber ohne meine Software muß ich mehrere OTPs vorhalten, die ich immer wieder erneuern muß. Mit einer 10 GB kann ich dauerhaft beliebig viele Dateien verschlüsseln - für immer! Ich kann auch nach einer Entschlüsselung eine _neue_ Verschlüsselung vornehmen. Dann kann ich die alte Kontrolldatei löschen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2026-10-18 12:23 +0200 |
| Message-ID | <11b2do9.474.1@stefan.msgid.phost.de> |
| In reply to | #369974 |
Am 17.10.2026 um 22:31 schrieb Helmut Schellong: > Stefan Reuther wrote on 17.10.2026 11:16: >> Am 16.10.2026 um 20:15 schrieb Helmut Schellong: >>> Stefan Reuther wrote on 16.10.2026 18:12: >>>> Am 16.10.2026 um 03:03 schrieb Helmut Schellong: > [...] >> Darf das OTP publiziert werden? Nein? Dann ist es Teil des Schlüssels. >> Und nach allen Maßstäben brauchbare Sicherheit bekommt man mit (z.B.) >> 3072-Bit-RSA, ohne, dass man ein 80000000000-Bit-OTP austauschen muss. > > Ich muß keine OTP-Datei jemals austauschen. > Das erspart mir meine Software. [...] > Stimmt. Die 10 GB muß aufbewahrt werden, und die Kontrolldatei (8192x16) > ebenso. "Aufbewahren" und "austauschen" ist das gleiche. "Aufbewahren" zum selbst entschlüsseln, "austauschen" (mit einem Empfänger), damit der das entschlüsseln kann. > Aber ohne meine Software muß ich mehrere OTPs vorhalten, die ich > immer wieder erneuern muß. Ohne deine Software muss ich nur ein paar Kilobyte *.pem aufbewahren bzw. austauschen. > Mit einer 10 GB kann ich dauerhaft beliebig viele Dateien verschlüsseln > - für immer! Und der Rest der Welt *braucht keine 10 GB dafür*. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-18 13:02 +0200 |
| Message-ID | <11b28un$1n9iv$1@solani.org> |
| In reply to | #369980 |
Stefan Reuther wrote on 18.10.2026 12:23: > Am 17.10.2026 um 22:31 schrieb Helmut Schellong: >> Stefan Reuther wrote on 17.10.2026 11:16: >>> Am 16.10.2026 um 20:15 schrieb Helmut Schellong: >>>> Stefan Reuther wrote on 16.10.2026 18:12: >>>>> Am 16.10.2026 um 03:03 schrieb Helmut Schellong: >> [...] >>> Darf das OTP publiziert werden? Nein? Dann ist es Teil des Schlüssels. >>> Und nach allen Maßstäben brauchbare Sicherheit bekommt man mit (z.B.) >>> 3072-Bit-RSA, ohne, dass man ein 80000000000-Bit-OTP austauschen muss. >> >> Ich muß keine OTP-Datei jemals austauschen. >> Das erspart mir meine Software. > [...] >> Stimmt. Die 10 GB muß aufbewahrt werden, und die Kontrolldatei (8192x16) >> ebenso. > > "Aufbewahren" und "austauschen" ist das gleiche. "Aufbewahren" zum > selbst entschlüsseln, "austauschen" (mit einem Empfänger), damit der das > entschlüsseln kann. Das ist nicht meine Absicht und war es auch nie. Ich will mit niemandem verschlüsseltes Gut austauschen. Nein, ich will verschlüsselt Backup machen, und nichts weiter. Diese Absicht habe ich hier seit vielen Monaten vielleicht 5-mal verbreitet. >> Aber ohne meine Software muß ich mehrere OTPs vorhalten, die ich >> immer wieder erneuern muß. > Ohne deine Software muss ich nur ein paar Kilobyte *.pem aufbewahren > bzw. austauschen. > >> Mit einer 10 GB kann ich dauerhaft beliebig viele Dateien verschlüsseln >> - für immer! > > Und der Rest der Welt *braucht keine 10 GB dafür*. Ich habe gar kein Problem mit einer 10 GB, wie ich bereits mehrfach schrieb. Warum wurde das OTP-Verfahren dann hier mehrfach als unknackbar gelobt? Und warum werden hier Webseiten zum Thema genannt? -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2026@bartheld.net> |
|---|---|
| Date | 2026-10-18 13:11 +0200 |
| Message-ID | <b2b7580b01a3c2aff13217a47bc531c0f2ae22aa.camel@bartheld.net> |
| In reply to | #369980 |
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 On Sun, 2026-10-18 at 12:23 +0200, Stefan Reuther wrote: > Am 17.10.2026 um 22:31 schrieb Helmut Schellong: > > Stefan Reuther wrote on 17.10.2026 11:16: > > > Am 16.10.2026 um 20:15 schrieb Helmut Schellong: > > > > Stefan Reuther wrote on 16.10.2026 18:12: > > > > > Am 16.10.2026 um 03:03 schrieb Helmut Schellong: > > > Darf das OTP publiziert werden? Nein? Dann ist es Teil des Schlüssels. > > Ich muß keine OTP-Datei jemals austauschen. > > Stimmt. Die 10 GB muß aufbewahrt werden, und die Kontrolldatei (8192x16) > > ebenso. > "Aufbewahren" und "austauschen" ist das gleiche. > > Aber ohne meine Software muß ich mehrere OTPs vorhalten, die ich > > immer wieder erneuern muß.
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-10-17 21:44 +0200 |
| Message-ID | <slrn11d7k0f.208h.als@mordor.angband.thangorodrim.de> |
| In reply to | #369956 |
Helmut Schellong <var@schellong.biz> wrote:
>
> Ich habe mir allerdings die Aufgabe gestellt, ein OTP mehrfach benutzbar zu machen.
> Und das habe ich nachweislich geschafft.
Und Du hast den "One Time" Teil von "One Time Pad" sehr offensichtlich nicht
verstanden, was hier niemanden verwundert.
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 | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-10-15 17:45 +0200 |
| Message-ID | <11aqsf3$1cv65$1@news1.tnib.de> |
| In reply to | #369924 |
Helmut Schellong <var@schellong.biz> wrote: >Und als Zeichen meiner übergroßen Unfähigkeit habe ich in den letzten 6 Tagen >ein Programm 'Mehrfache Nutzung eines One-Time-Pad (OTP)' entwickelt: > >. http://www.schellong.de/txt/zlist.txt > >Diese Angelegenheit ist 'geritzt'. Dass One-Time-Pads nicht mehrfach zu nutzen sind ist "Kryptografie 101", das lernt jeder Anfänger spätestens in der dritten Stunde. Es gibt allgemein anerkannte Beweise auf allen Niveauebenen. Obendrein sind One-Time-Pads in der heutigen Kryptografie zu Recht ins Hintertreffen geraten, unter anderem weil man bei One-Time-Pads das Problem, den Klartext geheimhalten zu müssen verdoppelt, weil man nebenbei nun auch das One-Time-Pad, das genauso lang ist wie der zu verschlüsselnde Klartext, geheimhalten muss. 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. 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. -- ---------------------------------------------------------------------------- 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 | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-10-15 23:17 +0200 |
| Message-ID | <slrn11d2gmm.3n96h.als@mordor.angband.thangorodrim.de> |
| In reply to | #369933 |
Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>>Und als Zeichen meiner übergroßen Unfähigkeit habe ich in den letzten 6 Tagen
>>ein Programm 'Mehrfache Nutzung eines One-Time-Pad (OTP)' entwickelt:
>>
>>. http://www.schellong.de/txt/zlist.txt
>>
>>Diese Angelegenheit ist 'geritzt'.
>
> Dass One-Time-Pads nicht mehrfach zu nutzen sind ist "Kryptografie
> 101", das lernt jeder Anfänger spätestens in der dritten Stunde.
Wenn die Vorlesung etwas langsamer als üblich verläuft. ;-)
> Es gibt allgemein anerkannte Beweise auf allen Niveauebenen.
>
> Obendrein sind One-Time-Pads in der heutigen Kryptografie zu Recht ins
> Hintertreffen geraten, unter anderem weil man bei One-Time-Pads das
> Problem, den Klartext geheimhalten zu müssen verdoppelt, weil man
> nebenbei nun auch das One-Time-Pad, das genauso lang ist wie der zu
> verschlüsselnde Klartext, geheimhalten muss.
Eben, das ist halt das klassische Problem dabei.
> Das ist ein Verfahren fürs Lehrbuch, das undiskutierbare, theoretische
> Vorteile hat, dafür aber operationale Nachteile in es unpraktikabel
> machender Größe hat.
Absolut sicher. Absolut unpraktikabel.
> Auch in der geheimdienstlichen Praxis wurden
> One-Time-Pads höchstens für die Verschlüsselung kürzester Nachrichten
> verewendet.
Typischerweise zur Übermittlung sehr kurzer Code-Nachrichten der Kategorie
"Aktion #23, Zeit #42".
> 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.
Hmm, Du meinst, die Schellong'sche Kryptographie-"Forschung" eignet
sich als Kletterhilfe in den Bergen?
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-10-16 02:40 +0200 |
| Message-ID | <11arrp1$1gj5l$1@solani.org> |
| In reply to | #369933 |
Marc Haber wrote on 15.10.2026 17:45: > Helmut Schellong <var@schellong.biz> wrote: >> Und als Zeichen meiner übergroßen Unfähigkeit habe ich in den letzten 6 Tagen >> ein Programm 'Mehrfache Nutzung eines One-Time-Pad (OTP)' entwickelt: >> >> . http://www.schellong.de/txt/zlist.txt >> >> Diese Angelegenheit ist 'geritzt'. > > Dass One-Time-Pads nicht mehrfach zu nutzen sind ist "Kryptografie > 101", das lernt jeder Anfänger spätestens in der dritten Stunde. Es > gibt allgemein anerkannte Beweise auf allen Niveauebenen. > > Obendrein sind One-Time-Pads in der heutigen Kryptografie zu Recht ins > Hintertreffen geraten, unter anderem weil man bei One-Time-Pads das > Problem, den Klartext geheimhalten zu müssen verdoppelt, weil man > nebenbei nun auch das One-Time-Pad, das genauso lang ist wie der zu > verschlüsselnde Klartext, geheimhalten muss. > > 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! 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. Ich produziere prinzipiell beliebig viele einzigartige OTP-Flickenteppiche. Ich muß dazu nur eine kleine binäre Kontrolldatei aufheben, zwecks Entschlüsselung. Diese ist durch internen Hash (Keccak) gesichert. Außerordentlich vorteilhaft finde ich mein Konzept hierzu! > 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!" 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. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-10-16 12:38 +0200 |
| Message-ID | <11asurm$1gicl$1@news1.tnib.de> |
| In reply to | #369940 |
Helmut Schellong <var@schellong.biz> wrote: >Marc Haber wrote on 15.10.2026 17:45: >> Helmut Schellong <var@schellong.biz> wrote: >>> Und als Zeichen meiner übergroßen Unfähigkeit habe ich in den letzten 6 Tagen >>> ein Programm 'Mehrfache Nutzung eines One-Time-Pad (OTP)' entwickelt: >>> >>> . http://www.schellong.de/txt/zlist.txt >>> >>> Diese Angelegenheit ist 'geritzt'. >> >> Dass One-Time-Pads nicht mehrfach zu nutzen sind ist "Kryptografie >> 101", das lernt jeder Anfänger spätestens in der dritten Stunde. Es >> gibt allgemein anerkannte Beweise auf allen Niveauebenen. >> >> Obendrein sind One-Time-Pads in der heutigen Kryptografie zu Recht ins >> Hintertreffen geraten, unter anderem weil man bei One-Time-Pads das >> Problem, den Klartext geheimhalten zu müssen verdoppelt, weil man >> nebenbei nun auch das One-Time-Pad, das genauso lang ist wie der zu >> verschlüsselnde Klartext, geheimhalten muss. >> >> 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? 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. >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. Und wie schützt Du dieses OTP vor Zugriff? Den musst Du genau so schützen wie die schützenswerten Daten. Und backuppen! >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! Das ist aber bei OTP zwingend erforderlich, sonst hieße es MTP. >Dies entfällt komplett durch Verwendung meiner Software. Und dabei entfällt auch komplett die Sicherheit der Daten. -- ---------------------------------------------------------------------------- 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 | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-16 17:14 +0200 |
| Message-ID | <11atf0c$1hmd4$1@solani.org> |
| In reply to | #369948 |
Marc Haber wrote on 16.10.2026 12:38: > Helmut Schellong <var@schellong.biz> wrote: >> Marc Haber wrote on 15.10.2026 17:45: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Und als Zeichen meiner übergroßen Unfähigkeit habe ich in den letzten 6 Tagen >>>> ein Programm 'Mehrfache Nutzung eines One-Time-Pad (OTP)' entwickelt: >>>> >>>> . http://www.schellong.de/txt/zlist.txt >>>> >>>> Diese Angelegenheit ist 'geritzt'. >>> >>> Dass One-Time-Pads nicht mehrfach zu nutzen sind ist "Kryptografie >>> 101", das lernt jeder Anfänger spätestens in der dritten Stunde. Es >>> gibt allgemein anerkannte Beweise auf allen Niveauebenen. >>> >>> Obendrein sind One-Time-Pads in der heutigen Kryptografie zu Recht ins >>> Hintertreffen geraten, unter anderem weil man bei One-Time-Pads das >>> Problem, den Klartext geheimhalten zu müssen verdoppelt, weil man >>> nebenbei nun auch das One-Time-Pad, das genauso lang ist wie der zu >>> verschlüsselnde Klartext, geheimhalten muss. >>> >>> 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? > > 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'. Usw. >> 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. > > 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. Die Frage ist, wer will unbedingt an meine Daten kommen? Ein internationales Spezialistenteam würde das schaffen. Backup - was soll diese Bemerkung? Ich habe doch etwa 20 GB bereits auf Backup im Internet gespeichert. Das ist doch bekannt. Ich könnte auch 100 GB dort speichern. >> 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! > > Das ist aber bei OTP zwingend erforderlich, sonst hieße es MTP. > >> Dies entfällt komplett durch Verwendung meiner Software. > > Und dabei entfällt auch komplett die Sicherheit der Daten. Diese Sicherheit entfällt überhaupt nicht! Und _warum_ sollte die Sicherheit entfallen? Die Tabellen, die ich öffentlich machte, enthalten zu 100% den jeweiligen Handlungsplan für eine konkrete Verschlüsselung - da fehlt nichts. Folglich könnte jeder, der hierzu Kompetenz hat, Unsicherheiten aufzeigen. Solange so etwas nicht unternommen wird, werde ich platte Behauptungen nicht ernst nehmen. Dein Satz: "Und dabei entfällt auch komplett die Sicherheit der Daten." ist ein Null-Argument. Mein Flickenteppich-Generator arbeitet so, als ob man z.B. 65536 beschriftete Zettel in ein Gefäß gibt, mit Preßluft vermischt und alle Zettel blind einzeln entnimmt und diese Reihenfolge notiert. Alle, die diese Reihenfolge nicht notiert haben, sind folglich hilflos. Was ist an einem solchen Konzept unsicher? -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2026-10-16 18:29 +0200 |
| Message-ID | <11atqds.198.1@stefan.msgid.phost.de> |
| In reply to | #369951 |
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. >> 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? Stefan
[toc] | [prev] | [next] | [standalone]
| 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]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | de.sci.electronics
csiph-web