zufallszahlen als code

So es ist mal wieder Winter und die Ideeen sprudeln

Idee:
an einer Stage soll ein 4-8 stelliger Code ausgegeben werden, aber nur genau 1 mal.
Dieser Code öffnet später dann ein Codeschloss.

Problem:
1.) Zufallszahlen zu erzeugen ist kein Problem. nur sollten die gleichen Zahlen ja auch im Schloss sein.
2.) Das schloss soll die schonmal eingegebene Zahl löschen.
3.) vertippt sich jetzt jemand und erwischt zufällig eine richtige Zahl dann weiß der Generator nicht das diese Zahl nicht mehr ausgegeben werden darf.

habe schon alles mögliche zum Thema Codeschloss mit variablem code gegoogelt finde aber nix passendes.

Steffen

Birabeach schrieb:

3.) vertippt sich jetzt jemand und erwischt zufällig eine richtige Zahl dann weiß der Generator nicht das diese Zahl nicht mehr ausgegeben werden darf.

Zum Vergrößern anklicken....

Einen Vertipper kannst Du erkennen, indem du eine zusätzliche Prüfziffer an deinen Code anhängst.

Birabeach schrieb:

Idee:
an einer Stage soll ein 4-8 stelliger Code ausgegeben werden, aber nur genau 1 mal.
Dieser Code öffnet später dann ein Codeschloss.

Problem:
1.) Zufallszahlen zu erzeugen ist kein Problem. nur sollten die gleichen Zahlen ja auch im Schloss sein.
2.) Das schloss soll die schonmal eingegebene Zahl löschen.
3.) vertippt sich jetzt jemand und erwischt zufällig eine richtige Zahl dann weiß der Generator nicht das diese Zahl nicht mehr ausgegeben werden darf.

Zum Vergrößern anklicken....

Was spricht anstatt 'Zufallszahlen' gegen 'interne Liste'? D.h. in der einen Stage sind z.B. 100 Codes eingespeichert die man an der anderen wieder eingeben muß. Die erste Stage gibt dann einen nach dem anderen aus, die zweite erwartet genau diesen Code wieder als Eingabe.

Natürlich müßte man dann an der Eingabestation auch mal 5-10 Codes auslassen können falls vorher irgendwer die zweite Stage nicht findet oder nicht bedienen kann. D.h. ein einmal ausgegebener Code funktioniert nur einmal an der zweiten Stage, dann wird der nächste erwartet (bzw. die Stage akzeptiert dann auch die nächsten 5-10 Codes, und geht dann von da aus weiter).

Und wenn die 100 codes rum sind fängt das ganze wieder bei 0 an. Mag dann sein daß irgendwer mal den gleichen Code bekommt, aber das ist dann ziemlich unwahrscheinlich.

Die Hardware dazu sollte ziemlich klar sein, das ganze würde dann in der Software realisiert.

Oh, "die Idee schon wieder"... Irgendwie hab ich das Gefühl, die kommt alle halbe Jahr mal hoch, und dann ist es den Leuten doch zu viel Arbeit, das umzusetzen.

Auch alle halbe Jahr mal wieder kommt die Erkenntnis hoch, dass durch technische Probleme frustrierte Dosensucher oder solche, die sich einfach den Code vom Vorgänger "sagen" ließen (der dann natürlich nicht mehr funktioniert), vermutlich eher früher als später das elektronische Schloss vandalisieren werden. Wer Dosensuchern den Weg zur Büchse erschwert, sollte mit deren... "Hartnäckigkeit" oder "alternativen Logbucherreichungsansätzen" rechnen.

Ansonsten fallen mir spontan 2 Lösunsansätze ein - einer per Fleiß, einer per Mathematik. Bisher hatte ich nur den Fleißansatz - gerade eben kam mir beim drüber überlegen der Mathematik-Ansatz, weil ich mich gerade beruflich in einer Thematik rumtreibe.

Ich schreib erstmal den Fleiß-Ansatz, wobei der bisher noch niemanden zur Umsetzung animierte, den ich ihm servierte. Der Mathematik-Ansatz braucht weniger Code und weniger Speicher, aber finde mal jemanden, der sich freiwillig mit Mathematik rumschlägt.

Der Fleiß-Ansatz: Man generiert sich eine Liste mit gültigen Codes mit einem Zufallszahlengenerator. Einmal, zu Hause am PC, per Bleistift - egal. Wieauchimmer. Diese Liste kennt sowohl die "Station", als auch das "Codeschloss". Die Station sucht sich per Zufallszahlengenerator einen Code aus der Liste raus, markiert ihn als "verwendet", und teilt ihn dem Sucher mit. Das Codeschloss nimmt einen eingegebenen Code, vergleicht ob der in der Liste ist, und wenn er drin ist wird er auch als "verwendet" ausgekreuzt und die Büchse geöffnet.

Heißt natürlich: Gelegentlich mal muss der Büchsenowner die Liste in Station und Codeschloss erneuern/auffüllen, wenn quasi keine unbenutzten Codes mehr drin sind.

Beispiel: Eine Liste von 256 Codes bestehend aus jeweils einer 16Bit Hex-Zahl brauchen 512Byte Speicher im Prozessor für die Liste. Das haben fast alle "großen" Prozessoren (zu denen hier ja gerne mal der Trend aus Faulheit geht) locker als EEPROM. EEPROM hat im Gegensatz zu Flash den Vorteil, dass man einen "benutzten" Code durch überschreiben mit 0x0000 oder 0xffff "auskreuzen" kann, so dass er nicht nochmal verwendet wird. Andererseits hat natürlich eine nagelneue Liste mit 256 16Bit-Einträgen eine Wahrscheinlichkeit von ca. 0,5%, dass ein "Zufallstreffer" per Tastatur eine gültige Kombi ist. Je leerer die Liste schon ist, umso kleiner wird die Wahrscheinlichkeit eines Zufallstreffers.

16Bit-Zahlen lassen sich aus 4 Ziffern einer Hex-Tastatur eingeben oder durch 5 Ziffern einer Dez-Tastatur. Es gibt Schlimmeres.

Ausbaubar zu Luxus: 1024 Codes á 32 Bit brauchen 4kB Speicher. Das heißt meist externes EEPROM oder Codes im Flash und "Kreuz-Tabelle" im EEPROM, dafür wird man aber wohl bei kaum einer Dose jemals die Tabelle auffüllen müssen. Eine reine "Auskreuz-Tabelle" im EEPROM (mit zugehörigen Codes im Flash) braucht 128 Bytes. Das ist dann schon wieder quasi gar nix im EEPROM, bedarf aber etwas Hirnschmalz in der entsprechenden Code-Such-und-Auskreuz-Routine. 32Bit sind 8 Ziffern einer Hex-Tastatur oder 10 Ziffern einer Dez-Tastatur, und eine Wahrscheinlichkeit von 0,2ppm für einen Zufallstreffer. Da kann glaub ich keiner mehr jammern.

Grundsätzlich ist sowas technisch nicht wirklich anspruchsvoll - aber halt durchaus Fleißarbeit in der Realisierung. Mich haben schon gefühlt 27 Leute gefragt, wie man diese Problemstellung in Software erschlagen könnte, ich hab daraufhin o.g. skizziert, und bisher haben alle mit "Och nö, so dringend ist dann doch nicht" dankend abgelehnt.

Die Lösung mit Mathematik braucht erheblich weniger Platz für Datenablage, dafür aber erheblich mehr Hirn in der Erstellung von Programmcode - und da Hirn für gewöhnlich nicht mit Gold aufzuwiegen ist wird sich da wohl noch unwahrscheinlicher jemand finden.

chrysophylax.

Man kann Pseudozufallszahlen verwenden.
Dann muß man aber dafür sorgen, daß das Abrufen und Nichtverwenden einer Zahl nicht zu Problemen führt.

Ein möglicher Lösungsansatz wäre ein sliding window über eine definierte Zahlenfolge dazu noch den hashwert der Schlüsselzahlen um es undurchschaubarer zu machen und fertig ist das Verfahren. Die einzige Frage, die sich dann noch stellt ist:

Wird der Cache dadurch besser ?

Gruß
Rolf

Wenn Stage und Schloss jeweils über eine Echtzeituhr verfügen könnte man Codes erzeugen in denen ein Zeitstempel codiert ist (einschließlich Datum) und die dadurch nur eine gewisse Zeit gültig sind, z.B. nur für ein paar Stunden.

Da es hierbei nicht auf Sekunden ankommt müssten die wahrscheinlich innerhalb der Lebensdauer des Caches oder der Batterie nicht neu synchronisiert werden.

Als Mathematik-Lösung wäre mir übrigens noch gekommen, 16Bit Zufallszahlen zu nehmen, diese per CRC16 mit ungebräuchlichem Polynom und Seed mit einer Prüfsumme versehen, 16Bit CRC hintendranzuhängen, und wenn das "Schloss" die Kombi Zufallszahl+CRC als gültig erkannt hat den Deckel zu öffnen. Natürlich müssten auch hier sowohl Station als auch Schloss eine Liste von bereits ausgegebenen / eingesetzten Codes führen und diese "auskreuzen", damit sie nicht nochmal verwendet werden.

Man hätte also wenigstens das Liste-Nachfüllen gespart, dafür würden bestimmt diverse Gruppen "freundlicherweise" für ihre "nachfolgenden Kumpels" gleich 2 oder mehr Öffnungs-Kombis erzeugen, falls sich rumspricht, dass die Dose jeden Code nur einmal akzeptiert. Die kann man dann auch irgendwann mal bei i-bäh kaufen oder so....

Wobei meiner Meinung nach immer noch die 2 wichtigsten Hauptprobleme bisher völlig außer Acht gelassen wurden:

1.):

chrysophylax schrieb:

Auch alle halbe Jahr mal wieder kommt die Erkenntnis hoch, dass durch technische Probleme frustrierte Dosensucher oder solche, die sich einfach den Code vom Vorgänger "sagen" ließen (der dann natürlich nicht mehr funktioniert), vermutlich eher früher als später das elektronische Schloss vandalisieren werden. Wer Dosensuchern den Weg zur Büchse erschwert, sollte mit deren... "Hartnäckigkeit" oder "alternativen Logbucherreichungsansätzen" rechnen.

Zum Vergrößern anklicken....

2.):

rolf1327 schrieb:

Wird der Cache dadurch besser ?

Zum Vergrößern anklicken....

chrysophylax

die idee mit der uhr fand ich ertsmal nicht schlecht. alledings weiß ja wieder das schloss nicht wann der code ausgegeben worden ist. ja mit der anderen geschichte tabelle auskreuzen usw,hab ich mich auch schon beschäftigt ist aber (für mich) zu aufwändig.

der grund für die aktion ist die, dass das dösle in der stadt liegen soll. eigendlich recht gut zugänglich.
da es aber ein multi bzw wig werden soll sollte das final etwas aufwendiger sein.

Birabeach schrieb:

die idee mit der uhr fand ich ertsmal nicht schlecht. alledings weiß ja wieder das schloss nicht wann der code ausgegeben worden ist.

Zum Vergrößern anklicken....

Diese Info ist im Code enthalten. Der Code ist einfach nur eine Darstellung von Datum und Uhrzeit die für die Cacher nicht lesbar ist.

Birabeach schrieb:

der grund für die aktion ist die, dass das dösle in der stadt liegen soll. eigendlich recht gut zugänglich.
da es aber ein multi bzw wig werden soll sollte das final etwas aufwendiger sein.

Zum Vergrößern anklicken....

Ist ja schon ok, wenn es etwas aufwändiger werden soll. Ich verstehe jetzt aber nicht ganz, wo deine Sorgen liegen. Hast du die Sorge, das Cacher eventuell den Code weitergeben könnten?

kurz und kapp gesagt JA

ja diejenigen die das machen wollen sollen es tun etc usw. aber wenn man schonmal sowas basteln kann warum nicht., d.h. ich versuchs zu basteln

aus der erfahrung heraus:
es wird cacher geben die das prinzip nicht verstehen und deinen vermeintlich defekten cache nach erfolgloser eingabe des vermeindlich richtigen code dann "reparieren".... nenn mich pessimist.... traurig aber wahr

Birabeach schrieb:

kurz und kapp gesagt JA

ja diejenigen die das machen wollen sollen es tun etc usw. aber wenn man schonmal sowas basteln kann warum nicht., d.h. ich versuchs zu basteln

Zum Vergrößern anklicken....

Das ist natürlich deine Entscheidung und auch dein Cache. Ich persönlich finde es schade, wenn so viel Energie und Zeit für so eine Nebensächlichkeit aufgebracht wird. Wer behumpsen will, der tut das und auch nur sich selbst, also irrelevant.
ALLERDINGS: Alle anderen Finder deines zukünftigen Caches werden es dir mit Favoritenpunkten danken, wenn du die beim Code eingesparte Energie in schöne Aufgaben/was weiß ich steckst.
Mir egal, mach meinetwegen Fort Knox draus.