Re: [qubes-users] New Foreshadow exploits CPU bug
On 08/21/2018 11:39 AM, taii...@gmx.com wrote: > SGX is another ME service slash intel marketing gimmick invented for DRM > not security. > > If the person who purchased the computer can't examine the VM's running > on it then they are not owning it simply licensing it which is why SGX > is a bad technology and people shouldn't buy x86. Consider you want to deploy your things in the cloud, eg. because it's less expensive. Then I guess you would actually like to not have to trust the cloud provider :) You still have to trust Intel for actually doing what they promise, but you have to trust the processor manufacturer at some point anyway. Not saying SGX actually meets its promises, though, just reacting to your second paragraph. There are use cases for having the person who owns a computer not being able to examine VM's running on it. Whether you want or not to use or have them is a different question. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b3d6a5d2-215b-ac7e-28b5-d50b01ff77b3%40leo.gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?
On 05/16/2018 11:20 PM, Ilpo Järvinen wrote: > On Wed, 16 May 2018, taii...@gmx.com wrote: > >> On 05/15/2018 01:22 AM, john wrote: >> >>> On 05/14/18 14:58, Ángel wrote: This paper is most interesting for the discovery of multiple ways email client leak information on visualization. (not clearly stated in the paper: some of them are already fixed, while in other cases the developers are still working on providing them) Luckily, with Qubes it is easy to set a firewall rule so that your email AppVM can only contact with your email server. NB that some of these leaks are dns-based, so ideally you would not allow it to perform any dns query, either. Best regards >>> can you give an example to the steps to make such a fw rule, if >>> it's that simple please ? >> I would suggest simply only allowing the ports you need for your email >> client. > > It's much less secure approach than blocking all but the email server > address. With a port filter, the attacker only needs to use that same > port for the attack to succeed. That's true, except HTML engines like the ones used by this attack should disallow eg. loading an image from port 25. For instance, firefox blocks at least ports 993 and 587, the only two that should be used by a reasonably recent and secure email setup. So that's not a solution against an arbitrary attacker, but that's a solution against the currently-spoken-about attack. BTW, if you really want to protect yourself from an arbitrary attacker, you'll want to protect against an attacker that has root on your email VM. And that means 1/ setting firewall rules in the FirewallVM, not in the email VM, as the latter could just be removed by the attacker 2/ all kinds of hardening against side-channels for compromised VM communication, that are currently not possible with Xen (and possibly not even with any widely-spread hypervisor, as that would likely entail a huge performance cost) Another solution for 2/ could be to never run the email VM at the same time as another potentially-compromised VM, but that very much restricts what you can do. And that can maybe (now that's all hypothetical) still be by-passed with side-channels through eg. LVM's thin pool allocator, as IIRC Qubes4 uses LVM thin pools as storage backend. (still haven't migrated…) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/436c6811-9ca0-bd0b-0c21-f2097248d43c%40leo.gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?
On 05/14/2018 02:45 PM, mossy wrote: > embargo broken early, attack/vulnerability details here -- > https://efail.de/ > > (and yes it seems like disabling HTML will mitigate the most > reliable/least complex attacks) Incidentally, the GnuPG press release, that raises the point that the paper may not be totally correct: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html Also if I understand correctly the latest exchanges from the GnuPG ML, Enigmail 2.0 is safe from attack except for 3DES ciphertext, so the attack could there only turn enigmail as a 3DES-ciphertext-decrypting oracle. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e69a90c3-0c95-2ece-a356-d2e860b74276%40leo.gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Critical PGP bugs. Do they possibly affect Split-GPG in Qubes?
I can't tell for sure for not having read the paper, but it sounds like too much hype for vulnerabilities not so important: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html (Werner being the maintainer of GnuPG) So I wouldn't worry about (but why not disable automatic decryption/verification of incoming emails in the meantime, doesn't cost much) On 05/14/2018 10:33 AM, magionemagi...@gmail.com wrote: > I know that right now details are sketchy but the advice of disabling PGP is > sound at least until we get to know more information, especially since it's > coming from reputable researchers and the EFF (links below but I guess > everybody here already knows about that), so obviously that there is ground > for worry. > > Do any of the Qubes users or devs know more at present about this issue or > have advice to provide, aside from waiting for the publication of the > research paper tomorrow morning (15th of May) and stopping using Split-GPG > for the time being as a precaution? > > https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now > > https://arstechnica.com/information-technology/2018/05/critical-pgp-and-smime-bugs-can-reveal-encrypted-e-mails-uninstall-now/ > > Thanks. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/55413b21-14d9-b470-37c1-55433c1db6cf%40leo.gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R4.0 drops USB data
On 03/08/2018 02:12 PM, Ed wrote: > [...] > > Are you passing the device through to another VM? > > The USB pass-through method has given me issues in the past for devices > that use a lot of bandwidth (webcams), though you are saying data is > lost after only a few bytes, I still might be suspect of the USB > passthrough system in qubes... > > So if you ARE passing through you might want to try running the scanner > software directly from sys-usb to see if you can eliminate the USB > passthrough as a source of problems. Oh, I thought it was a hardware issue, but did hit the same issue (on R3.2, haven't tried R4 yet). FWIW, [1] references this issue along with a potential workaround. That said, running still more things in sys-usb just increases once again the attack surface to sys-usb, which is already way too high imo, so that workaround isn't perfect… [1] https://github.com/QubesOS/qubes-issues/issues/2594 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/405d23b9-a58c-4047-ff17-7817dcfac239%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: porting to ARM
On 01/12/2018 12:45 PM, 'awokd' via qubes-users wrote: > On Fri, January 12, 2018 8:59 am, Ph.T wrote: >> . my initial motivation for ARM was that >> intel seemed more prone to #spectre than ARM; >> https://developer.arm.com/support/security-update >> "majority of Arm processors are not impacted >> by any variation of this side-channel speculation mechanism." > > AMD is less prone than Intel too. :) The vast majority of ARM processors that are not impacted by spectre is the one that doesn't do speculative execution, afaik. So that's basically all the “embedded” ones you wouldn't want on a desktop computer because they are too slow. Then hopefully I'm not thinking of some processors that would be both unaffected by spectre and performant... :) >> and is ARM saddled with ME or SMM? ...not sure. > > It has https://www.arm.com/products/security-on-arm/trustzone, but I don't > know if owner controlled implementations are available or not. I don't know TrustZone, but TrustZone-M (on Cortex-M's, embedded world processors) you can choose what code runs in the TrustZone-M (which is quite the point) [1]. A quick google search also makes me think with TrustZone-A too (the “performance” branch of ARM), eg. on RPi, you can run custom code in it [2], though I haven't read the full paper. That said, for security reasons it is necessary to lock down the secure OS in order to prevent offline modification, as it would pave the way towards evil maid attacks. [3] seems to give ways to do that. And so manufacturers could, if they wanted to, decide to just sell the chips with locked-down secure OSes, not giving any way for the user to change them. [1] https://link.springer.com/chapter/10.1007/978-3-319-66332-6_12?no-access=true [2] https://arxiv.org/pdf/1605.07763.pdf [3] https://www.sbs.ox.ac.uk/cybersecurity-capacity/system/files/ARM%20Security%20Technology.pdf -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e2595cd9-1d69-0430-5a02-d1b2c01c6cf7%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
POWER9 (was: Re: [qubes-users] Re: porting to ARM)
Am I the only one to notice you brought up POWER/TALOS something like five times in the last week, even when the thread originally had nothing to do with it (like this one)? I get it you're enthusiastic about an open processor getting actually used (unlike RISCV) (and must say I am too), but it's not really an option for Qubes (which is the topic of the mailing list), so long as no-one has ported Qubes to it (and unless you have a lot of money I don't see anyone deciding to port Qubes to POWER only based on your assertions). However, even with open hardware design, all problems are not solved. For once, there is no real checking of whether the product you buy actually matches the specification you received. (And the main issue with Intel ME or Meltdown/Spectre is actually that the implementation doesn't match the spec, as the spec is safe.) For instance, I recently heard of a paper at a cryptographers' conference (don't have the reference, sorry), where researchers designed a hardware implementation of AES that worked perfectly, then changed three wires, and had a hardware implementation that still worked perfectly -- until you change a bit the frequency, and then the encryption is utterly broken. Three wires at 14nm on modern systems with the 8G transistors of POWER9, good luck to spot them. Oh, and also contrarily to what you say POWER9 is not more owner-controlled than amd64, at least according to the specification (and as stated before the implementation does not necessarily match the information you are given). That said, the two big advantages of POWER9 (or RISCV) to me are that it democratizes the idea of open hardware, and that bugs in it could maybe be found more easily than if it was closed-source (even though it's doubtful Meltdown/Spectre would have been found more easily were the implementation open -- the fact that POWER9 is also vulnerable to them is an element of proof towards that). As the chip is actually not really possible to check, it doesn't help with voluntarily inserted backdoors. Just my 2¢ :) Leo On 01/11/2018 01:25 AM, taii...@gmx.com wrote: > On 01/10/2018 05:34 PM, Vít Šesták wrote: > >> Maybe absence of suitable hardware is the reason why we don't have it. > The target I imagine would be ARM servers with performance ARM CPU's > such as the ones from Gigabyte running AppliedMicro CPU's. > > Unlike the high performance POWER these ARM CPU's suck at single > threaded tasks and are not owner controlled like POWER AFAIK so I don't > think it is worth it. > The only reason to do so would be the already available xen vs no xen > ATM for POWER - but you could definitely do it and it would run qubes > satisfactory. > > And yes ARM has a kind of IOMMU, I believe it is called GIC-v3 but not > available on the average ARM stuff like a laptop or phone. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5bb92339-c4a1-3229-f086-29e089b1d578%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Mozilla
On 12/27/2017 07:38 PM, taii...@gmx.com wrote: > On 12/26/2017 06:34 PM, Leo Gaspard wrote: > >> (disclaimer: I once was an intern for Mozilla, though I do not have any >> bond with Mozilla right now) >> >> tl;dr: please do google for “looking glass” and “mozilla” >> >> Erhm. This is a *really* biased way of putting things. They did push an >> (opt-out) study through the (opt-out, iirc) studies subsystem, that did >> have the ability to alter page content. >> >> That said, the add-on was not programmed to not show up in the ‘add-on’ >> screen (that I know of), it was just a regular opt-out shield study. > No one wanted that dumb addon and most users aren't going to opt-out - > that is why "opt out" systems are a scam; what mozilla did was > incredibly wrong and I can't believe you are sticking up for them > without even receiving a full time wage from mozilla. > > How many things does the average person need to keep track of when it > comes to opting out? did you know that if you get in to an accident and > need blood transfusions the local hospital may give you synthetic blood > that increases the chance of dying? guess you had better opt-out of that... Once again, I'm not saying anyone wanted that add-on. But not opting-out of it caused no harm, nor was it meant to cause harm. I'd rather follow Hanlon's razor and never attribute to malice that which is adequately explained by stupidity, but that's only my opinion. That's basically all I was saying. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bd285322-4207-d5a3-005e-da4854a6ed6c%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Mozilla (was: Re: [qubes-users] Password security/disposable vm security)
On 12/26/2017 03:25 PM, 'Tom Zander' via qubes-users wrote:>> "Personally, I' d avoid thunderbird and anything from mozilla, but thats >> just me." >> Do they have a bad track record(I planned on researching my apps later >> =p). > > Just last month they added an invisible plugin in their binary builds which > was programmed to not show up in the 'add-on' screen and had the ability to > alter page content. > Someone didn't actually program it well enough and the whole thing got > leaked and after a lot of heat, a lot of bad press they eventually > apologised. > > I'm more concerned that they tried then how they failed. > It leaves a bad taste in my mouth. > > Google for "looking glass" and "mozilla" if you want to know more. (disclaimer: I once was an intern for Mozilla, though I do not have any bond with Mozilla right now) tl;dr: please do google for “looking glass” and “mozilla” Erhm. This is a *really* biased way of putting things. They did push an (opt-out) study through the (opt-out, iirc) studies subsystem, that did have the ability to alter page content. That said, the add-on was not programmed to not show up in the ‘add-on’ screen (that I know of), it was just a regular opt-out shield study. Now, the handling of this particular instance has indeed been stupid: this study was actually no study, but a promotional event organized with the Mr. Robot series (which explains the ability to alter page content, though I'm obviously not saying anyone wanted it), and in addition to this it appeared with the suspicious “My reality is different than yours” message, which made some users think they had been infected by some virus. So I'm not saying this was not a particularly stupid action and that they did not end up with woefully bad press (especially damaging given they had just outed Firefox 57 and its long-awaited changes), but it's nowhere near as bad as what you imply, ie. that they would already have willingly pushed a malicious add-on. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/421f892b-2758-d853-1bea-33b9e1bc24f1%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Suggestions (for forum posts)
On 12/03/2017 04:02 AM, Andrew David Wong wrote:>> No, a Google Account is not required. Many people who use the >> Qubes mailing lists never create one. If you're subscribed to one >> of the lists, you should be receiving every message sent to that >> list. (Of course, you won't retroactively receive emails that were >> sent to the list before you subscribed.) > >>> Really? I must be doing something wrong. I had origonally sent a >>> message to qubes-users+subscr...@googlegroups.com and got a >>> confirmation message but I dont get any messages except some of >>> the responses to my posts that I sent to >>> qubes-users@googlegroups.com I will read the mailing list page >>> again because I think I have missed an important detail > > I just tried to search for your email address in the list of > qubes-users subscribers, and it's not there. So, it looks like your > address was never successfully subscribed, or it was unsubscribed at > some point. I recommend that you try to subscribe again. Hmm, just a suggestion: if people aren't expected to Cc: everyone involved in a thread when replying, maybe it'd be better to set the google groups to only allow incoming messages from subscribed email addresses only? The error message is not very informative, but it would avoid issues like this one, by forcing people to subscribe before asking questions? Then it's less user-friendly, so there's a choice to be made, if it hasn't been made already. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2bcba28b-42ad-85bc-ab29-e34f3efc2d6d%40gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes support Secure Boot
On 12/02/2017 03:11 AM, taii...@gmx.com wrote: > On 11/23/2017 07:55 AM, Leo Gaspard wrote: > >> Can you please avoid ranting against secure boot once again? >> >> Secure boot is *not* useless. It *does* bring security benefits, >> although not as good as measured boot with a TPM: it requires an >> additional flaw somewhere in the {BIOS, bootloader} to bypass, instead >> of just coming in and replacing a non-encrypted element of the bootchain >> by taking the hard disk out of its case without ever being noticed. So >> if you have no TPM, using secure boot is a definitive security >> enhancement. > The "linux" SB (ie: red hat signed grub) is only for signed grub it > doesn't sign the kernel or the initramfs, one can also mess with the > BIOS or ME which is well within the skill level of a state attacker such > as the MSS. Ugh. Red Hat signed grub is not at all the only secure boot available for linux: YOU CAN REPLACE THE KEYS IN YOUR UEFI WITH YOUR OWN. (sorry for yelling but I think I've written it one too many times, maybe this way it'll better stand out) Please check [1] if you want to know how to do it by yourself. As for signing the kernel or the initramfs, grub can also check the signature of the kernel and initramfs, see [2] also (which does exactly the same thing as secure boot except here grub is directly included in the BIOS, so there is no need for signing it) > There are also a variety of SB exploits/bypasses. Of course there always will be flaws on systems, but does it mean you shouldn't try to harden everything possible? Flaws can most often be fixed, non-existent feature cannot > Irregardless it'll be what eventually kills linux on the desktop for the > average person after the vendors stop including the linux signing key > (SB 2.0 specs don't obligate them to allow for owner control or even the > inclusion of the second key unlike SB 1.0 specs), if you desire such > features it would be much better to simply use a bios-embedded GRUB2 via > coreboot which supports kernel/initramfs signing features. Now you are just designing a future you don't like and state “that's what will happen”. Sorry if I'm no seer, but for the desktop I haven't owned yet a computer that doesn't allow one to change the keys, and thus see no reason to believe what you are saying. Also, libre/coreboot is a nice way to have a level of security equivalent to secureboot (maybe slightly better because there is one less step in the boot chain, thus one less possibility of flaw). But then coreboot is not available/working on all hardware platforms, while SB is, and the two bring equivalent security. > "Secure" Boot is a MS trojan horse. There is no argument to support this assertion. Please once again stop spreading FUD. [1] https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot [2] https://libreboot.org/docs/gnulinux/grub_hardening.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/16f4d3dd-df08-5af6-4c64-8e29f9bc94e7%40gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes support Secure Boot
On 11/23/2017 03:35 AM, taii...@gmx.com wrote: > On 11/22/2017 07:25 PM, xeph...@gmail.com wrote: >> This is quite late, but now that UEFI is supported...is secure boot? >> Wasn't quite sure what key or signature to import. > Why are all the newbies here so obsessed with a microsoft technology? > > Just shut it off, it provides no benefit to you. If their code is so > great and beneficial to you why not simply install windows 10? they say > it is safe and secure just like SB 2.0... > > [... more of the same] Can you please avoid ranting against secure boot once again? Secure boot is *not* useless. It *does* bring security benefits, although not as good as measured boot with a TPM: it requires an additional flaw somewhere in the {BIOS, bootloader} to bypass, instead of just coming in and replacing a non-encrypted element of the bootchain by taking the hard disk out of its case without ever being noticed. So if you have no TPM, using secure boot is a definitive security enhancement. That said, to answer the original question, Qubes doesn't support secure boot out of the box yet as far as I can tell. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8753bf33-356b-33e7-85e8-c4c542c92226%40gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes & Quantum decryption Immunity
On 11/12/2017 10:43 AM, Yuraeitha wrote: >> As for quantum networks, they are slightly more obtainable than, say, >> moon rockets. > > [...] > Given the fiber internet network might be able to carry these signals, it's > not farfetched to imagine we'll start to have portions of Quantum internet in > less than 10 years. It's a cheap technology too. While sure such research > costs a lot to do, the technology itself should be relatively cheap, and a > lot of the quantum computing research costs come from universities whom give > away their research fore free mostly now a days (Open Science movement, kinda > like Open Source movement). > [...] The issue with all current quantum-physics-based encryption that I know of is that it requires a direct fiber link between the source and the destination. Also, the segment length is currently about ~4-5km if I remember correctly, though it may just as well have changed since a few years ago. But this direct fiber link means quantum-physics-based encryption will never be end-to-end between you and the website you are visiting. And if this quantum-physics-based encryption is terminated by eg. your ISP (the only one you have a physical fiber link to), then your ISP could use the exact same techniques as before to spy on you. Basically, quantum-physics-based encryption is nice in that it is demonstrably secure (modulo Bell's inequalities, last time I checked on this is getting quite old, so I'm not sure about every detail). But its constraints of use are really huge, so it is not likely to ever get in your house unless you're at the head of a billion-dollar-level entity, be it a state or a company. > I've wondered for a good while if splitting up an symmetric encrypted file in > multiple of parts, say for example minimum two parts, and send one over the > internet, and carry the other on yourself in person, that if only one part is > stolen (for example someone steal your laptop with sensitive competitive > business trade secrets), then it's still uncrackable? However it's mostly > been a fun thought experiment, I never managed to confirm it, but I imagine > businesses or even government agencies would want to use such approaches if > its applicable? If it isn't already. Such a scheme is Vernam cipher. It is the only other provably secure cryptographic system that I know of (all the others are based on “we think this problem is hard, so let's prove the cryptosystem is at least as hard as this problem”). Basically to encrypt a N-bit-long message, you generate a N-bit key (with perfect randomness, which is a point where the issue usually lies), you xor it with your message, and to decrypt the message you just xor again the encrypted message with the key. You could then just send the key and the encrypted message through the two means. Funnily enough, Vernam ciphers are actually the basis for quantum-physics-based encryption. The quantum channel is only used to generate the random N-bit key in way so that it is shared by the two protagonists and no eavesdropper could get a reasonable amount of bits without being detected (in which case the transmission can be cancelled without ever using the key) Cheers & hope that helps, Leo -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/966f5e22-8a2c-6386-c2b5-ea2dcafb7eb7%40gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Is there a way to use secure boot with qubes?
On 11/09/2017 12:27 PM, blacklight wrote: > On Wednesday, 8 November 2017 20:52:14 UTC, Guerlan wrote: >> My computer complains about bad signature when I try to install qubes. Is >> there a way to install it without disabling secure boot? Does qubes support >> secure boot? Is there a way to install qubes keys on the BIOS? Why did it >> reject the keys? > > the question is more that if secureboot supports qubes, rather than the > otherway around. to be supported by secureboot, one would need to buy a very > expensive license from microsoft, something qubes is not able afford atm. This is wrong. On many computer UEFIs, you can add additional root keys. Qubes could have a Qubes key available that people can add in their UEFI settings, and sign the kernels etc. with it. As far as I know that's not yet the case though, so you'd have to do the signing yourself. A bit sad for people without TPM, but I guess the development effort is better spent elsewhere. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7da30d3a-5c30-6881-00aa-36df770591c7%40gaspard.ninja. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this
On 09/19/2017 02:23 PM, taii...@gmx.com wrote:> It is impossible to have storage communication between VM's, that would > be a separate security issue. > On timing attacks or w/e - you may be able to avoid cross communication > by putting every AppVM on a separate core of a many core CPU such as an > Opteron 6386 (16 cores) Putting every AppVM on a separate core of a many core CPU could help a bit, but CPU's usually have separate L1, maybe L2 caches, but I don't know of any CPU with a non-shared-between-cores L3 cache. So basing the attack on timing the L3 cache may still work. Then, here we're going pretty far in the sophisticated tracking strategy, like “things currently being proposed at conferences,” so maybe it's out of the threat model (or maybe not, depends on your threat model). As to browser fingerprinting, I'd personally rather use a distinct distribution for the “anonymous” part, just to make timing updates (A upgraded this day and B too and all their upgrades are always on the same day that is not the one of the release of the distribution, thus A=B) harder. Then, again it's against someone specifically targeting you, I don't think qubes is widespread enough to make trackers even try to perform such deductions (yet). That said this last sentence is just gut feeling. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a4de7982-66ce-f472-dc48-7c0421efe056%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this
On 09/18/2017 09:27 PM, jes...@gmail.com wrote: > Thank you Micah and Michał, but I am not actually asking about a standard as > strong as 100% bulletproof anonymity or anything. I really am just concerned > about whether any of the methods on that list that I linked to would be > enough to leak cookie-like reference data between two separate Qubes security > domains. Cookie-like reference data between two separate Qubes security domains cannot happen. This would mean one VM is able to influence the hard disk of another, which would be a vulnerability in Qubes. > Being tracked as I browse around *in* a given security domain is entirely my > problem of course, and I understand that. My only concern is working to > ensure that to an outside observer such as webservers and ad networks nothing > short of the shared IP address (and via Tor or VPN or different IPs honestly > allocated to different domains perhaps not even that) can act as a reliable > indicator that web browsing activity in one Qubes security domain is "linked" > to activity from another security domain via any secretly stored cookie-like > reference identifiers that get somehow leaked across domains. What can however happen is things like hardware fingerprinting through the browser, like CPU frequency measurements. Also, Qubes doesn't guarantee two VMs can't talk together, so if you have at the same time a browser in two VMs in two websites they may be able to talk together using such side channels (timing the cache, ultra-low-level stuff like that). So even though supercookies and the like aren't shared in Qubes, if you use an insufficiently anonymising web browser, a web site may be able to fingerprint your hardware through the browser (Qubes/Xen does nothing to prevent that for performance reasons), and then to link your hardware to different identities you used to browse different pages in different VMs. I don't know of any website that would try to talk to others through side-channels, but I seem to remember articles on hardware fingerprinting (esp. the cpu frequency and drift, iirc) through JS from a few years back, so I guess against state-of-the-art tracking systems Qubes will not be enough. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1720ec21-6433-8a0c-02bc-aeb17336fb8c%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On 09/08/2017 04:51 AM, taii...@gmx.com wrote: > One can use coreboot with grub's kernel signing features on an owner > controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8 > (workstation), then after coreboot is working you enable the flash write > restriction so that it can't be flashed internally (an attacker would > have to have physical access for around 10mins to reflash) - this is > technically superior to "secure boot" as it is owner controlled by you > instead of microsoft. Just a datapoint: secure boot is *not* microsoft-controlled (unless you assume the manufacturer put in some kind of backdoor, in which case you're screwed anyway). Secure boot *by default* runs with keys owned by microsoft. You can (and should) replace them with a key you own and you use to sign new GRUBs, if you want to. The option to do so is usually somewhere in the BIOS menu. Once you have removed microsoft's golden key and put your own instead, there is no longer any link between your secure boot and microsoft. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4f6892f2-e515-75f5-e93d-d77d3e5df29a%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On 08/29/2017 04:01 PM, cooloutac wrote: > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: >> Just encrypting /boot would bring little, as it would still be possible >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it >> overwrite the /boot with malicious kernel images (or even to not use the >> ones provided). >> >> The options I know of are (from IMO strongest to weakest): >> * AEM, for knowing when someone tampered with /boot >> * SecureBoot, for restricting the allowed-to-boot images (I don't know >> about its ease of use with qubes, though) >> * locking your bootloader with a password and disallow external boot >> >> I'd think having all these protections at the same time would be best, >> using secureboot mostly to avoid having to ditch the laptop after AEM >> says it's no longer trustworthy (because it may stop the attacker before >> it can even make the laptop no longer trustworthy). > > secureboot can do more then restricting boot images, it can restrict > unsigned drivers too. Thats the part Joanna doesn't like because she does > not trust who will maintain the list of signed drivers. I say I'm already > putting just as much trust into alot of other things like my banks ssl cert > when connecting to my bank account. > > We are already trusting everything coming from upstream when we update... Well it can, but the issue with secureboot I remember reading about in the AEM post [1] is that it assumes no security vulnerability in all the bootchain (which could be used to trick eg. grub to run another image than the one you expect it to), while AEM only assumes no security vulnerability in the TPM. That's why I was putting secureboot forward only as a limited way to prevent malicious modifications, in parallel with AEM, that would still be used as a more secure way of checking secureboot worked correctly. [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7f3bc3ea-d715-5630-bdd5-8eb1d1047086%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
Just encrypting /boot would bring little, as it would still be possible to modify the unencrypted part of GRUB (that decrypts /boot) to have it overwrite the /boot with malicious kernel images (or even to not use the ones provided). The options I know of are (from IMO strongest to weakest): * AEM, for knowing when someone tampered with /boot * SecureBoot, for restricting the allowed-to-boot images (I don't know about its ease of use with qubes, though) * locking your bootloader with a password and disallow external boot I'd think having all these protections at the same time would be best, using secureboot mostly to avoid having to ditch the laptop after AEM says it's no longer trustworthy (because it may stop the attacker before it can even make the laptop no longer trustworthy). On 08/28/2017 09:48 PM, Unman wrote: > On Sat, Aug 26, 2017 at 08:39:23AM -0700, > cyberian@national.shitposting.agency wrote: >> Does Qubes offer a method of securing /boot? not just against USB evil maid >> attacks, but from tampering in general? >> >> for example, while a laptop is off, what would stop a malicious user from >> live booting to an arbitrary distro and altering kernel or xen images >> located on the unencrypted /boot partition? >> >> Does qubes offer options for encrypting /boot? >> > > The Fedora installer wont allow an encrypted boot partition, but there's > nothing stopping you from encrypting /boot after installation. You will, > of course, have to reconfigure grub to decrypt the new /boot, but that's > straightforward. > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3bb3a4b8-f63d-5ccd-bdbb-7905c725901e%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: remote code execution via UDP packets (CVE-2016-10229) in the context of Qubes // and kernel update recommendations
On 04/14/2017 06:00 AM, Reg Tiangha wrote: > On 04/13/2017 09:33 PM, cooloutac wrote: >> On Thursday, April 13, 2017 at 11:26:07 PM UTC-4, cooloutac wrote: >>> So probably the kernels are not actually vulnerable, They fixed it a year >>> ago with patches, and with Qubes you assume this sort of priv escl thing >>> regardless which is why they don't even bother with sudo. >> Actually when it comes to redhat they claim the code was never there to >> exploit. But redhat might not apply to fedora kernel so I'm kind of curious >> myself now. >> > For those who are concerned, this is what is currently in the Qubes > repository for dom0: > > current: kernel-4.4.38, kernel-qubes-vm-4.4.38 > > current-testing: kernel-4.4.55, kernel-qubes-vm-4.4.55 > > > From what I can tell, the Qubes Kernel is built from the stock kernel > source, so if this bug was fixed months ago, you could probably install > either and be fine (assuming you're running R3.2). > [...] According to [1], linux <= 4.4.60 is affected. The patch was but on 4.5-rc1 branch on Dec. 15, but this doesn't mean it got backported to older kernels as it was not tagged as a security issue before (eg. debian's DSA mentioned "A regression in the UDP implementation prevented freeradius and some other applications from receiving data." as the reason for their backporting the patch, if I read correctly) Which, unless fedora's (or qubes') kernel has been using a patch for this despite it not being tagged as a security issue until now, would mean qubes' current kernels are all vulnerable. HTH, Leo [1] https://nvd.nist.gov/vuln/detail/CVE-2016-10229 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/86219df3-c3a2-bcfd-196a-5dec6b714cec%40gaspard.io. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature