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 | 18 on this page of 158 — 16 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 Stefan Reuther <stefan.news@arcor.de> - 2026-10-17 11:16 +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 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 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| 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 | 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 | 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 | Andreas Fecht <forum@aftec.de> |
|---|---|
| Date | 2026-10-15 10:29 +0200 |
| Message-ID | <11aq2td$1hbto$1@solani.org> |
| In reply to | #369923 |
Am 15.10.2026 um 08:30 schrieb Marc Haber: > Das was Du hier ablieferst ist wirklich mit Abstand unter aller > Kanone. Diese Kombination aus Unfähigkeit, Hybris und Beharrlichkeit > ist mir in meiner bis 1984 zurückreichenden Laufbahn echt nur zwei, > dreimal untergekommen, Da kann ich Dir nur zustimmen (wie wohl fast alle hier (bis auf Einen)). Bei mir ist das bis jetzt nur einmal vorgekommen + Diesem hier. Ich bin immer nur erstaunt, wie beharrlich manche Leute sein können. Irgendwann wird wohl der jugendliche Leichtsinn durch Altersstarrsinn ersetzt ;-) Eine Einsicht kann man in dem Alter wohl nicht mehr erwarten. Gruß Andreas
[toc] | [prev] | [next] | [standalone]
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2026-10-15 10:44 +0200 |
| Message-ID | <11aq3q0$27s7s$1@dont-email.me> |
| In reply to | #369919 |
Am 14.10.26 um 12:44 schrieb Marc Haber: > Helmut Schellong <var@schellong.biz> wrote: >> Ich habe in meinem Berufsleben als Entwicklungsingenieur ständig fakten- und beweisbasiert >> gearbeitet. > > Jeder einzelner Deiner Kunden tut mir aufrichtig leid. > Noch deutlich schlimmer ist es, eine solche Persönlichkeit zum Kollegen zu haben. Ein Kollege, der sich für Gottes Geschenk an die Menschheit hält, ist wirklich extrem anstrengend. Und ich weiß wovon ich spreche :-/
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-10-05 14:58 +0200 |
| Message-ID | <slrn11c77no.3emot.als@frodo.angband.thangorodrim.de> |
| In reply to | #369758 |
Arno Welzel <usenet@arnowelzel.de> wrote:
> Helmut Schellong, 2026-10-05 12:52:
>
>> Arno Welzel wrote on 05.10.2026 01:36:
>>> Helmut Schellong, 2026-10-04 00:59:
>>>
>>>> Leo Baumann wrote on 03.10.2026 17:47:
>>>>> Am 03.10.2026 um 17:12 schrieb Helmut Schellong:
>>>>>> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten
>>>>>> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt!
>>>>>
>>>>> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich
>>>>> dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt.
>>>>
>>>> Der NIST-Test bestätigt jedoch die kryptographische Sicherheit.
>>>> Genau dafür ist er gemacht!
>>>>
>>>>> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der
>>>>> CPU-Taktzyklen seit dem letzten Reset.
>>>>
>>>> Nein, das ist wiederholt komplett falsch.
>>>> Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe.
>>>
>>> Den gibt es ja auch nicht. Den Quelltext zeigst Du nicht, weil den hier
>>> angeblich niemand versteht. Das ist einfach nur lächerlich.
>>
>> Die Ausgabe der randtsc.exe beweist das aber per NIST-Tests.
>> Das reicht mir.
>>
>> Hier in der NG wurde festgehalten, daß mein Quellcode unlesbar sei.
>
> Ich habe den Quellcode noch nie gesehen.
Dürfte auch besser so sein, Deine Leber wird es Dir danken.
SCNR,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-02 21:49 +0200 |
| Message-ID | <119p1rp$psm8$1@solani.org> |
| In reply to | #369673 |
Stefan Wiens wrote on 02.10.2026 16:19: > Helmut Schellong <var@schellong.biz> writes: > >> Leo Baumann wrote on 02.10.2026 06:29: >>> Am 01.10.2026 um 18:35 schrieb Helmut Schellong: >>>> Das Zauberwort in der Beschreibung oben ist 'Steuerungszwecke'. >>>> >>>> . sleep( D_bitmask & tsc ); >>> Die Anweisung erzeugt keine Entropie! >> >> Doch, weil die Werte vom TSC zufällig sind und weil die Wirkungen >> der unterlegten externen HW+SW permanent wirken. > > Was ist zufällig an der Zeit seit dem Reset? Es kommt auf das konkrete Lesen des Zählerstandes des TSC an! Das ist das Zufällige! Aus altem Posting: In den 1980er Jahren wurden Lotto-Generatoren angeboten. Einer hatte einen 10-MHz-Counter, der von 1..49 in der Runde zählte. Aktiviert wurde er durch Tippen auf einen mechanischen Taster mit Prellverhalten. Der Counter brauchte 4,9 us für 49 Zählschritte. Das sind 204 Durchläufe von 1..49 innerhalb einer Millisekunde. Das waren einwandfreie echte Zufallszahlen. Der TSC inkrementiert etwa 3000-mal innerhalb einer Mikrosekunde. Niemand kann innerhalb von Piko-Sekunden eine mechanische Taste drücken. Beispielsweise die Enter-Taste, um das Kommando aufzurufen. In der Zeit vor Beginn des Taste-Drückens hat der TSC zudem viel mehr gezählt, als während des Taste-Drückens. Die erste gelesene Zahl vom TSC ist doch zufällig - zufälliger geht es nicht so einfach - RDRAND ist graduell zufälliger. Die Prellzeit einer Taste liegt bei vielleicht 20 ms. Mein TSC zählt währenddessen 62111801 Schritte hoch. > Aber du hast auch belegt, dass du mit echten > Zufallszahlen nichts sinnvolles anfangen kannst, > wenn du sie mehrfach verwendest. Du hast nun den OTP-Gedanken hervorgeholt. Es gibt für echte Zufallszahlen mehrere Anwendungsfälle. Beispielsweise, wenn man 16 kleine Zahlen für ein kleines Array braucht, um ein Einschleifen, eine Zusammenführung optimal zu gestalten. Beispielsweise können die beiden großen Arrays (2x256x32bit) im Algorithmus Dragon echte Zufallszahlen enthalten. Die Verwendungsart isoliert sie nach außen. Für große OTP-Dateien hatte ich eine Verwendung von Offsets überlegt. Bei meiner Erfahrung kann ich das im Detail so gestalten, daß es kaum möglich ist, erfolgreich dagegen zu agieren: Und zwar Offsets im _gesamten_ Raum des OTP verteilt. Der Byte-Strom wird im Kreis herum, und vorwärts oder rückwärts abgetastet. Es gibt hier noch weitere einfache Möglichkeiten, um Verwirrung zu stiften! -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-09-29 15:52 +0200 |
| Message-ID | <119gfrl$gvoq$1@solani.org> |
| In reply to | #369613 |
Am 29.09.2026 um 13:06 schrieb Helmut Schellong: > Das ist allerdings eine Abwägung auf sehr hohem Level. Der RDTSC-Befehl (Read Time-Stamp Counter) misst lediglich die vergangen CPU-Taktzyklen seit dem Systemstart. Er ist aus zwei Hauptgründen weder ein echter noch ein kryptografisch sicherer Zufallszahlengenerator: Er besitzt keine physikalische Zufallsquelle (Entropie) und seine Werte sind für Angreifer vorhersehbar. :) -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-29 18:46 +0200 |
| Message-ID | <119gq0v$h7r4$1@solani.org> |
| In reply to | #369615 |
Leo Baumann wrote on 29.09.2026 15:52: > Am 29.09.2026 um 13:06 schrieb Helmut Schellong: >> Das ist allerdings eine Abwägung auf sehr hohem Level. > > Der RDTSC-Befehl (Read Time-Stamp Counter) misst lediglich die vergangen CPU-Taktzyklen seit dem Systemstart. Er ist aus zwei > Hauptgründen weder ein echter noch ein kryptografisch sicherer Zufallszahlengenerator: Er besitzt keine physikalische Zufallsquelle > (Entropie) und seine Werte sind für Angreifer vorhersehbar. Vorstehende Aussage ist nur zutreffend, wenn die verarbeitende Software von jemandem entwickelt wurde, der es halt nicht kann. Der noch nicht einmal die einfachen Grundlagen für einen Erfolg versteht, obwohl diese erklärt wurden. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | de.sci.electronics
csiph-web