is a Qubes installation instance is identifiable by Qubes team?

[Oleg Artemiev]

This is again about security and trust.

If the vendor is able to track each installation, then the vendor is
able to send custom updates.

Imagine the situation: once some person from the qubes team becomes a
hostage of some life situation, for example the local goverment or
some other force makes he/she to send a "customised" update to
exactly one qubes user.

Thus, downloading updates and sending automatic bug-reports must be
anonymous and sending trackable information must be opt-in, not
opt-out.

Compare that w/ android, windows and other software vendors - them all
want to have an unique ID for each instance of their product in update
protocol.

Due to similar reasons I've asked about the GUI option for
disabling/enabling updates in the Qubes:
some times I want to know when the system has changed, even when I
trust the source of update.

PS: I do believe that Joanna & her team are fair and good people and
I'm excited by Qubes. :)
This post is inspitated by 'anon updates' checkbox in XSpider configuration.

--
Bye.Olli.
gpg --search-keys grey_olli
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (mostly in russian): http://grey-olli.livejournal.com/tag/

[Vincent Diepeveen]

On Sat, 1 Mar 2014, Oleg Artemiev wrote:

> This is again about security and trust.
>
> If the vendor is able to track each installation, then the vendor is
> able to send custom updates.
>
> Imagine the situation: once some person from the qubes team becomes a
> hostage of some life situation, for example the local goverment or
> some other force makes he/she to send a "customised" update to
> exactly one qubes user.

Let's not keep the discussion anonymous - that would be updates shipped
to me :)

> Thus, downloading updates and sending automatic bug-reports must be
> anonymous and sending trackable information must be opt-in, not
> opt-out.

And i was thinking the important thing is to have a distro that you never
update, so that updates do not get received from the wrong source :)

It's too easy to break most securities now based upon 2048 bits RSA for
those who do effort to factorize. This is the fundamental problem of the
entire internet. The question is which risks you try to keep out with
cheapskate hardware that has so many build in hardware holes that any
selfrespecting nations NSA will manage to get in anyway.

NSA's in general will find a way to hack you - if they can't hack you they ship
entire team to you anyway. Not so long ago here when i had new firewall
running here (made out of stripped debian kernel at old hardware - my
budget very very limited of course) suddenly arab looking person armed
with gun (in this nation guns forbidden - 7 years jail) was checking out
neighbourhood. He tried to get into garden here via diagonal living
neighbours. It was a Saturday Morning. Full daylight. Their son by
accident was at parents house and sleeping there. So he
got that gun against his head. Even for soldiers this is very frightening
experience.

As a layman my question there is: How do you avoid that you receive
updates from a different source? That is in this project bigger
problem than the one you describe isn't it?

For me goal is to secure against all the Mosheiniks who want to hack you
while you browse at their homepage. It is so easy to get out of the box of
those browsers - default linux offers nearly no protection there once you
run a graphical client like KDE.

Hoping Qubes can do good job there :)

> Compare that w/ android, windows and other software vendors - them all
> want to have an unique ID for each instance of their product in update
> protocol.

> Due to similar reasons I've asked about the GUI option for
> disabling/enabling updates in the Qubes:
> some times I want to know when the system has changed, even when I
> trust the source of update.
>
> PS: I do believe that Joanna & her team are fair and good people and
> I'm excited by Qubes. :)

Then you are happy to deal with Polish as they hate the Russians.

> This post is inspitated by 'anon updates' checkbox in XSpider configuration.
>
> --
> Bye.Olli.
> gpg --search-keys grey_olli
> Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
> Blog keys (mostly in russian): http://grey-olli.livejournal.com/tag/
>

> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

[cprise]

Sounds like Hollywood-inspired paranoia. That intruder was not reacting
to your firewall, unless there is something about the incident you withheld.

Anyway... Repository packages are cryptographically signed and they
already assume that the network between publishers and the users is
hostile. Just be careful not to install unsigned packages on your systems.

[Vincent Penquerc'h]

On 01/03/14 20:53, cprise wrote:
> Anyway... Repository packages are cryptographically signed and they
> already assume that the network between publishers and the users is
> hostile. Just be careful not to install unsigned packages on your systems.

I was thinking a month ago or so about targetted update attacks.
Imagine that an attacker can have two different versions of a package
signed with the correct key. How the attacker does that is brushed off
here. Whether by coercion or by hash collisions, it does not matter
here. We assume it can be so. What if a single user is sent that
particular modified package ? It will pass all signature checks, but
will be doctored in a way nobody else will detect, because everybody
else has the right non malicious update.

The straightforward answer to that is to be able to compare
packages/updates with a consensus of your peers, to check you do have
the same versions as others. But AFAICT this is not done, and a protocol
for doing this securely/anonymously does not seem obvious. Especially
when you consider that the first person to download an update will not
find anyone in the peer list who can verify it, implying some kind of
delay between downloading an update and being able to verify it's the
same as the consensus one. Which brings a potential vulnerability
window, the length of which depends on how fast the consensus updates.

[Vincent Diepeveen]

[snip]

> Anyway... Repository packages are cryptographically signed and they already
> assume that the network between publishers and the users is hostile. Just be
> careful not to install unsigned packages on your systems.

You use an encryption scheme to sign it. Usually RSA.

Now the average company can have a pipedream and still not break RSA,
yet if we ignore all the progress made algorithmically by huge
organisations and we take a years 80 algorithm, for example Pomerances
Quadratic sieve, that is easy to put in
hardware (say ASICs), then we use some oldie factory from years ago and
print 3000 hardware ASIC's, which we put at a small cluster. Say 20 asic's
a node or so - then a small cluster can already break 2048 bits RSA and
therefore forge any signing.

This project is not so overcomplicated to carry out and relative low
cost in fact. One hardware guy and one math guy and enough budget to
produce a bunch of ASIC's. A commercial company could also carry it out if
they wanted to...

Now all that organisation (we can easily call it government organisation)
has to do, to take care you get their software is some fiddling at
internet, from where posters in this mailing group know for sure know a
lot about.

Please note we didn't take into account software progress there.
If we also take into account software progress the first question there
is: "how do we measure such progress if it gets done in secrecy?"

Well we can look at some similar fields. Say game tree search in games.
Searching deeper there is an exponential business.

If we compare the search depth they got there in 1990s versus today, then
we see that the exponent to search 1 ply deeper has been reduced by factor
2.

In short that means double the bit size is possible than already the above
hardware projection, in which case around 6000 bits is reachable now by
the same project team.

We ignore then hard facts as that factorisation has been proven to be
polynomial - so with say some terabyte of RAM and a bunch of cores maybe
it is already having a real good branching factor (much improved Theta
and therefore O)?

It's difficult to fight organisations equipped with this online. Signing
doesn't work against nations.

[Oleg Artemiev]

It looks like I've been replying to the person and skipped the list
destination. If not - sorry for duplicates.

>> This is again about security and trust.
>>
>> If the vendor is able to track each installation, then the vendor is
>> able to send custom updates.
>>
>> Imagine the situation: once some person from the qubes team becomes a
>> hostage of some life situation, for example the local goverment or
>> some other force makes he/she to send a "customised" update to
>> exactly one qubes user.
> Let's not keep the discussion anonymous - that would be updates shipped to me :)
:)

>> Thus, downloading updates and sending automatic bug-reports must be
>> anonymous and sending trackable information must be opt-in, not opt-out.
>
> And i was thinking the important thing is to have a distro that you never update, so that updates do not get received from the wrong source :)

Well, I'm planning offline Qubes for my data on the separate PC: my
home video & other personal sttuff + backups, not connected to the
network. I think that Qubes would be better than any other Linux.

> It's too easy to break most
> securities now based upon
>2048 bits RSA for those who
> do effort to factorize.
>This is the fundamental
> problem of the entire internet.

Interesting - what is your forecast for time for factoring such a key nowadays?

> The question is which risks you
> try to keep out with
> cheapskate hardware that has
> so many build in hardware
> holes that any selfrespecting
> nations NSA will manage to get
> in anyway.

Well, I'm a public person since we published our STP research in
Phrack with real names. It is not a problem to get my home address, my
photos, anything public about my life just from the net.

Anyone around having familiars working in FSS(FSB in runssian) or just
MIA(MVD in russian) or other special service (we have plenty of these,
like USA and other serious countries) can trace my calls (also google
is able to do the same, since I'm using Android on my devices, also
any malware on my phone can do this), get information about my
workplace and other pseudo-private information. Anyone working just in
any of these special services is potentially able to record my voice
while I'm talking and do other things that usually forbidden for
ordinary citizens. That is okay since I'm not criminal and do not care
much about this. Everything I do myself in real life is something that
is based on the idea, that all I say or do is recordable and is a
potentially subject of criminal prosecution.

The things I wrote above are normal for any serious country: the
special service must serve their role.

Since I'm doing everything with that idea in mind - I'm not a subject
of interest of our or foreign special services in real life.

But once I've found that I'm a public person I did a split. I keep a
virtual person for years. You may look in
http://grey-olli.livejournal.com/tag/split . And the rule is that
simple - my virtual person never talks with anyone I know in real
life. Tor, freenet, i2p and surely internet are the place to leave for
my virtual person.

Indeed, my virtual person is not a subject of any restriction as not a
subject of any restriction anything that I do think in my mind inside
of my head.

That is because I do leave as this person within the net only and the
net is the freedom keeper.

The only restriction is to be fair with myself.

In general I'm a patriot of Russia. But I'm not a supporter of out
government or our liberal opposition. In Russia (generally not only in
Russia) we all were betrayed by our politicians, when they divided our
country (I was born in USSR) and came back as oligarchs. But also we
had a period of dictate, when everyone thinking in the alternate way
was subject of prosecution. The things are changing fast and
repeatedly. Now what you talk is okay. Tomorrow everything changed and
you're the subject of persecution.

This is not something specific for Russia - entire world is built that
way - when you speak and show something that is not okay for someone
powerful - be sure you'll get a strike back.
Julian Assange is a good example. Do you remember that wiki-leaks was
subject of economical pressure by owners of credit card payment
system?
Think you're able to find an example for your own country.

Since I'm not leaving alone I'm in responsibility of my family, my
parents, my friends and other people who may have any sort of problem
due to anything what I do or say. That is the main reason to have
virtual person that is not tight to me in any visible form.

I take care about security in the way that other people will
definitely consider as insanity. Let me show two examples:

1. My wife presented me chines android phone. Currently I've no time
to reflash it with the custom android

2. Nowdays action cameras are that cheap that almost anyone is able to
buy one. I bought one from last annual bonus and now I'm recording
video of everything I see (the cam I bought is just a glass with third
eye in the middle). So once I'll have a feeling that I'm followed I'll
be able to review all the day or a week and make decision based on
facts, on something I can show a friend of mine or for my wife or
anyone else. The glass is not a subject of law enforcement since
anyone can see a third eye and understand that I may record. When
google glass will be available to buy in Russian I'll use them in the
same way as I do action camera, but also I'll root it and make it
encrypt its recordings. Funny - I think that the fact that I record is
a good thing - if ever I will become a witness of a terrorists attack
- I definitely will share the hd video for special forces (or they
will grab it from my corpse if I was that unlucky).

I am thinking about recording everything available on air (wifi/radio
IDs, other unique IDs, car numbers) and searching to find software to
automate offline statistical analysis of my recordings.

Everything I record is not a thing that I would share ever. This is my
private data and till I'm not sharing, attempts to forbid this are
attempts to forbid me remembering and thinking.

Thus, for me it is very important to keep my own data and systems I
manage as secure as possible. And this is the reason to treat
possibility to make forensic expertise of my devices as the very high
level security concern. Even when I'm not doing anything criminal.

From the other side I think that I'm that Joe who is not captured yet,
since he is not interesting enough to anyone. :)

And also there's another moment:

it is very hard to capture black cat in the black room when there's no
such a cat inside.

No one can proof my words about my virtual person and no one can disprove.

> NSA's in general will find a way to hack you - if they can't hack you they ship entire team to you anyway.

It is ineffective to send a killer/warior to everyone claiming he/she
has a virtual person. =) Spending funds on hacking everyone claiming
he/sh has a virtual is ineffective also.

> Not so long ago here when i had new firewall running here (made out of stripped debian kernel at old hardware - my budget very very limited of course) suddenly arab looking person armed with gun (in this nation guns forbidden - 7 years jail) was checking out neighbourhood. He tried to get into garden here via diagonal living neighbours. It was a Saturday Morning. Full daylight. Their son by accident was at parents house and sleeping there. So he got that gun against his head. Even for soldiers this is very frightening experience.

I know that security in real world is something that costs a lot. Most
people (guess 99%) can't afford to have a reasonable security for
their family.

In virtual world this is much cheaper and easy. A skilled technician
can make the system that is too hard to hack remotely or even having
physical access. The latter is questionable, but it is easy to make it
visible (seal labels and other methods born by banking hundred years
ago).

Well.. Qubes is very interesting in design and seem to have more
security features than any other solution available on the market.
Though it will be definitely a target for attack by governments since
people concerned by security usually have something interesting data
on their systems.

Thus it is really important to make attacks initiated by someone that
powerful to make someone inside the development team a hostage to be
harder to implement. Making updates and bug-reports anonymous is the
best thing we can do for this. I mean making it harder in terms of
implementing it closer to specific target. If the attack has to cover
entire distribution, that chances that someone will find evidence of
it and make it public are raising.

> As a layman my question there is: How do you avoid that you receive updates from a different source? That is in this project bigger problem than the one you describe isn't it?

This is not only a bigger problem - this is also just another problem.
I'm talking about the need to attack the entire community if a Qubes
installation instance is not something that is trackable from the
vendor distribution. Such a wider attack has more chances to be found
and evidence of it published.

> For me goal is to secure against all the Mosheiniks who want to hack you while you browse at their homepage. It is so easy to get out of the box of those browsers - default linux offers nearly no protection there once you run a graphical client like KDE.Hoping Qubes can do good job there :)

Yes, Qubes does protect you if you're following the usage best practices.

>> Compare that w/ android, windows and other software vendors - them all
>> want to have an unique ID for each instance of their product in update
>> protocol.
>> Due to similar reasons I've asked about the GUI option for
>> disabling/enabling updates in the Qubes:
>> some times I want to know when the system has changed, even when I
>> trust the source of update.

[..]


This post is inspired by 'anon updates' check-box in XSpider security
scaner configuration.


Anonymity in updates and bug-reports is very important. This is not
only important for clients, this is also important for a dev team,
since this lower reasons that someone powerful enough will try to make
them do something bad.

[David Schissler]

 Perhaps updates should eventually be pushed to a big torrent-like system with pieces distributed all over the place.  Then set it up so that pieces need to be grabbed from several different predetermined IP addresses plus some peers.  Work out all kinds of special magic in there to just make it much more difficult.  Also if the little pieces were all hashed it seems to me that it would make it dramatically more difficult to make the entire thing pass public key math.  Perhaps have the several hard code main IP addresses sign some connection stuff so it would have to match as well.  Then it seems to me that the only way to break all of that would to have a trivial exploit for the RSA algorithm.

[Vincent Diepeveen]

On Sun, 2 Mar 2014, Oleg Artemiev wrote:

> It looks like I've been replying to the person and skipped the list
> destination. If not - sorry for duplicates.
>
>>> This is again about security and trust.

I'm not big expert security related - only endure what happens.

Yet i read most of what you wrote careful and i had impression i was
reading 'we from coca cola in Moscow advice KremlinCoke'

If you make things anonymous there is no way to check that Moscow ships
updates to a guy they target. So if there is bugreport about some module,
you cannot verify that in fact it was a hack - as you don't know whether
the person received update from you or from Moscow.

If you do things not anonymous it's far easier to detect hacks.

With a background in development - majority of reports you have to figure
out yourself the problem as a developer - it is very helpful then to know
whether the problem actually was created by one of your own updates or a
hacked one that you never saw and was shipped by some IP fiddling.

[Alex Dubois]

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-users.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-users.
For more options, visit https://groups.google.com/groups/opt_out.

FYI In Firefox, there is a plug-in that provide web sites certificates peer group reviews. Developed by moxie marlinspike if I remember.

[Alex Dubois]

found it... http://convergence.io/

not sure if corrum can easily be corrupted (a government register 2000 Qubes workstations for example...).

[Oleg Artemiev]

On Mon, Mar 3, 2014 at 6:43 PM, Vincent Diepeveen <di...@xs4all.nl> wrote:
>
>
> On Sun, 2 Mar 2014, Oleg Artemiev wrote:
>
>>>> This is again about security and trust.
>
> I'm not big expert security related - only endure what happens.

[]

> If you make things anonymous there is no way to check that Moscow ships
> updates to a guy they target. So if there is bugreport about some module,

Targeted updates are evil. Period. Targeted updates are ok if you trust vendor entirely.
Yes, when we're talking in terms of commercial support - updates must be targeted.
So let that be opt-in. Or at least opt-out if opt-in cannot be easily made saving time
of developers and business clients.

> you cannot verify that in fact it was a hack - as you don't know whether
> the person received update from you or from Moscow.

The problem of getting updates via network is not the developer problem.
Signing using multiple hash (3+)algo (md5 + sha512 + AnyOtherHashDevTeamLike) will solve
problem of attacking just one algo to get collision.

> If you do things not anonymous it's far easier to detect hacks.

But it allows developers send personally targeted attack. And this is very funny - Qubes users
have all information targeted - work VM will have all your work secrets and so on. No need to search.

Do you get kernel updates from Linus directly? No.

> With a background in development - majority of reports you have to figure
> out yourself the problem as a developer - it is very helpful then to know
> whether the problem actually was created by one of your own updates or a
> hacked one that you never saw and was shipped by some IP fiddling.

Security always cost you something. You may ask user to install a copy of qubes with targeted updates enabled.

[..]

>> This is not something specific for Russia - entire world is built that
>> way - when you speak and show something that is not okay for someone
>> powerful - be sure you'll get a strike back.
>> Julian Assange is a good example. Do you remember that wiki-leaks was
>> subject of economical pressure by owners of credit card payment
>> system?
>> Think you're able to find an example for your own country.
>>

[..]

>> I take care about security in the way that other people will
>> definitely consider as insanity. Let me show two examples:
>>
>> 1. My wife presented me chines android phone. Currently I've no time
>> to reflash it with the custom android

Here I just wanted to tell that I just made another one virtual person for it. :) Too big text - I forgot to return here. %)

>> Well.. Qubes is very interesting in design and seem to have more
>> security features than any other solution available on the market.
>> Though it will be definitely a target for attack by governments since
>> people concerned by security usually have something interesting data
>> on their systems.

[..]

>>> As a layman my question there is: How do you avoid that you receive
>>> updates from a different source? That is in this project bigger problem than
>>> the one you describe isn't it?
>> This is not only a bigger problem - this is also just another problem.

My proposal: Use 3 hashes using diferent algorithm. Use 3 keys sequentially. Distribute keys fingerprints via diffrent channels at the same time: web, keyservers, torrents.

>> I'm talking about the need to attack the entire community if a Qubes
>> installation instance is not something that is trackable from the
>> vendor distribution. Such a wider attack has more chances to be found
>> and evidence of it published.

[..]

[Vincent Diepeveen]

Yeah but before all those security discussions which are easy to post
things about:

In meantime, yum doesn't manage to update here.
I figured out firefox problem is missing flash.
tried yum with:

sudo qubes-dom0-update flashplugin-installer

However it's obvious it doesn't get through firewall.
In firewallvm under applications i do not see 'yum'
tried turn on 'software install' and 'software update'
yet all didn't help much.

Any ideas how to get yum added to the firewallvm?

Somehow it doesn't allow me to just type a name and add it?

Thanks for answerring the in between question trying to get qubes to work
here :)

Vincent

[Alex Dubois]

Alex

Same problem

[Marek Marczykowski-Górecki]

On 04.03.2014 00:35, Vincent Diepeveen wrote:
> Yeah but before all those security discussions which are easy to post things
> about:
>
> In meantime, yum doesn't manage to update here.
> I figured out firefox problem is missing flash.
> tried yum with:
>
> sudo qubes-dom0-update flashplugin-installer

Why the hell you are trying to install flash plugin *in dom0*?!

But if you want to install/update it in VM, you can simply type:
sudo yum install flash-plugin
*in the template VM*
Note that flash plugin is already installed in default template...

The problem you are referring I guess is related to some problem of
linuxdownload.adobe.com server - I see some timeouts there recently.

> However it's obvious it doesn't get through firewall.
> In firewallvm under applications i do not see 'yum'
> tried turn on 'software install' and 'software update'
> yet all didn't help much.
>
> Any ideas how to get yum added to the firewallvm?

I really don't understand what do you mean by "yum added to the firewallvm".

> Somehow it doesn't allow me to just type a name and add it?
>
> Thanks for answerring the in between question trying to get qubes to work here :)
>
> Vincent
>

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Vincent Diepeveen]

On Tue, 4 Mar 2014, Marek Marczykowski-Górecki wrote:

> On 04.03.2014 00:35, Vincent Diepeveen wrote:
>> Yeah but before all those security discussions which are easy to post things
>> about:
>>
>> In meantime, yum doesn't manage to update here.
>> I figured out firefox problem is missing flash.
>> tried yum with:
>>
>> sudo qubes-dom0-update flashplugin-installer
>
> Why the hell you are trying to install flash plugin *in dom0*?!

When i googled qubes and updating software i found this homepage:

http://wiki.qubes-os.org/trac/wiki/SoftwareUpdateDom0

That was bad idea obviously :)

>
> But if you want to install/update it in VM, you can simply type:
> sudo yum install flash-plugin
> *in the template VM*

Assume you mean the untrusted VM?

I tried it there and i got output:

[user@untrusted ~]$ sudo yum install flash-plugin
Loaded plugins: langpacks, post-transaction-actions, presto,
refresh-packagekit, yum-qubes-
: hooks
adobe-linux-x86_64 | 951
B 00:00:00
fedora/18/x86_64/metalink | 32
kB 00:00:00
http://yum.qubes-os.org/r2-beta3/current/vm/fc18/repodata/repomd.xml:
[Errno 12] Timeout on
http://yum.qubes-os.org/r2-beta3/current/vm/fc18/repodata/repomd.xml: (28,
'Operation too slow. Less than 1000 bytes/sec transferred the last 30
seconds')
Trying other mirror.
updates/18/x86_64/metalink | 29
kB 00:00:00
adobe-linux-x86_64/primary FAILED
http://linuxdownload.adobe.com/linux/x86_64/repodata/primary.xml.gz:
[Errno 12] Timeout on
http://linuxdownload.adobe.com/linux/x86_64/repodata/primary.xml.gz: (28,
'Operation too slow. Less than 1000 bytes/sec transferred the last 30
seconds')
Trying other mirror.
Package flash-plugin-11.2.202.327-release.x86_64 already installed and
latest version
Nothing to do
[user@untrusted ~]$

However if i start firefox then still flash is not working and websites
show empty page (the ones not using flash seemingly excepted).

In its config file:

plugins.notifyMissingFlash ; true

How do i fix my problem?

> Note that flash plugin is already installed in default template...

> The problem you are referring I guess is related to some problem of
> linuxdownload.adobe.com server - I see some timeouts there recently.

I am not sure, the flash of firefox doesn't work.
How do i fix it if it says it is already on the system by yum?

I will try to locate the file and manually copy to somewhere - not sure
where - hints greatly appreciated!

>> However it's obvious it doesn't get through firewall.
>> In firewallvm under applications i do not see 'yum'
>> tried turn on 'software install' and 'software update'
>> yet all didn't help much.
>>
>> Any ideas how to get yum added to the firewallvm?
>
> I really don't understand what do you mean by "yum added to the firewallvm".

As in the dom0 it said it was running yum from the firewallvm,
i looked in the tab "applications" of firewallvm trying to put
yum from left side to right side, which worked to get the firedfox a
little to alive.

I realize now - bad idea try in the dom0 this.

Thanks for answerring!
Vincent

[Alex Dubois]

Alex

I will open other thread and give this one back to Olev as my problem is different.

The multi channel distribution is a good point.

>>
>> --
>> Best Regards,
>> Marek Marczykowski-Górecki
>> Invisible Things Lab
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>

[Oleg Artemiev]

On Sun, Mar 2, 2014 at 1:12 AM, Vincent Penquerc'h
<vin...@collabora.co.uk> wrote:
> On 01/03/14 20:53, cprise wrote:
>> Anyway... Repository packages are cryptographically signed and they
>> already assume that the network between publishers and the users is
>> hostile. Just be careful not to install unsigned packages on your systems.
>
> I was thinking a month ago or so about targetted update attacks.
> Imagine that an attacker can have two different versions of a package
> signed with the correct key. How the attacker does that is brushed off
> here. Whether by coercion or by hash collisions, it does not matter
> here. We assume it can be so. What if a single user is sent that
> particular modified package ? It will pass all signature checks, but
> will be doctored in a way nobody else will detect, because everybody
> else has the right non malicious update.
>
> The straightforward answer to that is to be able to compare
> packages/updates with a consensus of your peers, to check you do have
> the same versions as others. But AFAICT this is not done,

Are there any ready to go solutions for such an exchange?

BTW, this will give us ability to DoS installation of packages (if it
will depend
to fact that all have same hashes) if there's no correct way to
set a list of users who you want to share with. What if one will advertise wrong
checksumm?

> and a protocol
> for doing this securely/anonymously does not seem obvious. Especially
> when you consider that the first person to download an update will not
> find anyone in the peer list who can verify it, implying some kind of
> delay between downloading an update and being able to verify it's the
> same as the consensus one. Which brings a potential vulnerability
> window, the length of which depends on how fast the consensus updates.

agree.

But are there ready to go solutions? I don't think that Qubes team has time
to develop this.

[Oleg Artemiev]

On Sun, Mar 2, 2014 at 1:33 AM, Vincent Diepeveen <di...@xs4all.nl> wrote:
> [snip]
>
>> Anyway... Repository packages are cryptographically signed and they
>> already assume that the network between publishers and the users is hostile.
>> Just be careful not to install unsigned packages on your systems.
> You use an encryption scheme to sign it. Usually RSA.
> Now the average company can have a pipedream and still not break RSA,
> yet if we ignore all the progress made algorithmically by huge organisations
> and we take a years 80 algorithm, for example Pomerances Quadratic sieve,
> that is easy to put in hardware (say ASICs), then we use some oldie factory
> from years ago and print 3000 hardware ASIC's, which we put at a small
> cluster. Say 20 asic's a node or so - then a small cluster can already break
> 2048 bits RSA and therefore forge any signing.

[..]
How long time this may take from your forecast? Years? Months?

[..]

> In short that means double the bit size is possible than already the above
> hardware projection, in which case around 6000 bits is reachable now by the
> same project team.

Sorry, I didn't get an order of time values for this attack.

[..]

> It's difficult to fight organisations equipped with this online. Signing
> doesn't work against nations.

So why not to use multiple signing? Say 3 signs by different keys and
3 different hashing algorithms.
I gues this will work. And also I think that key rotation is important
then. And if attack works longer
than release lifetime (assuming each release we change keys) then it's
almost useless to attack.

Should we point developers attention to this recipe?

[cprise]

It sounds more practical to increase the key length while a replacement
public key algorithm is implemented. This key length calculator may be
of interest:
http://www.keylength.com/en/compare/

BTW, Fedora and Debian appear to have moved up to 4096bit keys.

Bruce Schneier recently stated that crypto based on discrete logarithms
should still be secure. One of those algorithms is ElGamal which is used
by the I2P networking layer; DSA is related and used for signing (though
to be secure it supposedly it needs to be used with sha2 instead of sha1).

[Zrubecz Laszlo]

On 1 March 2014 02:05, Oleg Artemiev <grey...@gmail.com> wrote:

> Due to similar reasons I've asked about the GUI option for
> disabling/enabling updates in the Qubes:
> some times I want to know when the system has changed, even when I
> trust the source of update.

This should be a n option for several other reason as well.

I'm working on a place where I can't reach the internet without using a proxy.
Now the automatic update checkings makes a lot of noise by triggering
'not allowed trafic' alerts.
And it is really bad thing.

Even if I set the correct proxy I realy do not want to 'announce' that
I'm using Qubes.

So yes, the update checks should be configurable.



** Actually one can disable the automatic updates as it is scheduled by cron.



--
Zrubi

[Vincent Diepeveen]

On Wed, 5 Mar 2014, cprise wrote:

>
> On 03/05/14 13:44, Oleg Artemiev wrote:
>> On Sun, Mar 2, 2014 at 1:33 AM, Vincent Diepeveen <di...@xs4all.nl> wrote:
>>> [snip]
>>>
>>>> Anyway... Repository packages are cryptographically signed and they
>>>> already assume that the network between publishers and the users is
>>>> hostile.
>>>> Just be careful not to install unsigned packages on your systems.
>>> You use an encryption scheme to sign it. Usually RSA.
>>> Now the average company can have a pipedream and still not break RSA,
>>> yet if we ignore all the progress made algorithmically by huge
>>> organisations
>>> and we take a years 80 algorithm, for example Pomerances Quadratic sieve,
>>> that is easy to put in hardware (say ASICs), then we use some oldie
>>> factory
>>> from years ago and print 3000 hardware ASIC's, which we put at a small
>>> cluster. Say 20 asic's a node or so - then a small cluster can already
>>> break
>>> 2048 bits RSA and therefore forge any signing.
>> [..]
>> How long time this may take from your forecast? Years? Months?

Well knowing majority of RSA keys has been generated with weak RNG's,
in fact around 5% of all RSA keys factorizes by just taking each others
GCD's, which you can do on an iphone obviously.

Then time doesn't matter. The more interesting question algorithmically
would be :"is this specific algorithm a good idea to use to factorize
nowadays".

Realize it's a brute force (full width) algorithm. Not a sophisticated
guessing approximation algorithm in short.

That's not the point of my writing. My point is if you write down the
order that is needed to factorize 2048 bits, that nowadays an
organisation, say located in Zimbabwe, without too bright types walking
around, and a reasonable budget of just a few million, needed to produce
the processors and buy a nice Mellanox network for a bunch of cluster
nodes - that THEORETICALLY you can factor the handful of keys on this
planet you're interested in, in factoring.

As the rest you already stole online.

An exact theta is not interesting, as the above scenario assumes that
there was zero progress in algorithms past decades, which is just not
realistic.

In mid 90s i kept an interview amongst a bunch of professors and
programmers asking their prediction for the 21th century for
computerchess.

A similar field like factorization - namely busy with approximation
algorithms.

A few points on what i noticed there:

a) all professors guessed the technology dead wrong. 100% of them.
Their expertise was so far away from current technology and algorithms,
that any of their guess was total outdated

b) a big bunch of researchers/top programmers and professors was not
capable of analytical questions; far majority, especially professors,
had the tendency to assume that what they coudl not solve themselves
during their generation, that some years later no one else would manage to
progress there

c) Interestingly socially some guesses were pretty accurate

d) technological EVERYONE completely UNDERESTIMATED PROGRESS. Far
majority was NOT capable of extrapolating hardware into the future.

Even using Moore type logics only a very small handful managed to use in
their logics.

e) 100% of all professors was not capable of extrapolating into the
future. Only a few top programmers close to the current reality managed.

f) the PHD researchers, funded by government, were even further off than
the above professors. My assumption later on was that this was because
they were YOUNGER than the above professsors - still lacking knowledge.

g) In later discussions online about the same subject in
rec.games.chess.computer there by far the most optimistic guess was mine.

Though behind screens some privately supported my opinion there, some of
the top programmers - not a single poster online agreed with that "far too
optimistic guess"

h) one of the professors (Robert Morgan) Hyatt brought as argument to the
scene that there was hard mathematical proof on the optimal size of a
search tree, which is O ( sqrt ( S ) ). Though i never looked it up, Knuth
wrote somethign about it.

Argument H gets used a lot in cryptography. The problem is that the
argument doesn't hold once you go APPROXIMATE things OR use a different
algorithm OR combine a 100 algorithms with each other.

My guess was that with so many nodes per second like Deep Blue got - the
claim back then was 200 million per second (some years later that claim
would get weakened them admitting they had huge problems and were in fact
under 5% efficient at the 133 million positions per second) - you could
reach a huge search depth. Easily 18-20 ply, whereas deep blue on average
got 12 ply. Back then in 1997 that was a HUGE search depth.

Today the top programs at modern processors get around 10-20 million nodes
per second and easily search 30 ply, using tricky approximation
algorithms with all sorts of methods to improve efficiency of those
algorithms.

Everyone totally underestimated the progress of the software algorithms.
100% of everyone. No exceptions.

Now as for factoring this would mean that "normal progress" by now would
factor *at least* 6000 bits.

Yet in meantime there is a hard proof that factorisation is a polynomial
algorithm.

Also proving a prime is practical faster than O ( n ^ 10 ).
In fact practical O ( n ^ 6 ) roughly with more optimisations that might
come.

That proving hardly uses RAM.

I don't see any reason to believe why such an algorithm (one using
very little RAM) doesn't exist to factorize
composites - be it that such algorithm is a lot harder to figure out.

My public statement from the start this century: if proving primes is O (
n ^ 10 ) then obviously factorizing it won't be taking much longer.

Also another big point in factorisation is the arrogance of some
government departments. They just cannot imagine that someone in a 3d
world nation will be capable of finding a brilliant algorithm.

Well that algorithm that a prime can be proven,
is O ( n ^ 10 ), and it was found in India.

>> [..]
>>> In short that means double the bit size is possible than already the above
>>> hardware projection, in which case around 6000 bits is reachable now by
>>> the
>>> same project team.
>> Sorry, I didn't get an order of time values for this attack.
>>
>> [..]
>>> It's difficult to fight organisations equipped with this online. Signing
>>> doesn't work against nations.
>> So why not to use multiple signing? Say 3 signs by different keys and
>> 3 different hashing algorithms.
>> I gues this will work. And also I think that key rotation is important
>> then. And if attack works longer
>> than release lifetime (assuming each release we change keys) then it's
>> almost useless to attack.
>>
>> Should we point developers attention to this recipe?
>
> It sounds more practical to increase the key length while a replacement
> public key algorithm is implemented. This key length calculator may be of
> interest:
> http://www.keylength.com/en/compare/
>
> BTW, Fedora and Debian appear to have moved up to 4096bit keys.

Which is fine for Fedora and Debian.

The sort of security you are looking for you want 8192 bits
AND A GOOD RNG. And component tests that after a user generated a key,
that those component tests go try to factor it and take the GCD's
with other public keys.

> Bruce Schneier recently stated that crypto based on discrete logarithms
> should still be secure. One of those algorithms is ElGamal which is used by
> the I2P networking layer; DSA is related and used for signing (though to be
> secure it supposedly it needs to be used with sha2 instead of sha1).

Bruce was asked the wrong question.
Does he favour discrete algorithms above RSA?

Bruce is a genius guy in analyzing the current situation - yet his own
computer online he's probably looking for
a different sort of security than most members of this list.

He'll state 2048 bits is fine for RSA, i'm sure of it.

Any security related crypto problem you can rewrite to a factorisation
problem or use similar approximation algorithms for, with only the
mathematical algorithms at the end being different.

RSA is the only algorithm that gets recognized as the algorithm that
already has survived pre-internet attacks. There is good reasons why also
JAVA relies upon 2048 bits RSA for its safety and security.

I wouldn't use anything else except RSA to be honest.

Finding that polynomial algorithm to factor anything is going to be a much
bigger challenge than approximating a few discrete logarithms.

There are thousands of professionals trying to factor and just a few who
keep themselves busy with discrete logarithms - that should be self
explaining.

If you do much effort for maximum security one shouldn't cryptographically
shield itself with the utmost miminum protection from succesful
factorisation attacks from Zimbabwe.

You build a huge bunker for your gold storage, guard the frontdoor with
1 guard, yet the guard is sitting with his back directly behind the
frontdoor which is made out of 5.1 CM of pot metal, because
the security expert, just released from prison,
tells you that a kalashnikov bullet cannot PENETRATE more than 5 CM of steel.

Vincent

[Marek Marczykowski-Górecki]

http://wiki.qubes-os.org/trac/ticket/800

[Oleg Artemiev]

[]

Qubes key reported by gpg is 4096 bits long.

> Which is fine for Fedora and Debian.

I do not understand why people restrict the length. If 8K or 16K length would be
available - definitely some peoople will consider to use that.
Currently I've no
option to use overkill keys. But why?

Sorry, I'm not yet that deep into cryptography (even after reading
Applied Crypto by Bruce).
Did I get your idea right that signing by a few 4096 bit RSA keys wouldn't help?