Oct 16, 2024
“Abundance of Caution” is C-suite lingo for “Oopsie, oh flying squirrel”
openssl.cnf option
June - RFC 9591 “FROST Flexible round-optimied Shnorr threshold signing protocol”
A cryptological protocol to allow a quorum of a distributed committee to sign a document.
Matthew Green @matthew_d_green 2024-05-02
“Europe is maybe two months from passing laws that end private communication as we know it, and folks are looking the other way (understandably.) You’re not going to get a do-over once these laws are passed.”
liblzma XZ backdoor to SSH (Easter Weekend)
@eb@social.coop)
(Have I said before that SystemD is the Universal Attack Surface?)
AndresFreundTec @AndresFreundTec@mastodon.social
I accidentally found a security issue while benchmarking postgres changes.
If you run debian testing, unstable or some other more “bleeding edge” distribution, I strongly recommend upgrading ASAP.
2/ > I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.
Really required a lot of coincidences.
$ xz --version ## simplistic, may check wrong one; 5.6.[01] bad.
xz (XZ Utils) 5.4.5
liblzma 5.4.5
$ bash detect_sh.bin ## beter, checks which libzma sshd uses
probably not vulnerable
$ bash -xv detect_sh.bin ## or, to trace it if paranoid, but only after visual inspection
#! /bin/bash
set -eu
+ set -eu
# find path to liblzma used by sshd
path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"
++ grep liblzma
++ grep -o '/[^ ]*'
+++ which sshd
++ ldd /usr/sbin/sshd
+ path=/lib/x86_64-linux-gnu/liblzma.so.5
# does it even exist?
if [ "$path" == "" ]
then
echo probably not vulnerable
exit
fi
+ '[' /lib/x86_64-linux-gnu/liblzma.so.5 == '' ']'
# check for function signature
if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
then
echo probably vulnerable
else
echo probably not vulnerable
fi
+ hexdump -ve '1/1 "%.2x"' /lib/x86_64-linux-gnu/liblzma.so.5
+ grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
+ echo probably not vulnerable
probably not vulnerable
$
Date: Fri, 29 Mar 2024 08:51:26 -0700 From: Andres Freund <andres@…razel.de> To: oss-security@…ts.openwall.com Subject: backdoor in upstream xz/liblzma leading to ssh server compromise
Hi,
After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer:
The upstream xz repository and the xz tarballs have been backdoored.
At first I thought this was a compromise of debian’s package, but it turns out to be upstream.
…
((includes attached analysis, detect.sh to check if compromize.)
I hope the xz attack helps people understand: while a lot of sexy open source projects are supported by big corps or VC money, a lot of the unsexy ones are one or two people volunteering for a nearly-full-time level of effort and engagement, but for free.
Everything
I know about the XZ backdoor (endorsed by Brian Krebs; by
@eb@social.coop)
Glyph @glyph@mastodon.social Mar 29, 2024, 20:43 I really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html
2024-03-30 Joerg Jaspert :debian: @Ganneff@fulda.social And if you are curious about the #xz #compromise, a little update on the #Debian site: As already written, the archive processing is currently off (nothing new coming to testing/unstable/experimental, no mirror updates pushed out). Automated build daemons for the affected architectures have been stopped, and only two of them regenerated with a clean #stable environment. They are building for the security archive only, nothing else, right now. That part is safe. Members of the Release, FTP, Security, Build-Daemon and Sysadmin team are discussing what the next steps are. There are multiple different ways that can be taken, with different drawbacks and amounts of work involved. Also, it is not yet fully known what the malicious code all could do, so there might be much more that needs to be done later - or not. Unknown as of now, needs the analysis of it to finish, which is not easy nor fast. @debian
analogist@social.ridetrans.it James Wu @analogist@social.ridetrans.it
@grimalkina the part that stood out to me was that the decision from the poor maintainer to hand over the maintainership to the malicious actor was… expedited by a slew of psyops abuse from various sockpuppet accounts that were absolutely indistinguishable from the demands that OSS maintainers of popular packets get on a routine basis. e.g.: xz-devel@tukaani.org
filippo@abyssdomain.expert Filippo Valsorda :go: @filippo@abyssdomain.expert 2024-03-30
I’m watching some folks reverse engineer the xz backdoor, sharing some preliminary analysis with permission.
The hooked
RSA_public_decryptverifies a signature on the server’s host key by a fixed Ed448 key, and then passes a payload tosystem().
It’s RCE, not auth bypass, and gated/unreplayable.
More details in this thread:
https://bsky.app/profile/did:plc:x2nsu
Jonathan Kamens jik@federate.social
I want to point out the first item in @zackwhittaker@techcrunch.com’s weekly #cybersecurity newsletter this week, as it pertains to the #xz backdoor. If you really think countries like China have engaged in “decade-long espionage campaigns” and haven’t tried similar stunts elsewhere, you’re kidding yourself. The xz backdoor isn’t the only one; it’s just the one we’ve found. #infosec Article link: https://www.justice.gov/usao-edny/pr/seven-hackers-associated-chinese-government-charged-computer-intrusions-targeting > UK, US slap China’s APT31 with sanctions Newsletter signup: https://social.us18.list-manage.com/su
Kevin Beaumont For those asking what systemd change, easy write up: Reduce dependencies of libsystemd #32028
It was in train before the XZ issue was discovered, which may be why the threat actor sped up, started making mistakes and started begging distros to upgrade XZ - as what looks to be years of planning was about to be flushed down the pan.
Kevin Beaumont > I wrote a thing - Inside the failed attempt to backdoor SSH globally — that got caught by chance
Includes a few things which I suspect may be new insights.
https://doublepulsar.com/inside-the-failed-attempt-to-backdoor-ssh-globally-that-got-caught-by-chance-bbfe628fafdd
The level of sophistication of the XZ attack is very impressive! I tried to make sense of the analysis in a single page (which was quite complicated)!
I hope it helps to make sense of the information out there. Please treat the information “as is” while the analysis progresses! #infosec #xz
Harald Hoyer @backslash@floss.social
Last Wednesday I gave a company internal Lunch&Learn talk about reproducible builds citing https://reproducible-builds.org/
The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process.
[reproducible-builds.org] > Reproducible Builds — a set of software development practices that create an independently-verifiable path from source to binary code > #xz #nix #nixos
benzblog: The XZ Backdoor via Fedi
excerpt -
Why does OpenSSH even depend on xz? Normally, it doesn’t, however several Linux distributions patch sshd to integrate systemd notifications. The systemd library to do that also happens to link against liblzma from the xz project. So perhaps the folks complaining about how systemd is so pervasive in modern Linux systems do have a point. … Would SBOM have prevented this? Haha lol no.
Tim Bray
@timbray@cosocial.ca >
1/2 Looking at one of the #xz writeup, this struck my eye: > “The
release tarballs upstream publishes don’t have the same code that GitHub
has. This is common in C projects so that downstream consumers don’t
need to remember how to run autotools and autoconf.”
> Ah, GNU AutoHell, I remember it well. Tl;dr: With AutoHell, even if
you’re building for a 19-bit Multics variant from 1988, it’s got your
back. Except for it’s just too hard to understand and use, thus the
above. > #infosec
2/2 Thus, another #xz lesson. Don’t rely on build tools you don’t understand generally, and don’t rely on GNU AutoHell specifically.
[Yes, I understand this hack has many more moving parts, most much more sophisticated. But I didn’t see anyone else saying this.]
Matt Blaze @mattblaze@federate.social
An interesting thing about the XZ sabotage is that, while it was very cleverly obfuscated (congratulations to Andres Freund for finding it!), once found, it is very clear that it’s a deliberate backdoor. It can’t be explained away as an ordinary bug that introduced a vulnerability.
Says something about the tradeoff space the attacker was working in.
2/ > Another notable thing: the backdoor, as far as I’ve been able to glean, is “NOBUS” (“nobody but us”), requiring knowledge of not just the existence of the backdoor, but also a secret key, to exploit. NOBUS backdoors would be very hard to camouflage as innocent bugs, so that could explain why the attacker chose this risky approach.
But that raises the question of why they wanted a NOBUS backdoor. A state actor trying to limit colateral risks would likely care about this.
reply/
Arik @arikb@mastodon.sdf.org
@jripley @mattblazealso, sshd drops privileges immediately after the authentication is successful. If you want to run something as root, it has to be pre-auth.
Dan Goodin ArsTechnica 4/1 updated Bruce
ISC Podcast (Mon, Apr 1st): xz-utils Backdoor (CVE-2024-3094) ⇒ Diary 2024-04-01 by Bojan Zdrnja - The amazingly scary xz sshd backdoor with Gist being updated & Jan Kopriva The xz-utils backdoor in security advisories by national CSIRTs - which countries managed to publish national advisories over a 3/4-day holiday weekend?
Filippo Valsorda @filippo.abyssdomain.expert 3/31 > To clarify, by “gated” I mean it takes the attacker’s private key to use the backdoor (it’s NOBUS); by “unreplayable” I mean that even if we observe an attack against one host, we can’t reuse it against another host (the attacker’s signature is bound to the host public key, but not to the command).
Only affects x86/64 type architecture build, does not affect ARM/PI/…
“Junk drawer” libraries are valuable targets especially if they have C++ initializers, code that runs upon being loaded not explicitly called. So OOPS is an Ooopsie.
(the irony of RU adjacent Kaspersky commenting on APTs)
Schneier 4/2 XZ Utils Backdoor & 4/15 Backdoor in XZ Utils That Almost Happened
Following responsible disclosure, the issue has been addressed in PuTTY 0.81, FileZilla 3.67.0, WinSCP 6.3.3, and TortoiseGit 2.15.0.1. Users of TortoiseSVN are recommended to use Plink from the latest PuTTY 0.81 release when accessing an SVN repository via SSH until a patch becomes available.
Specifically, it has been resolved by switching to the RFC 6979 technique for all DSA and ECDSA key types, abandoning its earlier method of deriving the nonce using a deterministic approach that, while avoiding the need for a source of high-quality randomness, was susceptible to biased nonces when using P-521.
On top of that, ECDSA NIST-P521 keys used with any of the vulnerable components should be considered compromised and consequently revoked by removing them from ~/.ssh/authorized_keys files and their equivalents in other SSH servers.
Every version of the PuTTY tools from 0.68 to 0.80 inclusive has a critical vulnerability in the code that generates signatures from ECDSA private keys which use the NIST P521 curve. (PuTTY, or Pageant, generates a signature from a key when using it to authenticate you to an SSH server.) This vulnerability has been assigned CVE-2024-31497. It was discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum; see their write-up on the oss-security mailing list.
The bad news: the effect of the vulnerability is to compromise the private key. An attacker in possession of a few dozen signed messages and the public key has enough information to recover the private key, and then forge signatures as if they were from you, allowing them to (for instance) log in to any servers you use that key for. To obtain these signatures, an attacker need only briefly compromise any server you use the key to authenticate to, or momentarily gain access to a copy of Pageant holding the key. (However, these signatures are not exposed to passive eavesdroppers of SSH connections.)
? Therefore, if you have a key of this type, we recommend you revoke it immediately: remove the old public key from all OpenSSH authorized_keys files, and the equivalent in other SSH servers, so that a signature from the compromised key has no value any more. Then generate a new key pair to replace it.
(The problem is not with how the key was originally generated; it doesn’t matter whether it came from PuTTYgen or somewhere else. What matters is whether it was ever used with PuTTY or Pageant.)
The good news: the only affected key type is 521-bit ECDSA. That is, a key that appears in Windows PuTTYgen with ecdsa-sha2-nistp521 at the start of the ‘Key fingerprint’ box, or is described as ‘NIST p521’ when loaded into Windows Pageant, or has an id starting ecdsa-sha2-nistp521 in the SSH protocol or the key file. Other sizes of ECDSA, and other key algorithms, are unaffected. In particular, Ed25519 is not affected.
Details of the error:
All DSA signature schemes require a random value to be invented during signing, known as the ‘nonce’ (cryptography jargon for a value used only once), or sometimes by the letter k. It’s well known that if an attacker can guess the value of k you used, or find any two signatures you generated with the same k, then they can immediately recover your private key.
This means that it’s dangerous to generate DSA signatures on systems with no high-quality source of randomness. Significantly more dangerous than generating the encryption keys for a single session: a leak of the private key compromises far more than one SSH session.
For this reason, since PuTTY was developed on Windows before it had any cryptographic random number generator at all, PuTTY has always generated its k using a deterministic method, avoiding the need for random numbers at all. The clever trick is to compute a secure hash whose input includes the message to be signed and also the private key. Secure hash output is indistinguishable from random data (or else the hash function isn’t doing its job), and this generation method can’t be repeated by an attacker who’s trying to find out the private key – if they could generate the same hash input as you, they’d already have the private key.
This technique is now mainstream, and RFC 6979 documents a specific well-known way of doing it. But PuTTY didn’t follow that specification, because we started doing the same thing in 2001, and the RFC wasn’t published until 2013.
PuTTY’s technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY’s technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.
In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.
This bias is sufficient to allow a key recovery attack. It’s less immediate than if an attacker knows all of k, but it turns out that if k has a biased distribution in this way, it’s possible to aggregate information from multiple signatures and recover the private key eventually. Apparently the number of signatures required is around 60.
or, Another Decades old OpenSSH server RCE
remerges
if
if-statement bypassed in latest patches 
Telegram MTProto 1.0 remains vulnerable to Chosen Ciphertext attack, and defualt is not end-to-end so subpeonable?
IND_CCA3_Insecure
Indistinguishability under chosen ciphertext attacks;The irony of citing a good explanation from Kaspersky but …
Fixing newly discovered side channel will likely take a major toll on performance.
“Beware of hardware optimizations”
see also Schneier 3/28
A Study of 4 Digit PIN popularity, inspired by humor, using real leaked PIN collections, briefly went viral.
Well, a 4 digit limit on PINs is pretty bad in itself. Limiting to digits is required if to be entered on a phone pad or equivalent; and requires Denial of Service lockout to prevent bruteforcing all 10k.
Study is over a decade old (tagged 2009-2013) but went viral in 2024, so I’m including it in 2024 news.
As author Nick comments, do not use his list of 20 least used PINs, the bad guys will have already grabbed that list assuming you’d do that.
How viral was this? You probably saw it in passing.
This story was discovered and promoted by Information is
Beautiful as Most
Common PIN Codes; they syndicate widely, so viral it went.
In the original article, if one scrolls down, he extends his study to all numeric pass-codes of any length. Half are 4 digit. 6 and 8 digit pass-codes account for another 30%. The remaining 20% are a not-so-fat tail 5,7,9,10..14. 123456… is tops in each length. Geometric patterns on the keypad remain popular, same as they were with German ENIGMA operators early in WW2.
Similar data, four-digit-pin-codes-sorted-by-frequency-withcount.csv
Alas the data scientist who did this wonder, Nick Berry, succumbed to cancer in 2022.
YubiKey Sidechannel Attack
Blockchain
garbage collection {paywall}
How a 27-Year-Old Codebreaker Busted the Myth of Bitcoin’s Anonymity.
Once, drug dealers and money launderers saw cryptocurrency as perfectly untraceable. Then a grad student named Sarah Meiklejohn proved them all wrong—and set the stage for a decade-long crackdown.
Key sentence of abstract
Bitcoin has the unintuitive property that while the ownership of money is implicitly anonymous, its flow is globally visible.
TL;DR Built a mesh or map using Metadata of transactions to cluster public and supposedly private wallet IDs of inferred same actors.
I feel unclean linking even a16z’s Y-T.
Dr Meiklejohn’s academic paper evokes Clint Eastwood two movie titles “A Fistful of Bitcoins: Characterizing Payments Among Men With No Names.”
Wikipedia reference links include Wired 2024, NYT 2013, MIT Tech Review 2019.
.git-ignore the credential files in
project dir)
David
Kahn (1930-2024)
See last 2022 status
Quantum Superposition when used for computing.
Such bits are in quantum superposition of True and False, which is a bug in classical computing but a feature in QC.
This allows non-deterministic algorithms.
Quantum Annealing - big qubit counts, great for optimization problems
but not cryptology. (?yet? well maybe …) Not general purpose.
Quantum Circuit/Logic - small numbers of qubits so far.
In theory, algorithms for these hardware types can use non-deterministic parallelism to evade classical performance limits, and in particular, could allow factoring fast enough to be dangerous, provided big enough quantum circuits can be made to work.
Yes !
Quantum Cryptanalysis
Every unbreakable cipher has been broken eventually (at least partially1).
20thC RSA and other PKI not guaranteed proof against either of:
Schor’s Algorithm in theory would factor fast on enough quantum circuits but 21 is not a large number yet. (see also Wikipedia. Some say 433 bits on IBM Osprey QC is enough for RSA2048 with Schor’s algo needing 372 Qubits (with pre-processing and post-processing), but will it work? Schneier and Schor doubt it. Shouldn’t someone try it?)
Other probabilistic quantum algorithms (Grover, GEECM, Variational Quantum Factoring (VQF)) can do some much bigger numbers (which may just define new class of unsafe primes??), and with classical pre-processing, can use a much smaller number of qubits than the ^obvious^ log2N.
not clear this will ever be able to generally break RSA4096, but it’s not impossible, so prudent to plan for that day.
Classical “Forward Secrecy” - old messages not broken by later loss of host key
Generalized: old saved messages not broken by later breakthroughs either.
Realistic threat? 
* VENONA: It worked Once! {[BLU Sept 2018](http://blu.org/meetings/2018/09/)}
* We now have a Vacuum Cleaner of Holding (_Greenpeace photo c/o Wikimedia_)So yes, it can happen again.
Normal Forward Secrecy requires that if e.g. the Host Key is compromised later, any retained cryptograms sent with nonce keys negotiated with the compromised Host Key aren’t also compromised.
This is nice, but we’d also like to protect against advances of technology, e.g. fast factoring or solutions of discrete logs.
This may not be within your threat model, yet, but in dystopian plausible futures, things you’ve already discussed/downloaded might be retroactively illegal/disloyal and oops.
The goal of post-quantum cryptography (also called quantum-resistant cryptography) is to develop cryptographic systems that are secure against both quantum and classical computers, and can interoperate with existing communications protocols and networks. – NIST
National Institute of Standards & Technology started a multi-round competition, similar to with AES and SHA3 competitions
NIST, the Bureaucracy formerly known as NBS.
Goal is to have PQC ready for use not only before quantum breakthrough but early enough (roughly now) that anyone who wishes to avoid save-intercepts-now-to-break later can switch quickly; although it may already be too late WRTO NSA archive?
This competition was “more brutal” than prior; of 69 candidates, peer cryptanalysis has broken 62. So far.
RSA2048 in play or not? - Chinese academic paper claiming 2k bit RSA within range of current gen NON-fault-tolerant QC, no great surprise given Qubits available and theoretical algorithm size. Schor and Schneier unconvinced - does it actually converge w/o FT? Schneier 2023-01
[2023.02.28] CRYSTALS-Kyber is one of the public-key algorithms currently recommended by NIST as part of its post-quantum cryptography standardization process. Researchers have just published a side-channel attack—using power consumption—against an implementation of the algorithm that was supposed to be resistant against that sort of attack. The algorithm is not “broken” or “cracked”—despite headlines to the contrary—this is just a side-channel attack. What makes this work really interesting is that the researchers used a machine-learning model to train the system to exploit the side channel.
OTOH as seen in TETRA:BURST, a side-channel attack can be used to extract key or algorithm from a piece of equipment that falls into opponent lab.
TL;DR No. It’s happened. (see in notes)
Lack of randomness failure isn’t just hypothetical, lots of SSH keys got invalidated in 2008 because they were well-known-primes.
random^[DSA-1571-1 openssl predictable random
number generator {CVE-2008-0166}
{Schneier}
which compromised many SSH keys.(WTAF? Yep. Debian packagers applying normal
best practices where they shouldn’t even touch (Normal doesn’t
apply!) had removed the entropy-harvesting because Valgrind and
Purify gave accessing uninitialized memory warnings. Well
yeah, that’s how we harvest entropy! Another problem (mostly
solved?) is host key generation at VM start - the VM’s entropy is rather
deterministic (biased) at that point. Similarly, optimizing compilers
removing zeroing memory prior to releasing it can allow keys to leak
into the memory pool. Cryptographic software is an ongoing a battle
against computer ^science^ that ^knows better^.)
And failure to salt wouldn’t surprise me when non-specialists (applications developers, database programmers, protocol developers) who should stick to packaged PKI use-case libraries (e.g. NaCl) try to use cryptographic primitive routines directly to avoid dependencies.)
2023 added few more low-entropy initialization examples added to the list.
And 2024’s PuTTY key disclosure was due to implementing low-entropy nonces badly for use in VMs and everywhere else.
Won’t someone think of the random numbers?
FIPS Allowed: NIST announced finalized PQC standards for 3
of 4 “winners” (3 more to come)FIPS Approved.
“If it sounds too good to be true…”
Claim is break of “military grade” RSA and symmetric algorithms (like AES) using the cheaper/simpler D-Wave Quantum Annealing computers.
“Interesting if true” as Cousin Millie taught us to say.
$ perl -Mbigint -E 'my $n=845546611823483; my $p=40052303; my $q=21111061; say ($p*$q); say sprintf(q(%d x%x (%db)),$_,$_,length(sprintf(q(%b),$_))) for ($p, $q, $n); say $n-($p*$q);'
845546611823483
40052303 x263264f (26b)
21111061 x1422115 (25b)
845546611823483 x301052970537b (50b)If they actually had scalable factoring with D-Wave Quantum Annealing, that would be shocking breakthrough. That is ^known^ to require real QC like IBM’s; factoring interseting numbers isn’t believed within D-Wave’s capability. Their demonstration of 50b does not appear to be a breakthrough.
Chinese scientists have mounted what they say is the world’s first effective attack on a widely used encryption method using a quantum computer. The breakthrough poses a “real and substantial threat” to the long-standing password-protection mechanism employed across critical sectors, including banking and the military, according to the researchers. Despite the slow progress in general-purpose quantum computing, which currently poses no threat to modern cryptography, scientists have been exploring various attack approaches on specialised quantum computers.
All analysis is preliminary as most of us haven’t seen the paper yet …
A Coded Message found in vintage victorian dress
A cryptogram was found in the pocket of a 19thC silk dress.
Solution required understanding how synoptic meteorologic observations were collected done by telegraphy.
Published academically in August 2023, but released as a Christmas story echo Dec. 2023.
(No “Bennett” was found in Weather Bureau empolyees. Was she possibly a commercial or US Army Signal Service civil Telegraph employee in Wash.D.C. who took a personal copy of two collated messages?)
Bustle_dress_pocket4.mp4 (170M)
{alas original deleted}
TesseractHeart @tesseracthearts;
Iceberg
playlist parts 1 & 2 🎞The YouTube of this presentation will be linked on BLU.org along with these slides and extended notes etc as 2024-oct as per usual.
Prior
talks in this series - most talks have slides &/or
YouTube attached, sometimes extras.
Alas the YouTube audio pre-pandemic wasn’t great, BLU will need a
donation of a wireless clip-on mike if we ever return to
Hybrid/In-Person meetings. Or we all need to wear a wired or BT headset
while presenting in person?
News and Focus sections have embedded links.
Good security news streams to either research history or to follow
year round are Scneier
Crypto-gram and SANS ISC, the
latter being less cryptologic and more operational in focus – but both
cover the wide span of vulnerabilities, tools, remediations, etc, not
just the cryptologic that I’m cherry-picking here.
Highly recommended.
Start your day with the 5 minute SANS Internet Storm Center
StormCast pod-cast; the Red Team is, so, so should you.
See our prior discussions of GEE, VENONA for breaks of One Time Pad↩︎