madscientist
/
SNFMulti
İzle 1
Yıldızla 0
Çatalla 0
Kod Sorunlar 0 Değişiklik İstekleri 0 Sürümler 0 Wiki Aktivite
104 İşlemeler
3 Dallar
Ağaç: 45c0711da8
Dallar Biçim İmleri
${ item.name }
Branş ${ searchTerm } oluştur
'45c0711da8'den
${ noResults }
Commit Graph

12 İşlemeler (45c0711da82bc8345b405b781c7108f2c34fa688)

Yazar SHA1 Mesaj Tarih
  Pete McNeil fe5e00d82c converted snfIPRange from enum to enum class 4 yıl önce
  Pete McNeil 3a4f5ea518 MANGLER to Mangler - conformity 4 yıl önce
  Pete McNeil 43d297c8bd finish up namespace tidy to get a clean build 4 yıl önce
  Pete McNeil d5d8aaefca tidy namespace snfNETmgr 4 yıl önce
  Pete McNeil e9e960f4b5 RuntimeCheck to cd::RuntimeCheck 4 yıl önce
  Pete McNeil 28ae11eac4 snfNETmgr not using namespace std 4 yıl önce
  Pete McNeil 3bf13f0602 Tweaked RuntimeCheck descriptions 4 yıl önce
  Pete McNeil 978f01d630 Cleaned up timestamp functions 4 yıl önce
  madscientist 6d3a6a8abf Fixed valgrind complaint about using uninitialized data when generating a OneTimePad. The algorithm uses unsigned char x as a register. Each next random byte in the pad is based on encrypting the last-- so a first byte is needed. Original code used an uninitialized x on purpose in order to get a supposedly unpredictable byte out of RAM. To make valgrind happy (and truly to make the algorithm better) x is now initialized by encrypting a 0 with the pad generator. This value is not directly exposed in the generated pad. The first byte in the one time pad is not the result of encrypting 0 but instead the result of encrypting the result of that operation. So, the first byte is based on the state of the pad generator just prior to making the OneTimePad. This is probably harder to predict than the state of the stack (where x would have come from) anyway. 15 yıl önce
  madscientist 08a48da626 Minor tweaks to eliminate compiler warnings in snfNETmgr.* 15 yıl önce
  madscientist 7faa99d01f Re-factored for CodeDweller separation 15 yıl önce
  madscientist b313d3961a setup 15 yıl önce