asmoranomar

Pagers are not guaranteed to be 1 way comms and bringing them into secure locations is a security violation. Additionally, depending on the classification, no unauthorized and undisclosed devices of any kind would be permitted, including any electronics or electronic media such as tapes, CDs, discs, etc. Even when I was issued a verified 1-way pager, I was specifically briefed I was not permitted to bring it into a classified location. Most of the highly classified SCIFS are shielded anyways, you can't use it inside so it's safer to leave it out, along with all other devices.

If your organization allows it, then (if federal) they are breaking the law and should be reported/up-channeled. If it's corpo, you should bring up additional concerns with your security team.

Edit: Also, it goes without saying, current events are probably a good reason why pagers (and other devices) aren't allowed in classified areas. While most focus on disclosure (getting out), we must not forget the risk of data/operations getting destroyed.

All valid concerns, but the fact is if you accept the weapon and anything happens, you are at fault.

We've had people get issued, and immediately, check and clear their weapon in the presence of an armorer in the bucket, and get in trouble for it misfiring, despite the fact that it should have been checked and cleared prior to change of hands and in addition to the fact that you hadn't been issued ammo yet. It's dumb, but people die over this, so they are very strict, even when it sometimes seems unnecessary.

We've had similar incidents with weapon safety (and other things) in the past that were more serious than what was going on in that picture. It all depends on the circumstances, and I've seen it go both ways. The point I was making is if there was anything more substantial, it would not just be 'relieved of command'. No mention of an actual reprimand, which is more serious. I'm not saying it couldn't ultimately lead up to that, but we don't know that yet.

It was also a relief of command, not a court martial, not non-judicial punishment, not a demotion or and not a punitive action. It happened because it affected the image of the force, but not necessarily anything that is terribly bad. Relieving someone of command can be a precaution or a temporary measure, not always leading up to anything drastic. He will probably get additional training and a small mark on his record that will go away in a short time as long as the trend doesn't continue. He may even still get to keep his command or just move somewhere else to command.

In some instances of private/public key systems, this is done. It's mainly for the purpose of ensuring the recipient knows who the sender was and also ensuring the sender knows who the recipient is.

Quick primer: If you encrypt with your private key, everyone knows it was sent by you. If someone encrypts with your public key, they know you will receive it. Use your private key and someone's public key together and you know only that person got it.

In practice, lately another step is added to negotiate a third temporary/session key. This ensures keys aren't used forever, and if compromised a new one can be generated. This is more secure than encrypting twice, because you never know what data is sensitive and picking the wrong one requires the attacker to start from scratch.

A better example is to explain the chaos of having to go to the grocery store and pick up some hot dogs and buns. You know the pain.

Why would you break the 2nd? Are you one of those liberal types? /s

I'm not an expert, but can you not be both?

And even if it was, it would be the right move. The last thing we want is to stop risk management because there's only 2 hours left and the door hasn't fallen off so far.

AM radio is also used for time keeping and weather transmissions for embedded systems that don't need Internet or heavy computing power (like a clock on your desk or a watch). It's also good for emergencies. All of which can be passed in analog audio or digitally modulated (or both). Probably not exciting for music, but the fact that it's there and you can tune into it to find out the weather or traffic is useful.

I was a mix-up that was quickly resolved because the baby they gave my mom had the wrong bits. It happened again with my sibling. And my other sibling. For the exact same reasons. We all joke that none of us are really related.

But it really makes you think...

Close, but you are still trusting the device you own. If I were to compromise that device, I could capture that key and use it. Again, this is my limited understanding, but a zero trust solution works in such a way that the actual keys are not stored anywhere. During setup, new temporary keys are generated. A keypass binds to the temporary key for use of authentication. The temporary key can be revoked at any time for any reason, whether it's due to a breach or routine policies. It can be as aggressive as it needs, and the implication is that if someone else (either you or an attacker) got issued a new temporary key then the other would not receive it. Using an incorrect temporary key would force an initialization again, using the actual keys that aren't stored anywhere.

The initialization process should be done in a high trust environment, ideally in person with many forms of vetting. But obviously this doesn't take place online, so there is the risk that your device is not trusted. This is why the process falls back on other established processes, like 2FA, biometrics, or using another trusted device. How this is done is up to the organization and not too important.

But don't get too hooked on the nuances of passwords, keys, passkeys,etc. The entire purpose is to limit trust, so that if any part of the process is compromised, there is nothing of value to share.

Disclosure: Worked in military and this seems to be a consumer implementation of public/private key systems using vector set algorithms that generate session keys, but without the specialized hardware. It's obviously different, but has a lot of parallels, the idea in this case is that the hardware binds to the private/public keys and generates temporary session keys to each unique device it communicates with, and all devices can talk with members of it's own vector set. Capturing a session key is useless as it's constantly being updated, and the actual keys are stored on a loading device (which is subsequently destroyed afterwards, ensuring the actual key doesn't exist anywhere and is non recoverable, but that's another thing altogether). My understanding of passkey systems is solely based on this observation, and I have not actually implemented such a solution myself.