Re: [dev] A secure wireless protocol
Hello Sagar,
> Currently, all phones use WiFi, GSM, Bluetooth networks in practically
> all applications. For WiFi and Bluetooth replacements, do you have any
> alternate network in mind which caters to only local public and private
> keys.
Here in the US, wireless communications are tightly controlled by the FCC. I
just began my studies to become a licensed amateur radio operator ("HAM"), and
it's clear to me from my studies that anything that broadcasts unlicensed
signals will be quickly located and shut down. There may be bands that are not
as tightly controlled, I'll need to defer to someone smarter than me.
All of this is US-specific, I have no clue about other countries' regulations.
--
Josh Lawrence
joshlawre...@fastmail.com
Re: [dev] A secure wireless protocol
Sergey Matveev wrote: >*** Josuah Demangeon [2023-10-15 16:43]: >>Not possible to do "tcpdump -i ipsec0" to see the packets going >>*over* the VPN as there is no network interface for it > >That depends on OS/configuration. There could be literally "ipsec" >interface in FreeBSD to see exactly the packets flowing over that VPN. >https://man.freebsd.org/cgi/man.cgi?query=if_ipsec&sektion=4 That is convenient and intuitively named. >Personally I just used to use gif-tunnels (IP-in-IP) and apply transport >mode ESP to them. Basically it has more-or-less (if we forget about ECN >at least) the same behaviour/efficiency as native tunnel mode (that also >encapsulates IP in IP and encrypts traffic between two tunnel endpoints) >but at least you have gif-interface you can conveniently tcpdump. This is some interesting setup. Then it is not needed to change the IPsec configuration files all of the time, and firewall and routing rules can be edited normally.
Re: [dev] A secure wireless protocol
> (OpenBSD added the pflog interface for tcpdump purpose though) My bad, it is the enc(4) interface: https://man.openbsd.org/enc.4 # ifconfig enc0 enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active # tcpdump -i enc0 tcpdump: listening on enc0, link-type ENC #
Re: [dev] A secure wireless protocol
*** Josuah Demangeon [2023-10-15 16:43]: >Not possible to do "tcpdump -i ipsec0" to see the packets going >*over* the VPN as there is no network interface for it That depends on OS/configuration. There could be literally "ipsec" interface in FreeBSD to see exactly the packets flowing over that VPN. https://man.freebsd.org/cgi/man.cgi?query=if_ipsec&sektion=4 Personally I just used to use gif-tunnels (IP-in-IP) and apply transport mode ESP to them. Basically it has more-or-less (if we forget about ECN at least) the same behaviour/efficiency as native tunnel mode (that also encapsulates IP in IP and encrypts traffic between two tunnel endpoints) but at least you have gif-interface you can conveniently tcpdump. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
Re: [dev] A secure wireless protocol
Sergey Matveev wrote: > *** Sagar Acharya [2023-10-15 18:00]: > >How many devices can connect to IPSec VPN? > > Thousands easily. Depends on bandwidth and CPU speed mainly. You can also find that protocol in almost any 'hardware' router that claims to support a VPN: Mikrotik, StormShield, Fortinet, Cisco... > >What is the private key or secret key for these networks? > > Various. Mostly either PSK (symmetric pre-shared key) or > X.509-certificate-based keypair are used for authenticaion. > (Symmetric) Encryption key of course is derived every time > the IKEv2 session is started with the peer. In attachment, a small "x509" script that I place in my ~/bin to manage certificate by wrapping some of the OpenSSL's tedious syntax. Not prime quality, but could help to get started. > >Where does it lie? > > Where you wish for. Depends on implementation. IPsec itself, its > transport part (ESP protocol) generally live inside the kernel itself. > IKEv2 daemon (like strongSwan for example) lives in userspace. I forgot about that, good point! IPsec is a bit particular as it does not have any network interface for the VPN itself, instead the kernel intercepts the packets going out if they match the configured rule (from Priv1 to Priv2) then encrypt/reroute them and directly send them (from Pub1 to Pub2). Because it all happens in the kernel with no network interface, troubleshooting is a bit particular. Not possible to do "tcpdump -i ipsec0" to see the packets going *over* the VPN as there is no network interface for it (OpenBSD added the pflog interface for tcpdump purpose though). So the various tools like tcpdump, firewall config syntax, etc. have special handling and syntax for it. Keyword: "XFRM". After some time working with it, it becomes more intuitive, but on day 1 I was lost! :) > >Is it secure? > > Depends on configuration parameters, implementation. IKEv2/ESPv3 > protocols in general are secure, yes. It is used by banks, phone systems, corporate VPNs... For debugging, you can try "PSK" or "pre-shared key" authentication which is just a password, to avoid to combine the difficulty of X.509 and IPsec. Josuah. x509 Description: application/shellscript
Re: [dev] A secure wireless protocol
*** Sagar Acharya [2023-10-15 18:00]: >How many devices can connect to IPSec VPN? Thousands easily. Depends on bandwidth and CPU speed mainly. >What is the private key or secret key for these networks? Various. Mostly either PSK (symmetric pre-shared key) or X.509-certificate-based keypair are used for authenticaion. (Symmetric) Encryption key of course is derived every time the IKEv2 session is started with the peer. >Where does it lie? Where you wish for. Depends on implementation. IPsec itself, its transport part (ESP protocol) generally live inside the kernel itself. IKEv2 daemon (like strongSwan for example) lives in userspace. >Is it secure? Depends on configuration parameters, implementation. IKEv2/ESPv3 protocols in general are secure, yes. >In the former case, client will return an md5 sum of earlier packet data to >confirm it received. 1) Neither IPsec, nor WireGuard, nor OpenVPN confirm that packet is received. They just transparently make a secure tunnel for *IP* packets. There is just no need in that kind of confirmation. Why? Internet Protocol is "fire and forget" by design: it just sends IP packet and forgets about it, job is done. If you want guaranteed delivery, then it is the business of transport protocols above, like TCP. IPsec/WireGuard/any-VPN secures IP-level. 2) MD5 in 2023? I hope no, it is not used. Well, actually MD5 is not used as a hash function in IPsec (ESP), but as a part of HMAC-MD5, that is actually still considered safe. But why one need to use that ancient stuff? Modern protocols (WireGuard, Noise, TLS 1.3) use only AEAD-algorithms, where "MAC" is some kind of integrated with the encryption algorithm and they are always used together. IPsec supports AEAD-ciphers in modern OSes a long time ago. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
Re: [dev] A secure wireless protocol
*** Sagar Acharya [2023-10-15 17:22]: >I don't need signing, just encryption. Are you aware that "just encryption" is practically useless, if it does not authenticate transmitted data somehow? By MAC, by AEAD, by signature, but with "just encryption" malefactor in many cases can alter your data without you noticing it at all. >I said, what I want to do. Within wireless space, I want to trasmit a packet >with a fixed header and encrypted data packet. Fire up any kind of VPN. IPsec, WireGuard, whatever. They can transparently secure you IP traffic. IPsec (ESPv3) will literally has its own ESP-header that will carry encrypted+authenticated plaintext IP packet. >I saw, ec cryptography is just signing, will not work. No it is not only for signing. At least it is also for key agreement. If you do not trust WiFi/Bluetooth/public-Ethernet security/encryption (that is completely sane and understandable), then just start VPN over that insecure channel. IPsec (ESP with AEAD ciphers (ChaCha20-Poly1305 or hardware accelerated AES-GCM) + IKEv2 with *25519 key agreement algorithm) or WireGuard are the fastest in nearly all cases. If you do not want to set any kind of IP addresses manually (or by SLAAC/DHCP*), then (at least) WireGuard can work over IPv6 link-local addresses without any problems (I do it). -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
Re: [dev] A secure wireless protocol
*** Sagar Acharya [2023-10-15 16:33]: >How is libcrypto of libressl? Just a library with numerous algorithms. There are plenty of others. >It has no encryption. What about ed448 and aes? Generally no asymmetric encryption is used in modern protocols. Only signing and key exchange operations as a rule. >Where can I find a comparison of all or maximum number of encryption algos and >their speeds? For example LibreSSL/OpenSSL has "openssl list" command and "speed". https://bench.cr.yp.to/ *25519 as a rule the fastest among well-studied asymmetric algorithms https://cr.yp.to/ecdh.html Anyway, why do you want to know that information? Are you going to implement your own cryptographic protocol? If no, then you should look/choose existing implementations/solutions and benchmark/compare them, because even slow-as-hell RSA can be a tiny part of overall computations and the speed of just DH/sign operation can be negligible and play no role. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
Re: [dev] A secure wireless protocol
*** Sagar Acharya [2023-10-14 13:17]: >So, a network which before transmitting a packet, encrypts it with the >recipients' public key and broadcasts it with recipients id as header, say >like, Pay attention that using asymmetric cryptography is pretty CPU consuming task. Using it for each IP packet (or TCP segment, UDP datagram, whatever) is pretty harsh. Moreover if you use modern ECC-based algorithm like curve25519 (that is magnitudes faster than RSA for example, and has pretty compact public keys), then take into account that it can not "encrypt" data, but only to exchange/derive the shared key between the sender and recipient, so you will have to send ephemeral public key with each packet, that will also take at least 32 bytes of the payload more. Like "crypto_box" of NaCl does: https://nacl.cr.yp.to/box.html So if you want usable efficiency, in general you have to do some kind of the handshake, to share the common cryptographic state and then use efficient symmetric cryptography further, like nearly all transport protocols do. Maybe something like Yggdrasil would be interesting to you: https://yggdrasil-network.github.io/ Each peer has its own public/private keypair and corresponding IPv6 address (from 200::/7 space) is derived from the public key. So you can directly communicate with the peer knowing that address in advance. Yggdrasil implementations can discover each other other the multicast IP network (Ethernet/WiFi) without any additional configuration, transparently building the meshed interconnected overlay network. Basically no configuration required (IPv6 link-local addresses should be always present on network interfaces, link-scope multicast packets will find Yggdrasil capable nodes nearby) and you can transparently communicate with each node by its 200::/7 IPv6 address. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
Re: [dev] A secure wireless protocol
On Sat, Oct 14, 2023 at 01:17:04PM +0200, Sagar Acharya wrote: > Dear devs, > > Currently, all phones use WiFi, GSM, Bluetooth networks in practically all > applications. For WiFi and Bluetooth replacements, do you have any alternate > network in mind which caters to only local public and private keys. > > So, a network which before transmitting a packet, encrypts it with the > recipients' public key and broadcasts it with recipients id as header, say > like, > > > > A list of MAC addresses would be maintained on WiFi server end for each > device. Are there already such network softwares made out there? > > The aim is no dhcp and not a single device outside list can communicate. > Thanking you > Sagar Acharya > https://humaaraartha.in/selfdost/selfdost.html > There are different levels of networking layers implementing secure tunnels in different layers (IPSec, TLS, HTTPS, Wireguard, Encrypted XMLs over HTTPS). You could even use public/private encrypted messages on sticky notes or by carrier-pigeon. Maybe I'm getting too old and conservative, but I'd use the standards (RFC) that are there. Bluetooth kinda sucks though. -- Kind regards, Hiltjo
[dev] A secure wireless protocol
Dear devs, Currently, all phones use WiFi, GSM, Bluetooth networks in practically all applications. For WiFi and Bluetooth replacements, do you have any alternate network in mind which caters to only local public and private keys. So, a network which before transmitting a packet, encrypts it with the recipients' public key and broadcasts it with recipients id as header, say like, A list of MAC addresses would be maintained on WiFi server end for each device. Are there already such network softwares made out there? The aim is no dhcp and not a single device outside list can communicate. Thanking you Sagar Acharya https://humaaraartha.in/selfdost/selfdost.html
