Re: OpenBSD insecurity rumors from isopenbsdsecu.re
Hello, Le 07/05/2020 à 16:00, i...@aulix.com a écrit : Can you please comment negative appraisal from the following website: https://isopenbsdsecu.re/quotes/ I did not want to hurt anyone, just looking for a secure OS and OpenBSD looked very nice to me before I have found this website. This explanation [1] from the author of the site should be enough for you: Why was this website created? Someone was bragging on IRC about how secure OpenBSD is compared to everything else, but this came without concrete evidences. Tired of having to endure this once too often, time was spent documenting OpenBSD’s security features: where are they coming from? against what are they defending? how successful are they? Because, in the words of Ryan Mallon: Threat modelling rule of thumb: if you don’t explain exactly what you are securing against and how you secure against it, the answers can be assumed to be: “bears” and “not very well”. The quotes were chosen to be especially aggressive but we could find as many against other operating systems. For me it's on the same level as "The UNIX-HATERS Handbook" [2], just a big ball of hate and FUD. After full reading, out of 52 exposed points there are 4 frankly against OpenBSD, 12 for OpenBSD and all the rest is opinion and filling. It wants to be impressive, but it’s just swank of a meticulous hater. Regards, [1] https://isopenbsdsecu.re/about/ [2] https://web.mit.edu/~simsong/www/ugh.pdf Mitigations Arc4random [...] Nowadays, arc4random in userland is available on various platforms, even when not being natively implemented, thanks to libbsd. NetBSD, FreeBSD, Linux, … have all moved to a ChaCha20-based CSPRNG. Even Tor is now using some of its code, for performance reasons. OpenBSD took inspiration from Linux two decades ago, but nowadays, it’s the other way around, OpenBSD is driving the CSRPNG game! OK. ASLR [...] OpenBSD randomizing everything is neat, and forces attackers to find/create better leaks. But nowadays, all the modern operating systems have those kind of mitigations, are are now focusing on killing bugs exploitable when an attacker has some reading capabilities. And what are these modern OSes? OpenBSD is a fossilized and archived OS on archive.org? Atexit hardening [...] In the glibc, the pointers to the function are obfuscated with a rol+xor via the PTR_MANGLE macro against a secret, which is roughly equivalent to what Windows is doing. This mitigation is completely bypassed with an arbitrary read: get the secret, obfuscate the pointer to your payload, done. Musl has no hardening at all On OpenBSD, the pointers are stored in a read-only memory zone, only made writeable when __cxa_atexit is called. To bypass this, an attacker would need to get code execution to modify the permissions of the memory zone. Where is the point? Development practises - Development practises OpenBSD got no continuous integration system, and apparently build breakage are, according to the FAQ, happening from time to time [...] There is a code style, but since it’s not automatically enforced, if only because there is no CI. The VCS used is CVS, the Concurrent Versions System [...] This is not what makes security! Development practises - Code reviews OpenBSD claims that they have “between six and twelve members who continue to search for and fix new security holes”, but it seems that this doesn’t prevent low-hanging bugs from entering the codebase, for example: [...] Ah, because those who don't read their code are more likely to find errors? Development practises - Security advisories OpenBSD is publishing security issues on its Errata pages, but doesn’t provide much context nor analysis. [...] Ok, that's a point, but is it necessary to point to the way of reproducing an exploit after having patched it? It is a practice, nothing more, which neither adds to nor takes anything away from security. Disk encryption [...] This is looking like a solid design, pretty similar to what LUKS is doing. Unfortunately, it doesn’t support using a TPM or an enclave (like Intel’s SGX, AMD’s SEV, …) to perform key-derivation and prevent offline bruteforcing. Pathetic. Embargoes handling OpenBSD isn’t usually included in security embargoes anymore, likely because they have the bad habit of not playing well with them, although they never technically broken one. [...] And should we play the game of the one with the cleanest ass? Explicit_bzero and bzero [...] While it might get optimized away when using static linking with LTO, it’s sill a neat way of improving forward secrecy, by trying to remove cryptographic materials from memory as soon as possible. Where is the problem? OBSD +1 Fork
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
At risk of responding without having read through the entire website, it seems to mostly be about OpenBSD's exploit mitigations, and nothing else. But OpenBSD does a lot of other things well, like doing lots of code reviews, having a culture of writing code with an eye toward security in the first place, providing API's that are more difficult for developers to misuse (strlcat, pledge), and generally good design like building things with privilege separation in lots of places. OpenBSD also has lots of mitigations, but then so do other OS'es. Mitigations have always been and will probably always be a controversial and fraught topic. That's because mitigations are just that - they're *mitigations*. For the most part they're not supposed to provide more-or-less impenetrable security barriers like with privilege separation, memory safe languages, etc. They're just there to make an attacker's life harder and their chances of success lower than otherwise. For this reason, they're subject to an endless arms race, with developers always introducing new and interesting mitigations, and exploit writers always researching fun and bizarre ways to work around them. The best an OS can do is to stay as close to the state of the art as possible. So, there's probably some valid criticisms in there (I haven't read through them all), but "some of OpenBSD's exploit mitigations have some issues" is not grounds to say that OpenBSD is bad or insecure, as a blanket statement. OpenBSD has a lot of great things going for it. My 2 cents, BW On Thu, 07 May 2020 07:00:15 -0700 wrote Dear OpenBSD fans, Can you please comment negative appraisal from the following website: https://isopenbsdsecu.re/quotes/ I did not want to hurt anyone, just looking for a secure OS and OpenBSD looked very nice to me before I have found this website. Kind Regards
Full disk encryption FAQ update request
We had a VPS customer ask for help on full disk encryption, and since following the instructions on https://www.openbsd.org/faq/faq14.html#softraidFDE did not work with a serial console, we published a blog post on it: https://prgmr.com/blog/openbsd/2020/05/08/openbsd-encrypted-root.html I don't know how to submit a patch to the related FAQ entry, and the footer on https://www.openbsd.org/faq/index.html says to email here with comments. Can the information on the serial console + encrypted root be added to the FAQ please? Regards, Sarah
TOFU/cert pinning in libtls
I am currently implementing a simple C client for the gemini protocol[1]. All transactions are protected using TLS, with a catch: > Clients can validate TLS connections however they like (including not > at all) but the strongly RECOMMENDED approach is to implement a > lightweight "TOFU" certificate-pinning system which treats self-signed > certificates as first- class citizens. This greatly reduces TLS > overhead on the network (only one cert needs to be sent, not a whole > chain) and lowers the barrier to entry for setting up a Gemini site > (no need to pay a CA or setup a Let's Encrypt cron job, just make a > cert and go). My basic idea for the client is: - load a db of self-signed certs. - connect to host - if host cert is self signed - if not in db, prompt user and add to db - if in db, check fingerprint and warn user if they don't match. Browsing the manuals/source code, there doesn't seem to be an easy way to configure this. I don't want to have to use the OpenSSL API for this :(. P.S. Big shoutout to Bob for his tutorial[2], it's a great introduction to an awesome library! [1] https://gemini.circumlunar.space/docs/spec-spec.txt [2] https://github.com/bob-beck/libtls/blob/ -- Stephen Gregoratto
Re: TOFU/cert pinning in libtls
On 2020-05-09, Bob Beck wrote: > > oolong$ man -k Xr=tls_peer_cert_hash > > nc(1) - arbitrary TCP and UDP connections and listens > > > > That's far from ideal IMO, but I don't know where, of the many tls_* > > manpages, would I reference it. > > man tls_peer_cert_hash > > happily brings up the man page on my machines. For reference, the relevant quote from tls_init: The properties of established TLS connections can be inspected with the functions described in tls_conn_version(3) and tls_ocsp_process_response(3). It's just one line and may be easy to pass over, but it is there.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Some time ago Google bought 2000qbit version from D-wave and confirmed it is a quantum computer bla bla bla... but cluster consists of eight qbit blocks to build advertised capacity if I understand googles papers right. My question was about decrypting currently generated and accumulated encrypted traffic after five - ten years on quantim computers if they were available. And which crypto algo. I have to use right now to prevent decryption in post quantum computing era. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, May 9, 2020 2:34 PM, wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course).
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On Sat, May 9, 2020 at 1:05 PM Kevin Chadwick wrote: > Careful of what sources you trust! If a processor was storing the keys used, > non > volatile then people would have found out. Software encryption wouldn't save > you > either. If there is a back door it won't have anything to do with AES-NI that > can be analysed so easily. Indeed -- human based key compromise issues severely outweigh the risk of direct attacks on a tcp session with encrypted content. That said, the risk with encrypted material here is not attacks on individual sessions but opportunistic attacks on large bodies of sample material (with, of course, human assist which will often have economic basis and vectors). (That said, I would also keep in mind also that supposedly the computer industry has hit a performance wall because of Moore's Law issues. But, assuming that there's a thread of truth in the marketing, we also have reason to believe that 5G switches at speeds an order of magnitude faster than anything we see on computer busses. So it's not just about the size of the transistors. And, sure, there's real issues there, but I think we have to assume that some of what we're hearing about computational abilities and limits isn't completely factual.) Thanks, -- Raul
Re: TOFU/cert pinning in libtls
On Sat, May 09, 2020 at 06:18:50PM +, Lucas wrote: > Hello Stephen, > > > My basic idea for the client is: > > > > - load a db of self-signed certs. > > - connect to host > > - if host cert is self signed > > - if not in db, prompt user and add to db > > - if in db, check fingerprint and warn user if they don't match. > > > > Browsing the manuals/source code, there doesn't seem to be an easy way > > to configure this. I don't want to have to use the OpenSSL API for this > > :(. > > I experimented with cert FP pinning in the past, too. tls_peer_cert_hash > is probably what you're looking for. Found it looking at > /usr/include/tls.h. Then tried to find it referenced in other manpages, > > oolong$ man -k Xr=tls_peer_cert_hash > nc(1) - arbitrary TCP and UDP connections and listens > > That's far from ideal IMO, but I don't know where, of the many tls_* > manpages, would I reference it. man tls_peer_cert_hash happily brings up the man page on my machines.
@OpenBSD_CVS Twitter 140char limit?
Hi there! Does anybody on this list manage @OpenBSD_CVS? Would be nice to lift the message truncation from the old 140char limit to the new 280char limit. Super annoying when I can't read an interesting commit message that is just a little longer :) -- TN
Re: reposync out of memory
Stuart Henderson wrote: > I can add something to the readme after the ports tree has unlocked. > > I think you're seeing this now due to the churn because every file in > the repositories was touched when the tree was tagged with OPENBSD_6_7. > I haven't seen it on the 2 machines I have running reposync, but they > update more frequently so probably didn't have to deal with updating > all of ports+src+xenocara together, which is probably what tipped it > over the edge. For the archive, creating a new login class bumping datasize-cur and adding cvs to that new login class did the trick. I doubt that's the magic number tho, as I went over half of ports repo before that change, so ymmv. # # reposync might choke during releases with default datasize # reposync:\ :datasize-cur=1024M:\ :tc=default:
Re: TOFU/cert pinning in libtls
Hello Stephen, > My basic idea for the client is: > > - load a db of self-signed certs. > - connect to host > - if host cert is self signed > - if not in db, prompt user and add to db > - if in db, check fingerprint and warn user if they don't match. > > Browsing the manuals/source code, there doesn't seem to be an easy way > to configure this. I don't want to have to use the OpenSSL API for this > :(. I experimented with cert FP pinning in the past, too. tls_peer_cert_hash is probably what you're looking for. Found it looking at /usr/include/tls.h. Then tried to find it referenced in other manpages, oolong$ man -k Xr=tls_peer_cert_hash nc(1) - arbitrary TCP and UDP connections and listens That's far from ideal IMO, but I don't know where, of the many tls_* manpages, would I reference it. HTH, -Lucas
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 16:25, i...@aulix.com wrote: > Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON > processor hardware, it doesn’t play a role, what other OS you install or boot > afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel > AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then > automatically contain that U.S. government backdoor! Careful of what sources you trust! If a processor was storing the keys used, non volatile then people would have found out. Software encryption wouldn't save you either. If there is a back door it won't have anything to do with AES-NI that can be analysed so easily. I'm conscious of being far from OpenBSD relevance, so excluding myself from this thread now.
Re: reposync out of memory
On 2020-05-09, Lucas wrote: > Hello misc@, > > Starting today, reposync is running out of memory for me. Happened 3 > times in a row already, in different stages. It looks like this when it > happens: > >>f.st.. ports/net/megatools/pkg/PLIST,v > ERROR: out of memory in flist_expand [receiver] > rsync error: error allocating core memory buffers (code 22) at util2.c(105) > [receiver=3.1.3] > rsync: [generator] write error: Broken pipe (32) > rsync error: error in socket IO (code 10) at io.c(820) [generator=3.1.3] > rsync: [receiver] write error: Broken pipe (32) > reposync: rsync failed > > I'm issuing the following command: > > oolong$ doas -u cvs /usr/local/bin/reposync > rsync://obsdacvs.cs.toronto.edu/obsdcvs/ /home/cvs > > I set up cvs user as described in the pkg-readme: > > oolong$ getent passwd cvs; id -c cvs > cvs:*:1001:1001::/nonexistent:/sbin/nologin > default > > default class is unaltered in the system: > > default:\ > :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin > /usr/local/sbin:\ > :umask=022:\ > :datasize-max=768M:\ > :datasize-cur=768M:\ > :maxproc-max=256:\ > :maxproc-cur=128:\ > :openfiles-max=1024:\ > :openfiles-cur=512:\ > :stacksize-cur=4M:\ > :localcipher=blowfish,a:\ > :tc=auth-defaults:\ > :tc=auth-ftp-defaults: > > FTR, I'm using reposync since it came out and this is the first time it > happens. I update once a week, if that matters. > > Is anyone experiencing this too? I guess I can work it around bumping > datasize for cvs user, but if this is happening to other ones, maybe > it's worht to add something to the pkg-readme. I can add something to the readme after the ports tree has unlocked. I think you're seeing this now due to the churn because every file in the repositories was touched when the tree was tagged with OPENBSD_6_7. I haven't seen it on the 2 machines I have running reposync, but they update more frequently so probably didn't have to deal with updating all of ports+src+xenocara together, which is probably what tipped it over the edge. > Just in case, dmesg can be found after the email. Thanks in advance. Thank you for the nice clear report.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Though I am a very noob in understanding crypto from a mathematical point of view (not just as an user of some ready program) IMHO following message can contain some truth about insecurity and intentional flaws of hardware crypto in X86 CPUs: https://support.nitrokey.com/t/spectre-or-meltdown-vulnerability/850 https://archive.fo/bF0gg Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON processor hardware, it doesn’t play a role, what other OS you install or boot afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then automatically contain that U.S. government backdoor!
reposync out of memory
Hello misc@, Starting today, reposync is running out of memory for me. Happened 3 times in a row already, in different stages. It looks like this when it happens: >f.st.. ports/net/megatools/pkg/PLIST,v ERROR: out of memory in flist_expand [receiver] rsync error: error allocating core memory buffers (code 22) at util2.c(105) [receiver=3.1.3] rsync: [generator] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(820) [generator=3.1.3] rsync: [receiver] write error: Broken pipe (32) reposync: rsync failed I'm issuing the following command: oolong$ doas -u cvs /usr/local/bin/reposync rsync://obsdacvs.cs.toronto.edu/obsdcvs/ /home/cvs I set up cvs user as described in the pkg-readme: oolong$ getent passwd cvs; id -c cvs cvs:*:1001:1001::/nonexistent:/sbin/nologin default default class is unaltered in the system: default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\ :umask=022:\ :datasize-max=768M:\ :datasize-cur=768M:\ :maxproc-max=256:\ :maxproc-cur=128:\ :openfiles-max=1024:\ :openfiles-cur=512:\ :stacksize-cur=4M:\ :localcipher=blowfish,a:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: FTR, I'm using reposync since it came out and this is the first time it happens. I update once a week, if that matters. Is anyone experiencing this too? I guess I can work it around bumping datasize for cvs user, but if this is happening to other ones, maybe it's worht to add something to the pkg-readme. Just in case, dmesg can be found after the email. Thanks in advance. -Lucas OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3944083456 (3761MB) avail mem = 3811930112 (3635MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) bios0: vendor LENOVO version "G2ET33WW (1.13 )" date 07/24/2012 bios0: LENOVO 2325BG4 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.52 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 1197.29 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "45N1029" serial 15304 type LION oem "LGC" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 1197 MHz: speeds: 2601, 2600, 2500, 2400,
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:34, i...@aulix.com wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course). I don't care for the details. D-waves tech has no hope of breaking any crypto in use today is what I have heard from reputable sources. Googles needs to go from 53 to an estimated more than 3000 for nistp-521 with each one being exponentially harder to manage. RSA 8192/4096 are the next best options but RSA takes exponentially longer to generate larger keys. Don't worry. The work is to be ready in case someone with enough funds makes a breakthrough. There is almost zero chance for many many years. You can always mix in a static symmetric key, if really needed or encrypt the data first with a static key? Wireguard offers mixing in a static key as an optional extra config option but wireguard has chosen not to support AES, so will be a lot slower on many modern processors and microchips that have AES hw support. The wireguard author seems to think the opposite about micro support, but he is wrong.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:31, i...@aulix.com wrote: > guessed by quantum provided session symmetric cipher is strong enough? Quantum does not break any in use today and AES-256 symmetric is expected to be quantum resistant in any case. I personally prefer AES-256 ctr over the more complex GCM. I am not a developer btw.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
D-waves has too uncoupled qubits if I understand it correctly, it is nothing to do about qubits quantity as we used to think about it. Like a "cluster" of completely isolated hosts (which is already not a cluster or course).
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
OpenSSH allows to use hybrid mode with many private keys of different type and even stored on different hardware like Nitrokey, Rutoken, etc. at the same time for a single session. E.g. 4 different private keys are required (say Nitrokey, Rutoken ECP2, Curve25519 and Postquantum one): AuthenicationMethods=publickey,publickey,publickey,publickey Will it prevent session analysis if only some part of keys (not all) were leaked or guessed by quantum provided session symmetric cipher is strong enough?
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
This one https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html is the most powerful 5000qbits quantum computer sells nowadays. Moreother, D-Wave opened online service to access 5000qbit remotely for solving 'special' tasks which can be accelerated using quantum architecture. In 2016 Google tested some encryption sub-layer in Chrome browser to test quantum resistant encryption algo. According to current online data collecting practices, after six years most of 'old' algorithms will possible to decrypt directly from storage by 'modern' quantum computers. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, May 9, 2020 5:05 AM, wrote: > According to Damien Miller: > > > this is pretty much possible now, by enabling the experimental support > > for the XMSS PQ signature algorithm > > in the SSH
Re: gnutls cannot connect to openbsd.org -- TLS 1.3 issue?
Has been fixed in LibreSSL. Thank you!
Re: gnutls cannot connect to openbsd.org -- TLS 1.3 issue?
On 2020-05-08, openbsdli...@uninformativ.de wrote: > It only fails with gnutls, so I first reported it there: > > https://gitlab.com/gnutls/gnutls/-/issues/984 > > However, Daiki Ueno said it looks like an issue with LibreSSL. Quoting > in full: > >> This looks like an issue in the server side (LibreSSL). In TLS 1.3, >> non-PSS RSA signature schemes have been removed, while the server >> seems to sign the Certificate Verify message with RSA-SHA256, which is >> not permitted. > > I'm not really an expert on TLS or cryptography, so no idea what's going > on, which is why I'm reporting it on misc first. :-) > > Should this be reported to libre...@openbsd.org? To save antone else time lookong: this is fixed, see beck@'s comment on the gitlab ticket.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. D-waves definition of qubit is different and their machines will never be capable of breaking public key cryptography using Shor's algorithm. I assume they want free publicity that you are giving them.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. > > Moreother, D-Wave opened online service to access 5000qbit remotely for > solving 'special' tasks which can be accelerated using quantum architecture. > > In 2016 Google tested some encryption sub-layer in Chrome browser to test > quantum resistant encryption algo. > > According to current online data collecting practices, after six years most > of 'old' algorithms will possible to decrypt directly from storage by > 'modern' quantum computers. That last sentence doesn't even make sense but is completely wrong. Decrypt according to? No Googles computer was an impressive jump to 53 qubits but every qubit is exponentially harder to keep stable. The pqcrypto project estimated far longer before an algorithm is broken by a computer and even then I believe they are talking about weaker keys. Not in our lifetime is often mentioned. It is quite possible and in my opinion probable that a nistp-521 key will never be broken by a quantum computer. I assume this is coming from the recent release of code by the PQCrypto project for OpenSSL. The PQCrypto project hasn't concluded yet. You should not use it yet especially without existing crypto too. There are some conservative algorithms that may not win the competition that are arguably useable under certain conditions but that is aside from the point. The one OpenSSH has developed is one of those.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 5/8/20 3:16 PM, Martin wrote: > Which 'quantum' resistant algorithms can be used right now to prevent data > decryption in future by 'quantum' computers (when they can do this) of > currently collected data flows? this is so dumb. worry about this when there are computers which can actually add two numbers quantoonly. aisha > > Martin >
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
According to Damien Miller: >this is pretty much possible now, by enabling the experimental support for the XMSS PQ signature algorithm in the SSH
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
https://www.technologyreview.com/2018/02/21/145300/serious-quantum-computers-are-finally-here-what-are-we-going-to-do-with-them/ https://www.microsoft.com/en-us/research/project/post-quantum-ssh/ https://openquantumsafe.org/ Why not to add post quantum algos to the SSH mainline to make them easily available at once in all up to date distros?
