Deci problema pe care AWS o rezolvă aici este că au un tuplu de valori, și anume serviciul, regiunea și data curentă și ar dori să obțină o cheie secretă diferită care depinde de toate aceste valori.
Ați putea continua și face acest lucru cu un PRF obișnuit, dar apoi vă confruntați cu o problemă: și anume nu doriți să aveți o situație în care valorile proaste ale oricăreia dintre intrările de tuplu produc brusc coliziuni cheie. O greșeală clasică ar fi de ex. fie să folosiți concatenarea directă și dacă nu sunt atenți, ajungeți cu (azi)
și (azi)
dând aceeași cheie. Evident, coardele în joc au mai multă structură decât exemplul, dar grija de bază ar trebui să fie clară.
Acum, cel mai eficient mod de a rezolva problema de mai sus este să utilizați o funcție de asociere care garanții că nu există două tupluri distincte de intrare să producă aceeași ieșire și, prin urmare, aceeași intrare în PRF. Cu toate acestea, proiectarea unor astfel de funcții este, de asemenea, ușor predispusă la erori.
eu ghici Din acest motiv, AWS a ales să folosească acest lanț complicat de invocări HMAC. Acum nu trebuie să-și facă griji cu privire la funcțiile complicate de asociere și tot ceea ce este necesar este o grămadă de evaluări HMAC care ar trebui să fie posibile în aproape toate limbile/mediile. Faptul că aceasta necesită apoi nu mai puțin de operațiuni HMAC este compensat de faptul că toate intrările la această derivare a cheii sunt oarecum static și puteți stoca cheile în cache timp de aproximativ o zi dacă operațiunile HMAC costă timp de calcul considerabil pentru dvs.