Beiträge von Hecke29

    Der Knackpunkt in Variante von Post #6 ist die sichere Verwahrung von "(Private-)ASYMS". Und dieses Verwahrungs-Problem löst auch die Blockchain oder Smart-Contracts nicht.

    Das ist auch nicht das Problem, das es zu lösen galt. Das Problem, dass es zu lösen galt war, dass es nicht möglich ist vor einem bestimmten Datum an den zu schützenden Text T zu kommen.

    Ich habe ja erwähnt, dass man in dem Fall zwei (private) Geheimnisse schützen muss.

    Allerdings ist das sichere Verwahren der (privaten) Geheimnisse kein exklusives Problem meiner Lösung, sondern existiert bei groben Durchdenken meiner Meinung nach in jedem Lösungsansatz.

    Der wichtige Punkt ist ja: Selbst wenn jemand an ASYMS kommt, kann er damit nicht an einen beliebigen Text T kommen. Dazu braucht er zusätzlich Zugriff auf den privaten Schlüssel der Blockchain-Adresse und Geduld. Und in dieser Wartezeit ist es für mich sogar noch möglich alle Secrets aus dem Smart-Contract zu entfernen (weil ich z.B. ein Offline-Backup vom Schlüssel der Blockchain-Adresse habe)

    Hallo gunnarh ,

    danke für deine Ideen. Genau was du zu den Zertifikaten meintest, hatte ich auch im Sinn: Keiner zwingt mich (kryptografisch) mich an das Ablaufdatum zu halten. Ich kann analog z.B. auch an bereits abgelaufene PGP-Schlüssel Text senden, obwohl der Schlüssel als ungültig markiert ist.

    GPG kam mir auch in den Sinn, aber das "Problem" ist, dass der zukünftige Empfänger die Öffentlichkeit wäre, also die geheimen Texte veröffentlicht werden. Sprich: Das System selbst ist gewissermaßen der Empfänger und ich möchte verhindern, dass es da früher / zwischendurch ran kann bis sich der Autor wirklich dazu entschieden hat den Text wirklich zu veröffentlichen.

    Dafür war ich schon relativ früh zum Entschluss gekommen, dass ich eine vertrauenswürdige Drittpartei brauche. Es gibt ja Timestamp-Authorities, aber damit läge die Prüfung "Darf das schon entschlüsselt werden?" wieder in der Applikationslogik, was es ja ähnlich wie bei Ablaufdaten von Zertifikaten oder Schlüsseln zu verhindert gilt. Ich wollte diese Prüfung aber schon technisch abgedeckt sehen. Der Hinweis auf Smart-Contracts muss ich sagen, gefällt mir derzeit am meisten. Und es ist tatsächlich mal ein Use-Case für Blockchain ohne, dass man unbedingt das Buzz-Word unterbringen muss :D

    Idee ist derzeit wie folgt:

    1. Nutzer gibt (zu schützenden) Text T ein.
    2. T wird symmetrisch mit Schlüssel SYMS verschlüsselt (Schlüssel ist für jeden Text einzigartig), es entsteht SYMS(T)
    3. SYMS(T) wird in der Anwendungsdatenbank gespeichert
    4. SYMS wird asymmetrisch mit (Public-)Schlüssel ASYMS_PUB verschlüsselt (Systemweit gleich). Es entsteht ASYM(SYMS)
    5. ASYM(SYMS) wird in einem Smart-Contract in einem Dictionary unter (s)einem Hash H gespeichert (dient als Identifier). Key-value-artig (mit key = H und value = {"secret" => ASYM(SYMS), "notBefore" => "2019-01-01"})
    6. SYMS wird vernichtet. Ab jetzt ist SYMS(T) von der Anwendung nicht mehr entschlüsselbar.
    7. Smart-Contract stellt zwei "Methoden" zur Verfügung (bin mit den Termini nicht so vertraut): deleteSecret, getSecret (nebst createSecret)
      • getSecret liefert zu H das secret nur aus, falls die aktuelle Zeit nach notBefore liegt
      • deleteSecret löscht den Eintrag aus dem Dictionary
    8. H wird in der Anwendungsdatenbank mit SYMS(T) verknüpft gespeichert
    9. Der Nutzer bekommt H mitgeteilt mit dessen Hilfe er die Veröffentlichung stoppen kann (die Anwendung ruft dann deleteSecret mit H auf, wodurch die einzige Version von SYMS verloren geht)
    10. Die Anwendung selbst (oder von mir aus auch das im Smart-Contract) trackt wann SYMS(T) theoretisch veröffentlicht werden soll und versucht an dem Tag (oder danach) ASYM(SYMS) aus dem Smart-Contract abzurufen. Wurde dies nicht durch den Nutzer gelöscht, erhält die Anwendung ASYM(SYMS)
    11. Die Anwendung kann nun mithilfe von (Private-)ASYMS den Originalschlüssel SYMS wieder herstellen und
    12. damit SYMS(T) entschlüsseln
    13. T wird veröffentlicht

    Zu schützende Geheimnisse sind:

    • ASYMS
    • Adresse / Private-Key für Etherium-Adresse, die berechtiggt ist mit dem Contract zu interagieren

    Selbst falls diese Geheimnisse beide in die gleichen Hände geraten, kann der Text T erst am Tag lt. Smart-Contract wieder hergestellt werden (außer derjenige hat auch 50%+1 Macht in der Etherium-Blockchain :D ). Fehlt eines der beiden Geheimnisse ist T nicht wieder herstellbar.

    Ich kann ja mal in der Idee etwas konkreter werden. In meinem Umfeld habe ich in der Vergangenheit hier und da aus erster und zweiter Hand mitbekommen, dass in öffentlichen Einrichtungen jeglicher Art hier und da mal etwas - sagen wir - nicht ganz korrekt abläuft. Da wird der ausschreibungspflichtige Auftrag mal an Cousin A vergeben und mit Tricks die Ausschreibungspflicht umgangen, dort "leiht" sich der Direktor einer Schule für's Wochenende mal den großen Schulprojektor zum Fußballgucken aus oder die Küchenhilfen in der Gerichtskantine kaufen immer 2 mal so viel ein, um das "übrig gebliebene" Material privat zu nutzen. Also alles so mehr oder minder "schlimme" Sachen.

    Ich fand nun die Idee ganz "lustig", dass es eine "Anlaufstelle" (=Webseite) für Angestellte / Beteiligte gibt, wo sie sich das von der Seele schreiben können und mit größerer Zeitverzögerung veröffentlicht werden. (Ja, keiner weiß, ob die dortig gespeicherten Geschichten echt sind).

    Smart Contracts in Blockchains ermöglichen dir, dass du auf einen Geldbetrag erst nach einem Jahr Zugriff erhälst.

    Bsp.: Etherium, Byteball

    Hab ich auch schon drüber nachgedacht. Ich würde z.B. das Geheimnis symmetrisch verschlüsseln und den Schlüssel in einen smart-contract packen. So ist das secret selbst nicht in der Blockchain und wenn der Contract zerstört wird, kann der Text nicht mehr entschlüsselt werden. Vielleicht sollte ich das weiter verfolgen. Danke für deinen Input

    Hallo in die Runde,

    ich habe schon etwas länger eine Idee für ein Projekt.

    Grob gesagt sollen "Geheimnisse" gespeichert werden und zu einem späteren Zeitpunkt anonym veröffentlich werden. In dieser Zeit von Eingabe des Geheimnisses bis zur Veröffentlichung kann die Person über das aufrufen eines Links das Geheimnis löschen, sodass es nicht veröffentlicht wird. Alternativ periodisch einen Link aufrufen, damit das Geheimnis nicht veröffentlicht wird ("Totmannschalter"-mäßig)

    Da die Geheimnisse potentiell dazu geeignet sind Personen in Bedrängnis zu bringen möchte ich zum einen selber gar nicht wissen wer meine Seite benutzt. Das denke ich würde ich über irgendwelchen wilden Reverse-Proxy-non-logging-Dingsbums ganz gut hinbekommen.

    Mehr Gedanken mache ich mir derzeit wie ich verhindern kann, dass bei einem Hack die unveröffentlichten Geheimnisse gelesen werden können oder weniger drastisch Administratoren diese lesen können. Ich suche nach einer Art "Zukunftsverschlüsselung". Ein bestimmtes verschlüsseltes Geheimnis kann erst NACH einem bestimmten Datum entschlüsselt werden. Wie das mathematisch klappen soll, weiß ich nicht (deshalb gibt es sowas wahrscheinlich auch nicht :D) aber ich dachte ich frag mal in die Runde, ob jemand eine Idee hat.

    Wenn es deine erste Bestellung ist (unabhängig welches Produkt), wird sich mutmaßlich morgen ein Mitarbeiter bei dir melden, um deine Daten zu verifizieren.

    Ansonsten geht das glaube ich (keine Ahnung; und bestimmt abhängig von der TLD), dass das automatisch geht.

    Für die komplette Vertragslaufzeit?

    Nicht nur das. Für alle Umsätze des geworbenen Kunden überhaupt in seiner "Lebenszeit" ( :D )

    Da man bei Aktionsprodukten keine Gutscheine angeben kann und die Gutscheine aus der Bestellung entfernt werden, ist es dann Glück, ob trotzdem die "Werbe"-Verbindung hergestellt wird. Deshalb wurde mal die Möglichkeit von klassischen ref-links geschaffen bei denen man die eigene Kundennummer in die URL packen kann und so ohne Gutschein die "Werbe"-Verbindung hergestellt wird (ist relativ undokumentiert irgendwo in einem Post von [netcup] Felix P. hier im Forum "versteckt") ;)

    Die 25 Euro sind Imho genau dazu da zu verhindern, dass die Aktionsangebote mit niedrigen absoluten laufenden Kosten dauerhaft im "Produktzyklus" bleiben. Niemand kommt auf die Idee z.B. ein 0,19€ p.M. Produkt für 25 Euro zu transferieren.

    Es bleibt also nur die Kündigung bei solch günstigen Produkten, sofern nicht zeitnah ein Einsatzzweck zu erkennen ist. Ich war selbst auch schon oft genug in genau der Situation. Behalten und Warten ist natürlich eine Wette und dieses "unternehmerische Risiko" der Entscheidung wird dir keiner abnehmen können.

    Noch als Disclaimer: Ich kenn mich mit Plesk relativ aus, habe aber selber kein Webhosting hier.

    Wenn du einen neuen Tarif hast (Scheinen die Webhosting 1000 - 8000 zu sein), steht hier wie man den "Dokumentenstamm" findet / ändert: https://www.netcup-wiki.de/wiki/Plesk_Ony…Dokumentenstamm (etwas hochscrollen, da ist ein Bild).

    Diese Eigenschaft müsstest du für deine sub.example.com auf httpdocs/mst stellen.


    Alternativer Ansatz ist eine Weiterleitung von sub.example.com auf die andere Domain zu machen (aber dann steht in der Adressleiste des Browsers diese lange hostingxyz-URL).