On 2017-02-25 08:00, Bastian Bittorf wrote: > * Michael Richardson <m...@sandelman.ca> [24.02.2017 19:00]: > > [...] > >> The server can either given everyone during a period of an hour the same >> random challenge, it can make them up and store them, or it can construct >> them as the HMAC-SHA256 of, for instance, the IP address which is asking, >> such that it never has to record any of them. >> >> A script kiddie now needs to do some work each time, has to request a new >> token each time, and if the challenges are based upon IP address, the kiddie >> can vote once per IP address they have. So, now they need a bot net to >> vote a lot... probably that's okay. > > thank you for this very good explanation. > >> >> I thought from the subject line and explanation that it was to permit >> >> a firmware image to be validated as being uncorrupted/tained. One >> >> might do this before flashing a device with it. >> >> > how should this be done before flashing? if there is a mistake >> > (e.g. forgotten package during build) the image itself is fine, but not >> > "good". >> >> Right. So getting the stamp into the image at the very last moment is the >> key. That way the build is reproduceable if you ignore those very few bytes. >> Ideally, there is a spot in the image that shows up to userspace. Have you >> figured this part out? I would attempt to make it a kernel boot command >> line option, if that can be tweaked easily. > > for now i patch 'usign' for a now option B = build: > root@LEDE:~ :) usign -B > 98021604736550012081493806018992642304441039324849310980174888200312941028157 > 114543661949658574850110716953530268394806126479026079327889534650057251922973 I think patching something existing like usign does not make any sense, you're only creating extra maintenance work for yourself. You should make a separate small binary for it...
- Felix _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
