@JourneymanGeek doesn't that beg the question if anyone that will be there does? :D
> Attendees will have the opportunity to hear policy shaping speeches from Government Ministers and an important strategic update from Robert Hannigan, Director GCHQ. Speakers will include senior IA and Cyber Security leaders from Government, Industry and Academia, who will share their experiences and perspectives.
@DavidFreitag - I think that was core to the problem. Updated motherboard drivers, and using the NVIDIA rather than the supplied GPU drivers has sorted almost everything
Still trying to figure out which device is still unhappy
(Unknown USB composite device - device descriptor request failed)
and the nasty habit the GPU has on only waking one monitor after the PC has been sleeping
but aside from that - I have even tested Portal on 7680 by 2160 and it is beautiful
If I'm going to be signing a message, and sending out the plaintext||MAC, and I expect the readers to send me back the same plaintext||MAC, is it better to use asymmetric signing than HMAC, or does it not make a difference.
I was thinking of using HMAC (SHA256), but I feel guilty about using just that and calling it a day.
I feel like I should use asymmetric signing, but that's only a gut feeling, and it can be totally wrong.
The only reason why I'm biased in favour of symmetric signing is because it's easier; no need to open up openssl and then generating a public/private key, and then having my code open up both keys, and programming additional logic that handles both signing and verifying.
@SalehenRahman If you use a MAC, then people who can verify the MAC know the key, and thus can also generate a MAC.
If all involved parties know the same MAC key then they can play nasty games on each other, which may or may not be a problem in your specific context.
For instance, in a SSL connection, both client and server know the MAC key used for protecting the integrity of records, but that is not a problem since that key is specific to that connection.
Records from one SSL connection cannot be used "as is" in another because the MAC key is not the same.
Notably, even within one connection, each direction has its own MAC key. This is important.
@Thomas: well, I'm just sending out a unique token to determine whether or not a client is authorized to use our service. The client couldn't care less what's in the token, so long as they give us a token that is signed by us, then they are welcomed to use our service.
So basically the client stores some value, which happens to be some data+MAC, and the server verifies that the MAC is correct, meaning that the value is "one of its own" ?
