Tevens klopt wat jij in het begin zegt ook niet. Er is absoluut geen enkele mogelijke manier waarop mijn algoritme een dubbel resultaat kan krijgen. Daar heb ik rekening mee gehouden met het bouwen. Het is geen complex genoeg algoritme om zo complex te zijn als cryptografie.
Dan is het dus een soort symmetrische encryptie, ongeacht de complexiteit of effectiviteit. ROT13 is dat ook, ondanks dat het triviaal te herkennen en "kraken" is. Het achterstevoren zetten van de invoer is dat ook. Als er geen dubbele resultaten mogelijk zijn en tegelijkertijd dezelfde input met dezelfde key dezelfde output oplevert, moet dat betekenen dat er ook geen enkele informatie verloren gaat in je transformatie-stap, zodat je met zekerheid kan zeggen dat verschillende outputs ook verschillende inputs moeten hebben. Daarmee is het ook triviaal reversibel, iets wat je compleet niet wilt als je met hashing bezig bent (waar het nog steeds op lijkt). En dat hangt dan nog volledig af van hoe je het hebt ontworpen en of je daar geen fouten in hebt gemaakt.
Het is een simpele salt hash
Dat is het dus per definitie niet gelet op je bovenstaand gequotete uitspraak.
Er is verder geen hook, waarmee iemand in deze laag kan komen.
Die hoeft er ook niet per se te zijn om toch informatie uit te laten lekken.
Dus, mocht er weer zoiets gebeuren als bij MD5 (dus collisions berekenen b.v.), krijgt iemand een string terug zoals b.v. "49039~2GF" i.p.v. "mijnwachwtoord" en daar kunnen ze absoluut niets mee, tot ze de formule + key kraken welke ik heb gebruikt om deze te maken.
Wat nou als ik "abcdef" invoer en kijk wat voor hash eruit komt, en daar een collision op bereken? En dat vervolgens een paar keer voor "abcdeg" en "abcdeh" ofzo? Dan kan je daarmee jouw algoritme en key berekenen.
En waar jij stelt dat deze "dubbele waarde" een probleem zou kunnen vormen, zelfs als het wél mogelijk zou zijn, zou het nog steeds geen enkel probleem zijn. Want deze waarde, dubbel of niet, zou nergens gebruikt kunnen worden. Alsin; deze kun je nergens invoeren. Want iedere invoer verwacht een waarde zonder zout.
Als er een dubbele waarde is die uiteindelijk dus dezelfde hash oplevert na al je transformatie-stappen, betekent dat bijvoorbeeld dat een bepaalde user met twee verschillende wachtwoorden in kan loggen. De benodigde tijd om het geheel te kraken is daarmee een stuk korter geworden.
Ik geef toe dat mijn terminologie niet zo sterk is. Dit is voornamelijk omdat ik het zo min mogelijk gebruik en dus al jaren niet meer bij ben blijven houden hoe ze wat nou precies noemen. Dit voornamelijk omdat er nogal eens discussie is geweest over terminologie en ik daar geen behoefte meer aan had.
Die discussie vindt voornamelijk plaats bij mensen die zich niet interesseren in de juiste terminologie, of gewoon geen kennis van zaken hebben. Kennis halen uit actiefilms en matige journalistiek schaar ik onder beide van deze. De terminologie is sinds introductie niet veranderd. Er is een hele wereld van verschil tussen encryptie en hashing en beide termen zijn ontzettend makkelijk uit elkaar te houden. Dat je dat nog steeds niet doet duidt m.i. gewoon op desinteresse en zeker in een discussie niet handig.
Ik blijf het gewoon FTP noemen omdat het in de kern altijd, nog steeds een file transfer protocol is, of daar uiteindelijk op terugvalt. Je kunt het wrappen in 1593932409 lagen en dan de naam veranderen naar 'moving containers' of 'deployment' of allerlei van dat soort prachtige termen, maar puntje bij paaltje is het nog steeds allemaal FTP, enkel met wat extra tussenstappen.
Nee. FTP is een file transfer protocol, ja. Maar een file transfer protocol is
niet FTP. SCP, SFTP en Rsync zijn bijvoorbeeld losstaande protocollen, wezenlijk verschillend van elkaar en van FTP, en wrappen FTP op geen enkele manier. FTPS doet dat dan weer wel, maar volgens mij is dat geen geweldig populair protocol.
Wel wil ik stellen dat jij (en anderen) vol zit met aannames. Zoals o.a. je aanname dat ik iets zou testen met "2 strings" ipv b.v. een string generator te bouwen en meer dan 10 miljoen strings door het ding te jassen precies om het punt wat jij maakt te voorkomen.
Je doet nu zelf allerlei aannames. Mijn punt over "2 strings" was dat je je claims waarschijnlijk getest hebt met X strings (bijvoorbeeld 10 miljoen, maar dat waag ik nog te betwijfelen, ik denk dat 2 dichterbij de waarheid zit), in plaats van dat je je claims wiskundig hebt bewezen waarna testen slechts een formaliteit is om te controleren dat je implementatie de regels van je ontwerp volgt.
De aanname dat het weten gebruiken van de exact juiste terminologie iets betekent over de kwaliteit van wat je maakt.
Nee, inderdaad. Maar het geeft wel ongelofelijk sterke aanwijzingen. Sterker nog: met jouw gebruik van terminologie lijkt het me schier onmogelijk om op een juiste manier studie te doen naar hetgeen waar je mee bezig bent, en daarmee impliceert dat dat zoiets ook nooit gebeurd is. Daarmee trap je vanzelf in alle valkuilen van zelfoverschatting en is de kans op iets wat kwalitatief nog ergens op een of andere schaal scoort behoorlijk minimaal. Al is het alleen maar doordat niemand met kennis van zaken je algoritme heeft beoordeeld. Weer een aanname die ik doe, maar eentje waarvan ik zeker weet dat die waar is. Dit zal ik kracht bijzetten door te vertellen dat ik vroeger ook ooit voor de lol mijn eigen encryptie gemaakt had, waarvan ook het algoritme geheim moest blijven, en waarvan ik dacht dat het vrijwel onkraakbaar was. Het voldeed verder aan alle criteria die jij genoemd hebt. Ik heb daarover een presentatie gehouden binnen het kader van een crypto-college en de professor had zelfs zonder toegang tot de software tijdens de presentatie nog een aantal pijnpunten gegokt(!) waar ik zelf niet aan gedacht had, en hij had gelijk. Met die zaken in het achterhoofd heb ik vervolgens met een medestudent een eigen cryptanalyse gedaan, mijn algoritme helemaal afgeschoten, en een goed punt gekregen voor de analyse. Zonder de opmerkingen van de professor had ik op dat moment die analyse niet fatsoenlijk kunnen doen. Je krijgt in de ontwerpfase namelijk al te maken met ontzettende tunnelvisie omdat je alle aanvalsvectoren die je zelf kan bedenken al hebt afgedekt. Daarna heb ik nooit meer aan dat algoritme gewerkt en ben ik gewoon de gangbare algoritmen en implementaties gaan gebruiken.
De aanname dat ik maar één persoon ben die er aan werkt.
Overal in je post staat "ik" en praat je in enkelvoud. Vind ik geen enorm rare aanname trouwens.
De aanname dat één persoon nooit iets zo complex zou kunnen maken als iets wat op github staat.
Ik weet niet waar ik die aanname gedaan heb, de enige aanname die ik gedaan heb is dat één persoon die op jouw manier claims doet over crypto niet genoeg kennis heeft om te kunnen beoordelen dat hij niet genoeg kennis heeft om dit op een correcte manier zelf te kunnen maken zonder hulp van buitenaf. Overigens lijk je met deze aanname de voorgaande aanname te bevestigen, maar soit.
Even voor de duidelijkheid; Ik ben zeer zeker geen cryptograaf en weet vrij weinig over cryptografie. Maar ik weet meer dan genoeg over websecurity dat mijn producten nog nooit met hacks te maken hebben gehad.
Aanname van mij: jouw producten zijn niet interessant genoeg om naar te kijken.
Ik weet ook dat ik niet alles weet en daarom huur ik white-hats in om lekken in mijn producten te vinden i.p.v. dit zelf te doen.
Als je hiervoor openstaat, zou ik deze white-hats of zeker een cryptograaf dan onder geheimhouding laten kijken naar jouw code zodat ze een oordeel kunnen vellen over de kwaliteit van je algoritme, de toegevoegde waarde ervan en alle voor- en nadelen aan het gebruik. Zeker vanwege de volgende quote van je:
Ik kan niet ontkennen dat ik wel eens custom measures heb gezien die inderdaad zo lek zijn als een mandje en juist gaten creëeren.
Doe ermee wat je wilt.