mvkg

I agree port knocking is a direct violation of Kerckhoff's principle. However, the proposed solution has non-discoverability from unauthorized sources which isn't necessarily in the threat model of OpenSSH or general cryptography. I do feel like this is potentially a desirable trait. I elaborated a bit more here[0], but I'm curious if you have any grander thoughts on how this could be approached

[0]: https://news.ycombinator.com/item?id=49307986

I think the answer is yes. A response from a remote system (or lack of) is a signal. The conventional ssh protocol method when connecting to a server is to instantly send over the identification string. RFC 4253 requires "both sides MUST send an identification string". It doesn't necessarily decide an order, but most ssh implementations I've seen send their protocol string before any other data has been received.

The broadcasting of the versioning information does constitute a potential leakage of information that could be useful to an attacker. Even if we contrast this to something like mTLS, the client certificate doesn't come until fairly late in the handshake, so there is still information that can be cleaned from the ServerHello from an unauthenticated inspector. This is also the case with QUIC since it piggybacks off the general TLS handshake.

I think the issue is, for a known set of systems, can you create communications between them that are oblivious/non-discoverable to non-authorized systems. I think the answer is yes, but it requires an out-of-band key agreement protocol. Wireguard is an example. However, the problem of out-of-band key agreement can't really be ignored.

I think the article's method is somewhat valid. I also think it is non-ideal for only doing source IP based rulesets, especially in the world of IPv4 and NAT being prevalent.

If the tool fails for some reason, couldn't an overly eager agent attempt to fix what's blocking it by digging into the tool (e.g. attaching a debugger or reading memory)? I think the distinction here is that skill+tool will have a weaker security posture since it will inherently run in the same namespaces as the agent where MCP could impose additional security boundaries.

5GHz certainly helps, but congestion/co-channel interference can still be an issue in high density environments, especially in a multi-user environment like an apartment complex where nothing is coordinated. The addition of 6GHz will help alleviate this problem too, but a lot of consumer gear seems to default to the widest channels possible.

Also, your glass door probably has Low-E glass which has a metallic coating.

> The future is probably just having multiple wifi APs wired up and then just running extremely fast but low range wifi.

This is somewhat the case, but it is limited. For example, in 5GHz there are 21x 20MHz channels available. In a highly dense environment, this can support roughly 30x devices per channel well and 50x devices per channel with some degradation.

Limiting the TX power on an AP can help, but it's not a panacea since clients always transmit their control frames at their default power (usually ~15dBm). There have been some improvements to this in .11ax, but depending on the spatial organization of the devices, it can only do so much.

The paper's claim for Dijkstra's is it's "a single algorithm performs as well as possible for every single graph topology". A* is an augmented version of Dijkstra's only applicable when there is a priori knowledge of a good heuristic for the topology (e.g. manhattan distance in a cartesian plane). Since there is almost certainly no heuristic that is universally optimal for all topologies, A* shouldn't be more universally optimal than Dijkstra's (and can probably perform worse given a bad heuristic).

802.1x allows for the client to validate the authentication server by way of X.509 certificates, although this normally does require manual configuration since there is no global namespace to tie an ESSID to like there is for domain names in normal TLS. Mutual asymmetric key auth is available through EAP-TLS as well, but I could see that being a rare feature on cameras.

802.11w

As of TLS 1.3, the ClientHello (which includes the Server Name Identification (SNI) extension) is still sent in plaintext. There is a current draft for encrypted client hellos[0], but I don't think its adoption is widespread. QUIC appears to encrypt the ClientHello; however, it does not protect from an attacker which can observe the initial connection packets[1].

[0]: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

[1]: https://www.rfc-editor.org/rfc/rfc9001.html#name-security-of...

I believe section 7 of RFC 9000 would allow for the creation of a handshake protocol which could conform to SSH without the need for including x509.

It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.

edit: it also has a hardcoded parameter to not validate certs which defeats the whole purpose of it using TLS in the first place... (https://github.com/moul/quicssh/blob/5f5a17c3431a39a8287467d...)

You mirror Z-Library but don't support TLS on any of your sites. This seems like an odd choice. What is your threat model?

Regarding the collision attack replacement check, do you know if that is carried over into other git implementations (e.g. libgit2)?

I have found brave to be a decent chromium-based browser for android if the only addon needed is for ad blocking. It has a bottom toolbar provides a similar experience to the firefox bottom address bar.

What were the PRN and AUX files used for?

In recent versions of (maybe only GNU?) `tar` you can leave off the `z` flag and it will still decompress based on the filename.

A quick look at the source shows that it appears to be linear and just uses `strings.Contains` or `r.MatchString` on each line, so I don't think it has any of the optimizations that are built into `ag`.

The two 'true' statements show that 12345678910111211 == 12345678910111212 transitively, which is obviously not possible.

For what purpose exactly? Surely you don't have multiple developers writing code with one cursor.

With TLS, the symmetric encryption keys are always newly generated regardless of the cipher suite chosen; the difference with the ephemeral cipher suites is how the keys are communicated.

Without forward secrecy, the client chooses the premaster secret, encrypts it with the server's public key, and sends it in the ClientKeyExchange message. With forward secrecy, the client receives signed ServerDHParams in the ServerKeyExchange and responds with ClientDiffeHellmanPublic in the ClientKeyExchange.

The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack.

[0] https://moxie.org/software/sslstrip/

I was a bit surprised to see that it wasn't published on April 1 and got renewed multiple times.

Some parts of it are laughable such as

       IPv10 support on "all" Internet connected hosts can be deployed
       in a very short time by technology companies developing OSs
       (for hosts and networking devices, and there will be no
       dependence on enterprise users and it is just a software
       development process in the NIC cards of all hosts to allow
       encapsulating both IPv4 and IPv6 in the same IP packet header.

But it does have an interesting take on stateless IPv4 <-> IPv6 communication, specifically IPv4 -> IPv6. Obviously it wouldn't work as described without a full deployment, but it seems like something could be done there.

For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.

He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.

IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work.

[0] https://datatracker.ietf.org/doc/draft-omar-ipv10/

It's a good recommended that you don't use them.

https://www.securecoding.cert.org/confluence/display/c/PRE00...

A good dual-stack implementation should also support Happy Eyeballs which does not result in simpler code.