[ALG] Algoritme om dagnummer te versleutelen (2 weg)

[P_de_B]

We gebruiken in de codering van onze artikelen onder meer het dagnummer van de dag waarop het product geproduceerd is. We willen echter niet dat de klant het nummer kan herleiden naar een dagnummer dus het nummer moet op een of andere manier versleuteld worden.

Het nummer bestaat nu uit drie cijfers 001 t/m 366 en dat moet ook zo blijven, daarnaast moet het eigenlijk niet een sequentieel nummer zijn. Tenslotte moeten wij het nummer natuurlijk wel weer kunnen herleiden naar een dagnummer. We kunnen natuurlijk een lookup tabelletje maken, maar eigenlijk willen we vanuit verschillende applicaties kunnen 'terugrekenen' en niet overal is een database beschikbaar.

Concreet zijn we dus op zoek naar een formule die een dagnummer om kan zetten naar een ander 3 cijferige (semi)willekeurige reeks en ons de mogelijkheid biedt dit nummer weer om te vormen naar een dagnummer.

Iemand een idee, ik kan op dit moment niet iets helders bedenken.

[Apie!]

het simpelste is denk ik het getal omdraaien...(is natuurlijk wel sequentieel)

Eerlijk gezegd snap ik ook niet waarom een klant een artikelnummer niet zou mogen herleiden naar de juliaanse dag waarop het is utigegeven. Als de klant nou gewoon onthoudt (administratie) wanneer een artikel is uitgegeven dan weet ie het toch ook?

[ Voor 75% gewijzigd door Apie! op 04-10-2005 10:45 ]

[ThunderNet]

mmz, de Wortel van dagnummer nemen, en dat x 100?
Simpel terug te rekenen

[RobIII]

XOR het met je verjaardag

[T-MOB]

Even getallen minus 1 en oneven getallen plus een getal groter dan 366?

Er zijn zat vreemde formules te bedenken, toch?

[P_de_B]

Omdraaien is te simpel, en er zit dan ook een regelmaat in. De wortel * 100 is ook niet echt handig. Dat komt nooit op een mooi getal van 3 cijfers uit.

[Apie!]

ehh dat past volgens mij niet allemaal in drie digits...

[JeRa]

Makkelijkst is denk ik een XOR-operatie

Stel, je hebt een productnummer p en een geheime sleutel q. Dan doe je p XOR q om je productnummer te versleutelen, en het resultaat doe je nogmaals XOR q om het originele nummer terug te krijgen

Zie ook deze pagina, bij Bitwise operation.

[RobIII]

P_de_B schreef op dinsdag 04 oktober 2005 @ 10:45:
Omdraaien is te simpel, en er zit dan ook een regelmaat in. De wortel * 100 is ook niet echt handig. Dat komt nooit op een mooi getal van 3 cijfers uit.

Dan zou ik toch gan voor een lookup tabel (desnoods met een Rand met een vaste seed...)
Of vul een array met de cijfers 1/366 en hussel die eenmalig goed door elkaar. Sla die op als lookup...

[ Voor 14% gewijzigd door RobIII op 04-10-2005 10:50 ]

[Apie!]

XOR is volgens mij nog wel het makkelijkst, maar dan moet je natuurlijk wel onthouden wat je "sleutel" is (42 natuurlijk)

[P_de_B]

Apie! schreef op dinsdag 04 oktober 2005 @ 10:41:
het simpelste is denk ik het getal omdraaien...(is natuurlijk wel sequentieel)

Eerlijk gezegd snap ik ook niet waarom een klant een artikelnummer niet zou mogen herleiden naar de juliaanse dag waarop het is utigegeven. Als de klant nou gewoon onthoudt (administratie) wanneer een artikel is uitgegeven dan weet ie het toch ook?

Het gaat om de batchcodering van een artikel niet om het artikelnummer, het gaat te ver om onze overwegingen hier uiteen te zetten, maar ga er maar vanuit dat het wel zinnig is

Een lookup lijstje is lastig omdat zoals gezegd niet in alle applicaties de mogelijkheid is zo'n lijst te raadplegen.

[RobIII]

Apie! schreef op dinsdag 04 oktober 2005 @ 10:50:
XOR is volgens mij nog wel het makkelijkst, maar dan moet je natuurlijk wel onthouden wat je "sleutel" is (42 natuurlijk)

42 is té voor de hand liggend
The secret to life, the universe and everything...

[BertS]

Moet het tussen 001 en 366 blijven? Of mag het 000 t/m 999 zijn?

In het laatste geval:
Stap 1: volgorde omdraaien
Stap 2: elke positie: Indien getal>=5: getal=getal-5, indien getal<5: getal=getal+5

vb: 285
Stap 1: 582
Stap 2: 5 -> 0; 8->3; 2->7
Resultaat: 037

Terugrekenen:
Stap 2: 0+5; 3+5; 7-5 = 582
Stap 1: 285

klant ziet 037, lijkt me redelijk versleuteld tov 285

[ Voor 11% gewijzigd door BertS op 04-10-2005 10:54 ]

[JeRa]

P_de_B schreef op dinsdag 04 oktober 2005 @ 10:51:
[...]

Een lookup lijstje is lastig omdat zoals gezegd niet in alle applicaties de mogelijkheid is zo'n lijst te raadplegen.

Nou, dan pak je toch XOR?

[P_de_B]

Een XOR heeft als nadeel dat er toch nog op bijeenliggende getallen een soort reeks inzit. Afnemers die elke dag van de week bestellen zullen dan juist ten onrechte vermoeden dat het een dagnummer is ben ik bang voor.

Ik zal eens proberen de forumule van bee-es te gebruiken.

[RobIII]

P_de_B schreef op dinsdag 04 oktober 2005 @ 11:12:
Een XOR heeft als nadeel dat er toch nog op bijeenliggende getallen een soort reeks inzit. Afnemers die elke dag van de week bestellen zullen dan juist ten onrechte vermoeden dat het een dagnummer is ben ik bang voor.

Ik zal eens proberen de forumule van bee-es te gebruiken.

XOR de digits los van elkaar
Er zijn toch 1001 manieren te verzinnen om dit te doen?

[P_de_B]

RobIII schreef op dinsdag 04 oktober 2005 @ 11:13:
[...]


Er zijn toch 1001 manieren te verzinnen om dit te doen?

dat weet ik wel, maar ik kom even niet op iets handigs, elke methode die ik bedenk heeft wel weer een nadeel.

[P_de_B]

Ik denk dat we maar (een variant van) de methode van bee-es gebruiken. Die lijkt me wel handig en levert in eerste instantie volgens mij geen problemen op

@Rob, de getallen afzonderlijk XORren lukt ook niet natuurlijk, dan krijg je geen 3 cijferig getal terug.

[RobIII]

P_de_B schreef op dinsdag 04 oktober 2005 @ 11:34:
@Rob, de getallen afzonderlijk XORren lukt ook niet natuurlijk, dan krijg je geen 3 cijferig getal terug.

Maandagdinsdagmorgen....

[ThunderNet]

zo * ThunderNet is even creatief bezig geweest
om een jaar in losse getallen te krijgen ben je 10 bits nodig
(2 bits voor eerste getal) 2 * 4bits bcd voor laatste 2 getallen.

code:

2bits
00 = 0
01 = 1
10 = 2
11 = 3

4bits

0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = 10

stel we hebben een dagnummer: 147

eerste getal 2 bits, geeft bij 1 dus : 01
dan 4 geeft het : 0100
bij 7 : 0111

Dit gaan we achter elkaar samenvoegen zodat we 0101000111 ervan krijgen, echter willen we allemaal BCD's dus zetten we er nog 2x 00 achter
dan krijgen we dit: 010100011100

nu gaan we dit in 3 * 4bits splitsen
0101 0001 1100
5 1 12

zetten we deze getallen om in hexadecimaal krijgen we 51C

willen we de code 51C weer terug rekenen:
5 = 0101
1 = 0001
C = 1100
samen geeft dit 0101 0001 1100
laatste 2 bits weer weghalen: 0101 0001 11

weer groeperen in de begin volgorde: 2bits 4bits 4 bits
krijgen we dus: 01 0100 0111 wat is: 147

misch. beetje omslachtig, maar het werkt wel

[P_de_B]

Hmm, de omdraai functie is ook nog niet perfect.

100 556
101 656
102 756
103 856
104 956
105 056
106 156
107 256
108 356
109 456
110 566

Zit toch nog teveel een reeks in. Hmm, in eerste instantie dacht ik dat dit een makkie zou zijn, maar het valt toch tegen. Het resultaat weer XORren werkt ook niet, dan kom ik incidenteel boven de 999 uit.

EDIT: Hexadecimaal is ook geen optie, de nummers moeten in de range van 000 t/m 999 liggen

[ Voor 12% gewijzigd door P_de_B op 04-10-2005 11:58 ]

[Woy]

Kan je niet iets van Public-key encryption doen? De resultaten daarvan zijn ieder geval niet seqentieel. Omdat je de restultaten met 3 digits wil houden zul je wel moeten zorgen dat n relatief klein blijft ( 999 of kleiner ) en dus zullen je p en q ook klein zijn. Het is dan wel niet echt veilige encryptie maar het bereikt wel precies wat jij wilt. Dat het getal niet meer direct op een dagnummer lijkt.

[Salandur]

Gebruik een combi van de hier gegeven methodes, zolang het veilig is moet dat geen probleem zijn. Uiteindelijk levert het toch altijd een lijstje op dat voor elke dag hetzelfde getalletje genereerd

[ Voor 35% gewijzigd door Salandur op 04-10-2005 13:18 ]

[justmental]

Een combinatie van een paar omkeerbare bewerkingen lijkt me voldoende voor zoiets.
En aangezien je ruimte hebt in je getallen kun je nog een bitje random vullen (bij voorkeur ergens in het midden).
Zelf zou ik waarschijnlijk voor de combinatie bitrotatie, XOR en een vaste waarde optellen gaan.

[T-MOB]

Inderdaad, met een combinatie krijg je een redelijk nietszeggende lijst. Met een -1 op even getallen, een +367 op oneven getallen en een xor met 42 krijg je bijv zoiets (laatste rijtje was om te checken of de undo werkt ;):

code:

# 100 => 505 => 100
# 101 => 78 => 101
# 102 => 511 => 102
# 103 => 76 => 103
# 104 => 509 => 104
# 105 => 66 => 105
# 106 => 499 => 106
# 107 => 64 => 107
# 108 => 497 => 108
# 109 => 70 => 109
# 110 => 503 => 110
# 111 => 68 => 111
# 112 => 501 => 112

Hier de hele lijst en source voor de liefhebber.

[P_de_B]

T-MOB schreef op dinsdag 04 oktober 2005 @ 13:34:
Inderdaad, met een combinatie krijg je een redelijk nietszeggende lijst. Met een -1 op even getallen, een +367 op oneven getallen en een xor met 42 krijg je bijv zoiets (laatste rijtje was om te checken of de undo werkt ;):

code:

# 100 => 505 => 100
# 101 => 78 => 101
# 102 => 511 => 102
# 103 => 76 => 103
# 104 => 509 => 104
# 105 => 66 => 105
# 106 => 499 => 106
# 107 => 64 => 107
# 108 => 497 => 108
# 109 => 70 => 109
# 110 => 503 => 110
# 111 => 68 => 111
# 112 => 501 => 112

Hier de hele lijst en source voor de liefhebber.

Jep, zoiets zal het moeten worden. Er zit nog wel een beetje een reeks in de even en oneven getallen, maar dit moet wel kunnen denk ik.

Dank iedereen voor het meedenken.

[RobIII]

Hussel anders gewoon wat bits door elkaar (wisselen van plek).

[Rukapul]

rwb schreef op dinsdag 04 oktober 2005 @ 11:57:
Kan je niet iets van Public-key encryption doen? De resultaten daarvan zijn ieder geval niet seqentieel. Omdat je de restultaten met 3 digits wil houden zul je wel moeten zorgen dat n relatief klein blijft ( 999 of kleiner ) en dus zullen je p en q ook klein zijn. Het is dan wel niet echt veilige encryptie maar het bereikt wel precies wat jij wilt. Dat het getal niet meer direct op een dagnummer lijkt.

Je aanpak is de beste tot nu toe omdat je min of meer garandeert dat er geen observeerbare structuur inzit en specifieke delta's lastig terug te vinden zijn (itt een directe XOR methode).

Indien je public key toe wilt passen, kies dan in elk geval een publieke sleutel (e) die groot genoeg is zodat ook kleine getallen zodanig verheven worden dat ze door de modulo functie niet herleid kunnen worden tot 'klein getal'. Is er trouwens wel een public/private pair wat binnen de 0-999 range (decimaal, 9 bit binair) blijft?

Overigens zou ik in dit geval eens kijken of je ipv de ad-hoc husselfuncties toch gewoon een (symmetrische) encryptiefunctie kunt gebruiken, zodat je optimaal permuteert en substitueert (basis crypto operaties). Deze zijn per definitie omkeerbaar en de veiligheid berust op een geheime sleutel. Probleem is dat een 9 bit in, 9 bit out met bv 9 bit key algoritme niet zomaar voorhanden is en je niet wilt dat 1-366 bv expandeert naar 0-65536 (of erger). Een streamcipher helpt sowieso niet veel aangezien die precies het nadeel heeft van de XOR functie hierboven. Een andere reden om deze weg niet in te slaan is dat het nogal overkill is: de ciphers gebruiken substitutietabellen/-functies die meer ruimte innemen dan het opslaan van een tabel in TS geval

[ Voor 15% gewijzigd door Rukapul op 04-10-2005 14:40 ]

[P_de_B]

Rukapul schreef op dinsdag 04 oktober 2005 @ 14:27:
[...]

duidelijk verhaal

Op zich heb je gelijk, maar het is de bedoeling dat het nummer voor de 'toevallige' kijker niet direct herleidbaar is naar een dag van het jaar. Het is niet zo'n probleem dat een code eenvoudig te kraken is als je alle waardes weet. Ze gaan toch niet onze batchcodering bruteforcen denk ik.

Een redelijke husseling als hierboven beschreven is in principe voldoende. Al heeft het zoeken naar een public key oplossing wel mijn interesse gewekt. Dat is echter iets waar ik eens rustig voor moet gaan zittten denk ik

[Olaf van der Spek]

Zie 1 - 366 als 9 bits (0 - 511) en voer op de bits een permutatie (bit 0 -> bit 7, bit 1 -> bit 3, etc) uit. Combineer dat eventueel met xor.

[ Voor 16% gewijzigd door Olaf van der Spek op 04-10-2005 14:40 ]

[Woy]

Rukapul schreef op dinsdag 04 oktober 2005 @ 14:27:
[...]
Indien je public key toe wilt passen, kies dan in elk geval een publieke sleutel (e) die groot genoeg is zodat ook kleine getallen zodanig verheven worden dat ze door de modulo functie niet herleid kunnen worden tot 'klein getal'. Is er trouwens wel een public/private pair wat binnen de 0-999 range (decimaal) blijft?

Ja die bestaat wel. het is namenlijk zo dat n = p * q.
p en q zijn de initele priem getallen die je kiest waar je encryptie op berust. daarna gaan alle berekeningen modulo n dus als je zorgt dat p * q onder de 999 blijft dan zit je goed. Omdat je zulke kleine getallen hebt is je encryptie wel relatief makkelijk brute force te kraken maar je weet ieder geval zeker dat er geen "volgorde" in je getallen zit.

Aan de hand van p en q kan je dan je public en private key berekenen ( in jouw geval kan je die natuurlijk beide private houden maar je hebt de private key weer nodig om terug te kunnen rekenen ).

RSA encryptie

hier staat de theorie redelijk duidelijk uitgelegd. het is helemaal niet zo heel erg ingewikkeld om zelf te maken.

[ Voor 7% gewijzigd door Woy op 04-10-2005 14:41 ]

[P_de_B]

rwb schreef op dinsdag 04 oktober 2005 @ 14:40:
[...]

Ja die bestaat wel. het is namenlijk zo dat n = p * q.
p en q zijn de initele priem getallen die je kiest waar je encryptie op berust. daarna gaan alle berekeningen modulo n dus als je zorgt dat p * q onder de 999 blijft dan zit je goed. Omdat je zulke kleine getallen hebt is je encryptie wel relatief makkelijk brute force te kraken maar je weet ieder geval zeker dat er geen "volgorde" in je getallen zit.

Aan de hand van p en q kan je dan je public en private key berekenen.

RSA encryptie

hier staat de theorie redelijk duidelijk uitgelegd. het is helemaal niet zo heel erg ingewikkeld om zelf te maken.

Jep, met die Wiki link was ik ook aan de slag, en het is inderdaad niet erg moeilijk.

[Rukapul]

rwb schreef op dinsdag 04 oktober 2005 @ 14:40:

Ja, de basis snap ik wel Punt is even dat je modulo n moet gaan rekenen en dat n tussen 366 en 999 moet liggen, wat het aantal mogelijkheden voor p en q nogal reduceert

edit: 999 ipv 512

[ Voor 88% gewijzigd door Rukapul op 04-10-2005 14:57 ]

[Woy]

mwaoh er zijn wel een aantal mogenlijkheden hoor

b.v. p=17 en q=47

deze heb ik even uit mijn hoofd. Voor echte encryptie zijn er idd veel te weinig mogenlijkheden maar daar gaat het hier natuurlijk niet om

[edit]
er zijn trouwens 127 mogenlijke p en q's die aan die voorwaarde voldoen.

[ Voor 17% gewijzigd door Woy op 04-10-2005 15:22 ]

[H!GHGuY]

waarom ziet iedereen nu toch die 3 getalletjes als zijnde afgebakend van elkaar ?

als je nu eens de laatste 4 bits van het eerste getal neemt samen met de eerste 4 bits van het volgende, en je op die manier wat creatief bezighoudt, kun je wel iets moois inmekaar timmeren dmv XOR, (5-x) enz enz

[ThunderNet]

HIGHGuY schreef op dinsdag 04 oktober 2005 @ 16:18:
waarom ziet iedereen nu toch die 3 getalletjes als zijnde afgebakend van elkaar ?

als je nu eens de laatste 4 bits van het eerste getal neemt samen met de eerste 4 bits van het volgende, en je op die manier wat creatief bezighoudt, kun je wel iets moois inmekaar timmeren dmv XOR, (5-x) enz enz

Waar ik net tegen aan liep, creatief met nibbles loop je al snel tegen het feit aan dat je Hexadecimaal wil gebruiken als eind-resultaat... wat dus helaas niet kan

[Olaf van der Spek]

HIGHGuY schreef op dinsdag 04 oktober 2005 @ 16:18:
waarom ziet iedereen nu toch die 3 getalletjes als zijnde afgebakend van elkaar ?

[rml]OlafvdSpek in "[ ALG] Algoritme om dagnummer te versleut..."[/rml]

[Soultaker]

Moet het gecodeerde getal nu wel of niet tussen 1 en 366 liggen?

edit:
Hier stond een suggestie die eigenlijk niet zo slim was.

[ Voor 92% gewijzigd door Soultaker op 04-10-2005 17:06 ]

[Woy]

Soultaker schreef op dinsdag 04 oktober 2005 @ 17:04:
Moet het gecodeerde getal nu wel of niet tussen 1 en 366 liggen?

edit:
Hier stond een suggestie die eigenlijk niet zo slim was.

Het hoeft volgens mij niet perse tussen 1 en 366 te liggen. Maar het is wel de bedoeling dat het een 3 cijferig getal blijft dus effectief tussen de 0 en 1000

[P_de_B]

rwb schreef op dinsdag 04 oktober 2005 @ 17:12:
[...]

Het hoeft volgens mij niet perse tussen 1 en 366 te liggen. Maar het is wel de bedoeling dat het een 3 cijferig getal blijft dus effectief tussen de 0 en 1000

Correct

[RobIII]

Visual Basic 6:

Private Function EncDecode(iDayNum As Integer) As Integer
    EncDecode = (iDayNum And &HFF00) + ((Not CByte((iDayNum And &HFF))) Xor &HAA)
End Function

Output:

code:

   1 ==>   84   |      2 ==>   87   |      3 ==>   86   |   
   4 ==>   81   |      5 ==>   80   |      6 ==>   83   |   
   7 ==>   82   |      8 ==>   93   |      9 ==>   92   |   
  10 ==>   95   |     11 ==>   94   |     12 ==>   89   |   
  13 ==>   88   |     14 ==>   91   |     15 ==>   90   |   
  16 ==>   69   |     17 ==>   68   |     18 ==>   71   |   
  19 ==>   70   |     20 ==>   65   |     21 ==>   64   |   
  22 ==>   67   |     23 ==>   66   |     24 ==>   77   |   
  25 ==>   76   |     26 ==>   79   |     27 ==>   78   |   
  28 ==>   73   |     29 ==>   72   |     30 ==>   75   |   
  31 ==>   74   |     32 ==>  117   |     33 ==>  116   |   
  34 ==>  119   |     35 ==>  118   |     36 ==>  113   |   
  37 ==>  112   |     38 ==>  115   |     39 ==>  114   |   
  40 ==>  125   |     41 ==>  124   |     42 ==>  127   |   
  43 ==>  126   |     44 ==>  121   |     45 ==>  120   |   
  46 ==>  123   |     47 ==>  122   |     48 ==>  101   |   
  49 ==>  100   |     50 ==>  103   |     51 ==>  102   |   
  52 ==>   97   |     53 ==>   96   |     54 ==>   99   |   
  55 ==>   98   |     56 ==>  109   |     57 ==>  108   |   
  58 ==>  111   |     59 ==>  110   |     60 ==>  105   |   
  61 ==>  104   |     62 ==>  107   |     63 ==>  106   |   
  64 ==>   21   |     65 ==>   20   |     66 ==>   23   |   
  67 ==>   22   |     68 ==>   17   |     69 ==>   16   |   
  70 ==>   19   |     71 ==>   18   |     72 ==>   29   |   
  73 ==>   28   |     74 ==>   31   |     75 ==>   30   |   
  76 ==>   25   |     77 ==>   24   |     78 ==>   27   |   
  79 ==>   26   |     80 ==>    5   |     81 ==>    4   |   
  82 ==>    7   |     83 ==>    6   |     84 ==>    1   |   
  85 ==>    0   |     86 ==>    3   |     87 ==>    2   |   
  88 ==>   13   |     89 ==>   12   |     90 ==>   15   |   
  91 ==>   14   |     92 ==>    9   |     93 ==>    8   |   
  94 ==>   11   |     95 ==>   10   |     96 ==>   53   |   
  97 ==>   52   |     98 ==>   55   |     99 ==>   54   |   
 100 ==>   49   |    101 ==>   48   |    102 ==>   51   |   
 103 ==>   50   |    104 ==>   61   |    105 ==>   60   |   
 106 ==>   63   |    107 ==>   62   |    108 ==>   57   |   
 109 ==>   56   |    110 ==>   59   |    111 ==>   58   |   
 112 ==>   37   |    113 ==>   36   |    114 ==>   39   |   
 115 ==>   38   |    116 ==>   33   |    117 ==>   32   |   
 118 ==>   35   |    119 ==>   34   |    120 ==>   45   |   
 121 ==>   44   |    122 ==>   47   |    123 ==>   46   |   
 124 ==>   41   |    125 ==>   40   |    126 ==>   43   |   
 127 ==>   42   |    128 ==>  213   |    129 ==>  212   |   
 130 ==>  215   |    131 ==>  214   |    132 ==>  209   |   
 133 ==>  208   |    134 ==>  211   |    135 ==>  210   |   
 136 ==>  221   |    137 ==>  220   |    138 ==>  223   |   
 139 ==>  222   |    140 ==>  217   |    141 ==>  216   |   
 142 ==>  219   |    143 ==>  218   |    144 ==>  197   |   
 145 ==>  196   |    146 ==>  199   |    147 ==>  198   |   
 148 ==>  193   |    149 ==>  192   |    150 ==>  195   |   
 151 ==>  194   |    152 ==>  205   |    153 ==>  204   |   
 154 ==>  207   |    155 ==>  206   |    156 ==>  201   |   
 157 ==>  200   |    158 ==>  203   |    159 ==>  202   |   
 160 ==>  245   |    161 ==>  244   |    162 ==>  247   |   
 163 ==>  246   |    164 ==>  241   |    165 ==>  240   |   
 166 ==>  243   |    167 ==>  242   |    168 ==>  253   |   
 169 ==>  252   |    170 ==>  255   |    171 ==>  254   |   
 172 ==>  249   |    173 ==>  248   |    174 ==>  251   |   
 175 ==>  250   |    176 ==>  229   |    177 ==>  228   |   
 178 ==>  231   |    179 ==>  230   |    180 ==>  225   |   
 181 ==>  224   |    182 ==>  227   |    183 ==>  226   |   
 184 ==>  237   |    185 ==>  236   |    186 ==>  239   |   
 187 ==>  238   |    188 ==>  233   |    189 ==>  232   |   
 190 ==>  235   |    191 ==>  234   |    192 ==>  149   |   
 193 ==>  148   |    194 ==>  151   |    195 ==>  150   |   
 196 ==>  145   |    197 ==>  144   |    198 ==>  147   |   
 199 ==>  146   |    200 ==>  157   |    201 ==>  156   |   
 202 ==>  159   |    203 ==>  158   |    204 ==>  153   |   
 205 ==>  152   |    206 ==>  155   |    207 ==>  154   |   
 208 ==>  133   |    209 ==>  132   |    210 ==>  135   |   
 211 ==>  134   |    212 ==>  129   |    213 ==>  128   |   
 214 ==>  131   |    215 ==>  130   |    216 ==>  141   |   
 217 ==>  140   |    218 ==>  143   |    219 ==>  142   |   
 220 ==>  137   |    221 ==>  136   |    222 ==>  139   |   
 223 ==>  138   |    224 ==>  181   |    225 ==>  180   |   
 226 ==>  183   |    227 ==>  182   |    228 ==>  177   |   
 229 ==>  176   |    230 ==>  179   |    231 ==>  178   |   
 232 ==>  189   |    233 ==>  188   |    234 ==>  191   |   
 235 ==>  190   |    236 ==>  185   |    237 ==>  184   |   
 238 ==>  187   |    239 ==>  186   |    240 ==>  165   |   
 241 ==>  164   |    242 ==>  167   |    243 ==>  166   |   
 244 ==>  161   |    245 ==>  160   |    246 ==>  163   |   
 247 ==>  162   |    248 ==>  173   |    249 ==>  172   |   
 250 ==>  175   |    251 ==>  174   |    252 ==>  169   |   
 253 ==>  168   |    254 ==>  171   |    255 ==>  170   |   
 256 ==>  341   |    257 ==>  340   |    258 ==>  343   |   
 259 ==>  342   |    260 ==>  337   |    261 ==>  336   |   
 262 ==>  339   |    263 ==>  338   |    264 ==>  349   |   
 265 ==>  348   |    266 ==>  351   |    267 ==>  350   |   
 268 ==>  345   |    269 ==>  344   |    270 ==>  347   |   
 271 ==>  346   |    272 ==>  325   |    273 ==>  324   |   
 274 ==>  327   |    275 ==>  326   |    276 ==>  321   |   
 277 ==>  320   |    278 ==>  323   |    279 ==>  322   |   
 280 ==>  333   |    281 ==>  332   |    282 ==>  335   |   
 283 ==>  334   |    284 ==>  329   |    285 ==>  328   |   
 286 ==>  331   |    287 ==>  330   |    288 ==>  373   |   
 289 ==>  372   |    290 ==>  375   |    291 ==>  374   |   
 292 ==>  369   |    293 ==>  368   |    294 ==>  371   |   
 295 ==>  370   |    296 ==>  381   |    297 ==>  380   |   
 298 ==>  383   |    299 ==>  382   |    300 ==>  377   |   
 301 ==>  376   |    302 ==>  379   |    303 ==>  378   |   
 304 ==>  357   |    305 ==>  356   |    306 ==>  359   |   
 307 ==>  358   |    308 ==>  353   |    309 ==>  352   |   
 310 ==>  355   |    311 ==>  354   |    312 ==>  365   |   
 313 ==>  364   |    314 ==>  367   |    315 ==>  366   |   
 316 ==>  361   |    317 ==>  360   |    318 ==>  363   |   
 319 ==>  362   |    320 ==>  277   |    321 ==>  276   |   
 322 ==>  279   |    323 ==>  278   |    324 ==>  273   |   
 325 ==>  272   |    326 ==>  275   |    327 ==>  274   |   
 328 ==>  285   |    329 ==>  284   |    330 ==>  287   |   
 331 ==>  286   |    332 ==>  281   |    333 ==>  280   |   
 334 ==>  283   |    335 ==>  282   |    336 ==>  261   |   
 337 ==>  260   |    338 ==>  263   |    339 ==>  262   |   
 340 ==>  257   |    341 ==>  256   |    342 ==>  259   |   
 343 ==>  258   |    344 ==>  269   |    345 ==>  268   |   
 346 ==>  271   |    347 ==>  270   |    348 ==>  265   |   
 349 ==>  264   |    350 ==>  267   |    351 ==>  266   |   
 352 ==>  309   |    353 ==>  308   |    354 ==>  311   |   
 355 ==>  310   |    356 ==>  305   |    357 ==>  304   |   
 358 ==>  307   |    359 ==>  306   |    360 ==>  317   |   
 361 ==>  316   |    362 ==>  319   |    363 ==>  318   |   
 364 ==>  313   |    365 ==>  312   |    366 ==>  315   |

Functie kan aangeroepen worden met een parameter (dagnummer). De uitkomst kan er weer in gestopt worden om het origineel terug te rekenen.

Zo maar even wat uit de losse pols geklooid en uit mijn duim gezogen...

Edit:
En voor de gein mijn C# eens geoefend (C# noob hier):

C#:

private static int encDecode(int iDayNum) 
{
  return (int)(iDayNum & 0xFF00) + (((byte)~(iDayNum & 0xFF)) ^ 0xAA);
}

Zelfde functie dus, maar nu in C#

[ Voor 69% gewijzigd door RobIII op 04-10-2005 18:19 ]

[Confusion]

P_de_B schreef op dinsdag 04 oktober 2005 @ 10:39:
We gebruiken in de codering van onze artikelen onder meer het dagnummer van de dag waarop het product geproduceerd is. We willen echter niet dat de klant het nummer kan herleiden naar een dagnummer dus het nummer moet op een of andere manier versleuteld worden.

offtopic:
Je hebt al geprobeerd om mensen uit het hoofd te praten dat het belangrijk is dat dagnummer geheim te houden? Als een klant erachterkomt dat die driecijferige code een versleuteld dagnummer is, zal hij alleen maar denken dat hij belazerd wordt en waarschijnlijk terecht?

[H!GHGuY]

wat ik bedoelde was:
stel dat je volgend nummer hebt:

code:

0000 0010 0110 1001
 2      6      9
of 
0000 0001 0000 1101

je kunt nu dus individuele nibbles verwisselen van plaats of zelfs paren/individuele bits verwisselen
daarna nog wat extra operaties en niemand zal ook nog maar iets verstaan van je codes.

eventueel kun je eens zoeken op FAT12. daarin wordt ook een mooie codering gebruikt met nibbles.

[ Voor 55% gewijzigd door H!GHGuY op 04-10-2005 19:24 ]

[P_de_B]

Confusion schreef op dinsdag 04 oktober 2005 @ 18:43:
[...]

offtopic:
Je hebt al geprobeerd om mensen uit het hoofd te praten dat het belangrijk is dat dagnummer geheim te houden? Als een klant erachterkomt dat die driecijferige code een versleuteld dagnummer is, zal hij alleen maar denken dat hij belazerd wordt en waarschijnlijk terecht?

offtopic:
Ik kan me voorstellen wat je bedoelt, maar het is niet wat je denkt. Ik wil het je gerust uitleggen, maar niet op een forum

[P_de_B]

Voor de anderen, ik heb inmiddels een afdoende oplossing gevonden, dus daar hoeven jullie het niet meer om te doen. Ik vind het echter wel interessant om te zien welke oplossingen er nog meer zijn. Nogmaals mijn dank aan iedereen

[Woy]

Als je met bits gaat spelen zoals RobIII als voorbeeld geeft kun je denk beter alle bits van plek verwisselen met een mapping. Dan krijg je wat meer "Random" verdeelde waardes. Anders lijkt het nog steeds op een serie. Je hebt 9 bruikbare bits ( 512 values ) dus dan zou je ongeveer zoiets kunnen doen

C#:

public int[] mapping = new int[]{ 8, 6, 1, 5, 7, 4, 3, 2, 0 };

public bool IsBitSet( int val, int bitNum )
{
    return (val & ( 1 << bitNum )) > 0;
}

public int Encode( int val )
{
    int retVal = 0;
    for( int i=0; i < mapping.Length; i++ )
    {
        if( IsBitSet( val, i ) )
        {
            retVal |= 1 << mapping[ i ];
        }
    }
    return retVal;
}

public int Decode( int val )
{
    int retVal = 0;
    for( int i=0; i < mapping.Length; i++ )
    {
        if( IsBitSet( val, mapping[ i ] ) )
        {
            retVal |= 1 << i;
        }
    }
    return retVal;
}

Deze code heb ik even snel getypt dus zal niet perfect zijn. Maar het idee is denk duidelijk. Hiermee krijg je nog redelijk "Random" waarden.

P_de_B schreef op dinsdag 04 oktober 2005 @ 19:42:
Voor de anderen, ik heb inmiddels een afdoende oplossing gevonden, dus daar hoeven jullie het niet meer om te doen. Ik vind het echter wel interessant om te zien welke oplossingen er nog meer zijn. Nogmaals mijn dank aan iedereen

Wat heb je uiteindelijk als oplossing gekozen?

[ Voor 20% gewijzigd door Woy op 04-10-2005 19:46 ]

[Rukapul]

RobIII schreef op dinsdag 04 oktober 2005 @ 17:56:

Visual Basic 6:

Private Function EncDecode(iDayNum As Integer) As Integer
    EncDecode = (iDayNum And &HFF00) + ((Not CByte((iDayNum And &HFF))) Xor &HAA)
End Function

Output:

Zo maar even wat uit de losse pols geklooid en uit mijn duim gezogen...

En het resultaat is er ook naar Er zit veel teveel structuur tussen input en output. Plot de input maar eens tegen de output en je ziet duidelijk een structuur terugkomen.

Als iemand even uitlegt hoe ik bitwise operators in excel doe dan post ik wel een plotje

P_de_B schreef op dinsdag 04 oktober 2005 @ 19:42:
Voor de anderen, ik heb inmiddels een afdoende oplossing gevonden, dus daar hoeven jullie het niet meer om te doen. Ik vind het echter wel interessant om te zien welke oplossingen er nog meer zijn. Nogmaals mijn dank aan iedereen

Welke oplossing heb je nou gekozen of zelfbedacht?

Edit: rwb was een paar seconden sneller

rwb schreef op dinsdag 04 oktober 2005 @ 19:45:
Als je met bits gaat spelen zoals RobIII als voorbeeld geeft kun je denk beter alle bits van plek verwisselen met een mapping. Dan krijg je wat meer "Random" verdeelde waardes. Anders lijkt het nog steeds op een serie. Je hebt 9 bruikbare bits ( 512 values ) dus dan zou je ongeveer zoiets kunnen doen

Deze code heb ik even snel getypt dus zal niet perfect zijn. Maar het idee is denk duidelijk. Hiermee krijg je nog redelijk "Random" waarden.

Sowieso moet je bij een bitwise mapping permuteren (bitten wisselen) en substitueren (xoren). Een blockcipher doet niet anders, maar dan op een 'goede' manier.

Kwa elegantie vind ik de RSA methode overigens het netst. Die heeft bovendien als voordeel dat je onder bepaalde aannames wiskundig aan kunt nemen dat er geen overduidelijke structuur inzit (dan zou je namelijk waarschijnlijk ook efficient kunnen factoriseren ). Combinaties van meerdere methoden zijn ook mogelijk.

[ Voor 35% gewijzigd door Rukapul op 04-10-2005 19:54 ]

[P_de_B]

Rukapul schreef op dinsdag 04 oktober 2005 @ 19:48:


[...]

Welke oplossing heb je nou gekozen of zelfbedacht?

[rml]P_de_B in "[ ALG] Algoritme om dagnummer te versleut..."[/rml] zoals het nu lijkt, maar als ik nog wat meer tijd heb wil ik eigenlijk de laatste suggestie van rwb gaan toepassen.

[TD-er]

Tijdens het lezen van dit topic zat ik ook even te mijmeren.
je wilt 1-366 coderen in 3 cijfers.
Wat je dus kunt doen is het in 9 of 10 bits encoderen.
Kortom je hebt wat ruimte over om je getal aan te vullen met 0-en en 1-tjes op zo'n manier dat het als een soort van checksum fungeert. (bijv een bitje per 4 bits om het aantal 1-tjes even te maken)
Op die manier krijg je dus een beperkte reeks bitpatronen (minder dan 1024 geldige patronen)
Door dan ook nog de bitjes door elkaar te husselen, krijg je voldoende random-achtig gedrag.
Wanneer je dan een beetje handig de bitjes husselt, kun je waarschijnlijk zelfs voorkomen dat er getallen boven de 999 uitkomen, bij de inputrange van 1-366.

Het nadeel van de eerder geopperde random-reeks met vaste seed zal gemiddeld zo'n 180 lookups kosten om te kijken welk rangnummer een bepaalde combinatie heeft.

[Rukapul]

TD-er schreef op dinsdag 04 oktober 2005 @ 20:13:
Tijdens het lezen van dit topic zat ik ook even te mijmeren.
je wilt 1-366 coderen in 3 cijfers.
Wat je dus kunt doen is het in 9 of 10 bits encoderen.
Kortom je hebt wat ruimte over om je getal aan te vullen met 0-en en 1-tjes op zo'n manier dat het als een soort van checksum fungeert. (bijv een bitje per 4 bits om het aantal 1-tjes even te maken)
Op die manier krijg je dus een beperkte reeks bitpatronen (minder dan 1024 geldige patronen)
Door dan ook nog de bitjes door elkaar te husselen, krijg je voldoende random-achtig gedrag.
Wanneer je dan een beetje handig de bitjes husselt, kun je waarschijnlijk zelfs voorkomen dat er getallen boven de 999 uitkomen, bij de inputrange van 1-366.

Als je zoiets wilt dan is het beter om een non-deterministische random bit te kiezen dan een deterministische checksum. In cryptografie probeer je de entropie te verhogen en de redundantie te minimaliseren.

Overigens heb je slechts 9 output bits tot je beschikking door de harde eis van 0-999 decimaal. Zou je er bijvoorbeeld 10 hebben dan zou je 1 bit toe kunnen voegen. Deze 10 bits mappen dan op 10 andere bits, en bij het terugrekenen gooi je het betreffende random bit weg. Het voordeel hiervan is dat elke input nu op meerdere (2 ) outputs kan mappen, wat analyse kan bemoeilijken. Om de ruimte 367-999 te gebruiken met een bitwise methode lijkt me een drama worden. Extra bits toevoegen kan namelijk alleen onder de voorwaarde dat na de coderingsfunctie het resultaat kleiner is dan 1000, wat er op neerkomt dat je bit 10 (512) conditioneel zet, maar bij een goede coderingsfunctie betekent dat je dat per keer uit moet proberen (of een lookup tabel ).

[MSalters]

P_de_B schreef op dinsdag 04 oktober 2005 @ 10:51:
Een lookup lijstje is lastig omdat zoals gezegd niet in alle applicaties de mogelijkheid is zo'n lijst te raadplegen.

Onzin, dat weet je zelf ook. Als je in zo'n applicatie een algoritme kunt opnemen, dan kan een lookup table ook. En als je geen algoritme in die applicaties kan opnemen, dan klopt je TS niet.
( Een lookup is logisch equivalent aan een if-tree maar heeft complexiteit O(1) ipv O(N) of O(logN) )

[RobIII]

Rukapul schreef op dinsdag 04 oktober 2005 @ 19:48:
En het resultaat is er ook naar Er zit veel teveel structuur tussen input en output. Plot de input maar eens tegen de output en je ziet duidelijk een structuur terugkomen.

Voor zover ik het begreep ging het er om dat de "average Joe" niet kon achterhalen welk dagnummer het was. En de "average Joe" gaat aan deze "structuur" écht niet herkennen wat er gaande is. Het plebs, om het zo maar eens even te noemen, zal nog nooit hebben gehoord van een XOR en wellicht al moeite hebben met het concept "versleuteling" (met alle respect voor alle non-nerds). Dat een tweaker hier iets uit zou kunnen herleiden wil ik al met moeite accepteren (a.d.h.v.alleen de output), laat staan een non-nerd. Misschien moet je je eens onder andere mensen begeven* Desalniettemin zal iemand die écht er voor gaat zitten er geheid uit komen, dat zal ik ook niet ontkennen. Het ging mij dus om een "huis-tuin-en-keuken" *kuch*versleuteling*kuch* by-obscurity En nogmaals, dit is maar in 5 minuten uit mijn duim gezogen.
* _{<geintje en niet lullig bedoeld hoor >}

Rukapul schreef op dinsdag 04 oktober 2005 @ 19:48:
Als iemand even uitlegt hoe ik bitwise operators in excel doe dan post ik wel een plotje

Excel kent gewoon VBA en je kunt die code dus gewoon copy/pasten in een macro hoor Heb ik zojuist ook gedaan voor bovenstaand grafiekje.

[ Voor 24% gewijzigd door RobIII op 05-10-2005 01:30 ]

[TD-er]

Rukapul schreef op dinsdag 04 oktober 2005 @ 20:59:
[...]

Als je zoiets wilt dan is het beter om een non-deterministische random bit te kiezen dan een deterministische checksum. In cryptografie probeer je de entropie te verhogen en de redundantie te minimaliseren.

Overigens heb je slechts 9 output bits tot je beschikking door de harde eis van 0-999 decimaal. Zou je er bijvoorbeeld 10 hebben dan zou je 1 bit toe kunnen voegen. Deze 10 bits mappen dan op 10 andere bits, en bij het terugrekenen gooi je het betreffende random bit weg. Het voordeel hiervan is dat elke input nu op meerdere (2 ) outputs kan mappen, wat analyse kan bemoeilijken. Om de ruimte 367-999 te gebruiken met een bitwise methode lijkt me een drama worden. Extra bits toevoegen kan namelijk alleen onder de voorwaarde dat na de coderingsfunctie het resultaat kleiner is dan 1000, wat er op neerkomt dat je bit 10 (512) conditioneel zet, maar bij een goede coderingsfunctie betekent dat je dat per keer uit moet proberen (of een lookup tabel ).

prima dat je niet-deterministische codering wilt gebruiken, maar dan sta je dus toe dat er meerdere mogelijke input-waarden geaccepteerd gaan worden. (hooguit een factor 2.8 in dit geval, namelijk bijna anderhalve bit)
Is dat acceptabel voor iets grotere strings?
Dan neemt de kans op per ongeluk geaccepteerde strings redelijk toe lijkt mij.
Maar goed, ik snap het punt van reverse-engineering wel.

[P_de_B]

MSalters schreef op dinsdag 04 oktober 2005 @ 23:19:
[...]

Onzin, dat weet je zelf ook. Als je in zo'n applicatie een algoritme kunt opnemen, dan kan een lookup table ook. En als je geen algoritme in die applicaties kan opnemen, dan klopt je TS niet.
( Een lookup is logisch equivalent aan een if-tree maar heeft complexiteit O(1) ipv O(N) of O(logN) )

Mja mogelijk is het misschien wel, maar ik ging steeds uit van een database oplossingen (een tabel met random waardes vullen), ik denk niet van een lookup die jij bedoelt.

Ik wil graag de mogelijkheid hebben om een algoritme te implementeren zonder dat ik de waardes uit de tabel moet meenemen. Daarnaast viel het mij in eerste instantie tegen terwijl ik had gedacht dat het super eenvoudig zou zijn.

[ Voor 19% gewijzigd door P_de_B op 05-10-2005 07:47 ]

[Reptile209]

Hou je er wel rekening mee, dat met de algo's die hier genoemd worden, de klant elk jaar dezelfde nummers weer ziet? Dus een bestelling op 5 okt 05 en 5 okt 06 zou hetzelfde nummer krijgen. Wellicht valt er dan toch wat voor te zeggen om elk jaar op 31 december een random lookup tabel te genereren, dan is het ook in de tijd random .

[Rukapul]

MSalters wel een punt: voor ca 2kB heb je twee hardcoded arrays n je sourcecode die exact hetzelfde doet. Een argument voor een functie zou parametrisatie kunnen zijn om over tijd te varieren of indien er in de toekomst meer 3 cijferige velden gecodeerd moeten worden..

RobIII schreef op woensdag 05 oktober 2005 @ 01:24:
[...]

[afbeelding]
Voor zover ik het begreep ging het er om dat de "average Joe" niet kon achterhalen welk dagnummer het was.
[...]
En nogmaals, dit is maar in 5 minuten uit mijn duim gezogen.
* _{<geintje en niet lullig bedoeld hoor >}

* Rukapul schuldt maar weer eens meewarig naar een klassiek voorbeeld van not-invented(/programmed)-in-my-cubicle houding met slechte resultaten als gevolg.

Edit: de figuur laat duidelijk zien dat een vrijwel volkomen lineaire functie is met een klein beetje ruis, wat vrijwel volgens elke maatstaf voor dit probleem geen acceptabele oplossing is. (Mensen zijn zeer goed in het ontdekken van lineaire verbanden. Dit terwijl bitwise operaties in beginsel niet lineaire effecten hebben. Dit algoritme is dus in vrijwel elk opzicht slecht.)

TD-er schreef op woensdag 05 oktober 2005 @ 02:04:

Dan neemt de kans op per ongeluk geaccepteerde strings redelijk toe lijkt mij.
Maar goed, ik snap het punt van reverse-engineering wel.

Integriteitscontrole kun je beter over de gecodeerde string (als deel of geheel) uitvoeren dan redundantie in de input stoppen Overigens was ik er vanuit gegaan dat het hele productcode wel een integriteitsverificatiecode zou bevatten.

[ Voor 14% gewijzigd door Rukapul op 05-10-2005 09:13 ]

[RobIII]

Rukapul schreef op woensdag 05 oktober 2005 @ 08:56:
Edit: de figuur laat duidelijk zien dat een vrijwel volkomen lineaire functie is met een klein beetje ruis, wat vrijwel volgens elke maatstaf voor dit probleem geen acceptabele oplossing is. (Mensen zijn zeer goed in het ontdekken van lineaire verbanden. Dit terwijl bitwise operaties in beginsel niet lineaire effecten hebben. Dit algoritme is dus in vrijwel elk opzicht slecht.)

Hoor je jezelf nu?
Nogmaals, denk je nou echt dat "Average Joe" aan de hand van (waarschijnlijk maar een gedeelte van) de output kan achterhalen waar het over gaat? Denk je nou echt dat average joe enig idee heeft van linieaire functies? Sterker: Als je het zo goed weet heb ik nog wel wat output voor je, mag jij me vertellen welke dagnummers er bij horen. We hebben het hier, gegeven de topicstart, niet over cryptografie, maar over "getalletjes husselen". Tjeez...
Nogmaals, het gaat hier niet om een super-safe weet-ik-het-wat Pentagon-unbreakable codering ofzo. Granted, mijn *kuch*ideetje*kuch* is écht niet moeders mooiste. En om eerlijk te zijn had ik inderdaad wel wat "wildere" resultaten verwacht toen ik dit gedrocht uit mijn duim zoog. Maar WTF heeft dat te maken met een "not-invented-here" syndroom? Als je meteen naar een RSA moet grijpen om zo'n basic futiliteit op te lossen heb je imho alleen maar een gebrek aan fantasie of last van een behoorlijke paranoia. Maar goed, als je weer eens uit je ivoren toren komt kunnen we misschien eens verder babbelen.

Overigens, een (nee, misschien niet "de") implementatie van RSA is o.a. hier te vinden (om het even langs mijn functie te houden). Vind je het niet een beetje overkill voor zoiets onzinnigs?

[ Voor 20% gewijzigd door RobIII op 05-10-2005 10:51 ]

[Rukapul]

RobIII schreef op woensdag 05 oktober 2005 @ 10:32:
En om eerlijk te zijn had ik inderdaad wel wat "wildere" resultaten verwacht toen ik dit gedrocht uit mijn duim zoog. Maar WTF heeft dat te maken met een "not-invented-here" syndroom?

Je post halverwege de draad met een 'oplossing' die slechtere resultaten biedt dan vele voorstellen daarvoor (zowel met gelijke als grotere complexiteit) zonder enige argumentatie waarom jouw oplossing goed danwel beter is dan de geschetste oplossingen. Dan kun je het mij wel met PLONK-waardige opmerkingen kwalijk nemen dat ik je daarop wijs, maar het is beter de balk uit je oog te peuteren, wat gezien bovenstaande opmerking toch een beetje heeft plaatsgevonden. Tot hierboven had je niet eens één objectieve maatstaf om de kwaliteit van zo'n husselfunctie te beoordelen.

Overigens, een (nee, misschien niet "de") implementatie van RSA is o.a. hier te vinden (om het even langs mijn functie te houden). Vind je het niet een beetje overkill voor zoiets onzinnigs?

Je hoort mij nergens zeggen dat TS RSA moet gebruiken, alleen dat het een elegante oplossing is. Als ik dit zelf klein en efficient zou moeten realiseren dan dan zou ik een lookuptable gebruiken. Die tabel zou ik offline vullen op basis van input uit een PRNG of als ik inschat dat ik later de flexibiliteit nodig zou hebben een geparametriseerde crypto functie.

[RobIII]

Rukapul schreef op woensdag 05 oktober 2005 @ 10:53:
Je hoort mij nergens zeggen dat TS RSA moet gebruiken, alleen dat het een elegante oplossing is. Als ik dit zelf klein en efficient zou moeten realiseren dan dan zou ik een lookuptable gebruiken. Die tabel zou ik offline vullen op basis van input uit een PRNG of als ik inschat dat ik later de flexibiliteit nodig zou hebben een geparametriseerde crypto functie.

TS gaf duidelijk aan geen lookup table te willen / kunnen gebruiken. Waarom dat zo zou zijn zal me worst wezen, daar heb ik niet naar gevraagd. Ik neem aan, en P_de_B kennende, dat hij daar een goede reden voor heeft/had. Natuurlijk heeft MSalters een punt (dat overigens iedereen heeft gedacht at some point in deze draad) door te zeggen dat het onzin is om geen lookup-table te kunnen gebruiken.

Maar als het gaat over een plank voor je hoofd (of een balk in je oog) dan moet je eens een stapje terug doen en je eigen posts eens lezen. Het "probleem" was erg simpel, vereistte geen ontzettend sterke encryptie of wat dan ook en was (IMHO) niet eens een topic waard. Wat mij verbaasd is dat mensen met allerlei vreselijke overkill oplossingen komen die totaal onnodig zijn voor dit "probleem". (En nee, een lookup-table is geen overkill, dat hoor je me niet zeggen). Dat je me "ophangt" aan een stukje code (dat overigens alleen maar diende ter illustratie en nergens als (dé) oplossing wordt aangedragen) moet je zelf weten. Ik had dacht ik al aardig toegegeven dat het niet moeders mooiste was. Overigens is het gros, tot aan betreffende post van mij, qua suggesties allemaal redelijk in lijn. Ze gaan (bijna?) allemaal over wat bit-husselen, wat XOR-en en +5 en -5 constructies. Even de eerste zoveel posts samengevat:

[list]
• de Wortel van dagnummer nemen, en dat x 100?
• Even getallen minus 1 en oneven getallen plus een getal groter dan 366?
• Makkelijkst is denk ik een XOR-operatie
• XOR is volgens mij nog wel het makkelijkst
• Stap 1: volgorde omdraaien, Stap 2: elke positie: Indien getal>=5: getal=getal-5, indien getal<5: getal=getal+5
• Een combinatie van een paar omkeerbare bewerkingen lijkt me voldoende voor zoiets

Dan komt rwb (en jij) met Public-key encryption en reageert TS er als volgt op:

P_de_B schreef op dinsdag 04 oktober 2005 @ 14:33:
Op zich heb je gelijk, maar het is de bedoeling dat het nummer voor de 'toevallige' kijker niet direct herleidbaar is naar een dag van het jaar. Het is niet zo'n probleem dat een code eenvoudig te kraken is als je alle waardes weet. Ze gaan toch niet onze batchcodering bruteforcen denk ik.

Een redelijke husseling als hierboven beschreven is in principe voldoende. Al heeft het zoeken naar een public key oplossing wel mijn interesse gewekt. Dat is echter iets waar ik eens rustig voor moet gaan zittten denk ik

Misschien dat je over die post, in je enthousiasme, heen hebt gelezen?

En nogmaals, "kwaliteit" of niet van mijn (of willekeurig welke andere) functie doet er amper toe als het gaat om de gemiddelde "zijn-de-bierflesjes-wel-goed-gevuld-lopende-band-medewerker". Het ging er om dat op het eerste gezicht een dagnummer niet te herleiden was. We hebben niet allemaal Computer science aan de UT gestudeerd

Voor de geïnteresseerden heb ik overigens even een plot gemaakt van rwb's functie:

Tuurlijk is deze mooier en charmanter. Maar ook hier valt een verband te vinden. Als je er maar wat tijd in steekt (en weet wat je zoekt).

Maar goed, genoeg offtopic gezeverd. Zand erover.

[ Voor 112% gewijzigd door RobIII op 05-10-2005 11:56 ]

[schoene]

Rukapul schreef op woensdag 05 oktober 2005 @ 08:56:
MSalters wel een punt: voor ca 2kB heb je twee hardcoded arrays n je sourcecode die exact hetzelfde doet. Een argument voor een functie zou parametrisatie kunnen zijn om over tijd te varieren of indien er in de toekomst meer 3 cijferige velden gecodeerd moeten worden..

tjah, je kan dat eenvoudigweg oplossen door je array niet te hardcoden, maar op te stellen bij het opstarten van je programma, en dat opstellen afhankelijk te maken van het jaartal. Uiteindelijk zijn die arrays gewoon 2 permutaties van 1,2,...,n. Een permutatie maken kan eenvoudig door het algoritme

code:

for i=1 to n-1 do swap[ a[i], a[ Random[i,n] ];

Als je de randomizer met dezelfde seed initializeert, krijg je ook steeds dezelfde permutatie. Laat je de seed van het jaartal afhangen, dan krijg je ieder jaar een nieuwe permutatie.

C++:

#include <vector>
#include <algorithm>
#include <cstdlib>
#include <iostream>

void initializeVectors (std::vector<int> &day2code, std::vector<int> &code2day, const int size, const int seed)
{
  std::srand (seed);

  day2code.resize (size);
  code2day.resize (size);

  for (unsigned int i=0; i < day2code.size (); ++i)
  {
    day2code [i] = i;
    code2day [i] = i;
  }

  for (unsigned int index1=0; index1 < day2code.size () - 1; ++index1)
  {
    int index2 = index1 + (std::rand () % (day2code.size () - index1));

    std::swap (day2code [index1], day2code [index2]);
    std::swap (code2day [day2code [index1]], code2day [day2code [index2]]);
  }
}

int main(int argc, char* argv[])
{

  std::vector<int> day2code, code2day;

  initializeVectors (day2code, code2day, 366, 2005);

  // als je nog verder random getallen nodig hebt
  //srand (time (0));

  for (unsigned int i=0; i < day2code.size (); ++i)
  {
    std::cout << "dag " << i << " : code " << day2code [i] << " | ";
    std::cout << "code " << day2code [i] << " : dag " << code2day [day2code [i]] << std::endl;
  }

  return 0;
}

[ Voor 14% gewijzigd door schoene op 05-10-2005 14:02 ]

[Vaan Banaan]

rwb schreef op dinsdag 04 oktober 2005 @ 14:59:
mwaoh er zijn wel een aantal mogenlijkheden hoor
b.v. p=17 en q=47
deze heb ik even uit mijn hoofd. Voor echte encryptie zijn er idd veel te weinig mogenlijkheden maar daar gaat het hier natuurlijk niet om
[edit]
er zijn trouwens 127 mogenlijke p en q's die aan die voorwaarde voldoen.

Ik heb het eens getest en inderdaad lijkt het volledig random. Op 1 januari na dan.
b.v. e=169, dan wordt d=601
tabel (gedeelte) is origineel => encrypt => decrypt

code:

  1 =>   1 =>   1 |   2 => 444 =>   2 |   3 => 592 =>   3 |   4 => 582 =>   4
  5 => 556 =>   5 |   6 => 776 =>   6 |   7 => 486 =>   7 |   8 => 331 =>   8
  9 => 502 =>   9 |  10 => 772 =>  10 |  11 => 176 =>  11 |  12 => 175 =>  12
 13 => 574 =>  13 |  14 =>  54 =>  14 |  15 => 763 =>  15 |  16 => 747 =>  16
 17 =>  51 =>  17 |  18 => 766 =>  18 |  19 => 699 =>  19 |  20 => 796 =>  20
 21 =>  72 =>  21 |  22 => 641 =>  22 |  23 => 555 =>  23 |  24 => 197 =>  24
 25 => 722 =>  25 |  26 => 774 =>  26 |  27 => 755 =>  27 |  28 =>   6 =>  28
 29 => 362 =>  29 |  30 => 795 =>  30 |  31 => 428 =>  31 |  32 =>  83 =>  32
 33 => 322 =>  33 |  34 => 272 =>  34 |  35 => 154 =>  35 |  36 => 529 =>  36
 37 => 779 =>  37 |  38 => 344 =>  38 |  39 => 233 =>  39 |  40 => 266 =>  40
 41 => 775 =>  41 |  42 =>   8 =>  42 |  43 => 264 =>  43 |  44 => 160 =>  44
 45 => 261 =>  45 |  46 => 328 =>  46 |  47 =>  47 =>  47 |  48 => 377 =>  48
 49 => 491 =>  49 |  50 => 169 =>  50 |  51 => 629 =>  51 |  52 =>  86 =>  52
 53 => 682 =>  53 |  54 => 439 =>  54 |  55 => 378 =>  55 |  56 => 267 =>  56
 57 => 725 =>  57 |  58 => 129 =>  58 |  59 => 739 =>  59 |  60 => 621 =>  60
 61 =>   7 =>  61 |  62 => 669 =>  62 |  63 => 277 =>  63 |  64 =>  98 =>  64
 65 => 343 =>  65 |  66 => 746 =>  66 |  67 => 373 =>  67 |  68 => 119 =>  68
 69 => 171 =>  69 |  70 => 461 =>  70 |  71 => 150 =>  71 |  72 => 769 =>  72
 73 => 539 =>  73 |  74 => 708 =>  74 |  75 => 758 =>  75 |  76 => 127 =>  76
 77 =>  43 =>  77 |  78 => 381 =>  78 |  79 => 788 =>  79 |  80 => 651 =>  80

Dit lijkt me inderdaad wat jij wil, eventueel eerst een vaste waarde bij de dag optellen, om 1 januari ook versleuteld te krijgen. (En dat er achteraf weer afhalen natuurlijk)

[ Voor 20% gewijzigd door Vaan Banaan op 05-10-2005 17:38 ]

[Woy]

Vaan_Banaan schreef op woensdag 05 oktober 2005 @ 17:34:
[...]

Ik heb het eens getest en inderdaad lijkt het volledig random.

Random is op veel platformen daardoor ook op een soortgelijke manier geimplementeerd volgens mij.

Op 1 januari na dan.

Dat krijg je logischerwijs als je 1 machtsverheft maar het is idd een oplossing om dan bijvoorbeeld gewoon 1 bij op te tellen. Dan loopt je reeks van 2 - 367 ipv 1 - 366.

En het is nog een super eenvoudige functie om te implementeren dus ik zie niet in waarom je lastig zou gaan doen met bits en dergelijke.
Alleen een lookup-table zou idd mischien nog de voorkeur kunnen hebben.

[Voutloos]

Tja, waarom zou 1 paar waarbij cyphertext == messagetext nou erg zijn? De toeschouwer weet in den beginne uberhaupt niet eens dat het mysterieuze xxx een dagnummer betekent en ziet bovendien niet binnen een leuke tijd een structuur. Als je verwacht dat alle getallen versleuteld zijn, valt dat ene getal wat versleuteld hetzelfde getal blijft niet door de mand en anders zou je er even goed niets uit af kunnen leiden.