Armory - Discussion Thread

[randomguy7]

I'd recommend to encrypt the swap (maybe with a passphrase instead of a random one time password, I don't trust the entropy pool while booting up). No swap at all might get nasty if you hit your ram constraints.

[1714024690]

1714024690

[1714024690]

1714024690

[1714024690]

1714024690

[etotheipi]

I'd recommend to encrypt the swap (maybe with a passphrase instead of a random one time password, I don't trust the entropy pool while booting up). No swap at all might get nasty if you hit your ram constraints.

Well the most sensitive keys will be kept on an offline computer which presumably runs nothing else except offline Armory.  There's not really a way to run through your RAM there.  Plus, I'd rather run out of swap than have the keys accidentally hit the hard drive unencrypted without warning.  But yes, it is possible to have encrypted swap, though I don't think you can use hibernate if you do that, so you'd be disabling hibernate which is 80% the reason you wanted encrypted swap to begin with.

[SebastianJu]

I'd recommend to encrypt the swap (maybe with a passphrase instead of a random one time password, I don't trust the entropy pool while booting up). No swap at all might get nasty if you hit your ram constraints.

Well the most sensitive keys will be kept on an offline computer which presumably runs nothing else except offline Armory.  There's not really a way to run through your RAM there.  Plus, I'd rather run out of swap than have the keys accidentally hit the hard drive unencrypted without warning.  But yes, it is possible to have encrypted swap, though I don't think you can use hibernate if you do that, so you'd be disabling hibernate which is 80% the reason you wanted encrypted swap to begin with.

Encrypt the whole OS with Truecrypt and you dont have to bother anymore... though TC is somewhat in a strange state... now that the devs dont want to work on it anymore.

[etotheipi]

I'd recommend to encrypt the swap (maybe with a passphrase instead of a random one time password, I don't trust the entropy pool while booting up). No swap at all might get nasty if you hit your ram constraints.

Well the most sensitive keys will be kept on an offline computer which presumably runs nothing else except offline Armory.  There's not really a way to run through your RAM there.  Plus, I'd rather run out of swap than have the keys accidentally hit the hard drive unencrypted without warning.  But yes, it is possible to have encrypted swap, though I don't think you can use hibernate if you do that, so you'd be disabling hibernate which is 80% the reason you wanted encrypted swap to begin with.

Encrypt the whole OS with Truecrypt and you dont have to bother anymore... though TC is somewhat in a strange state... now that the devs dont want to work on it anymore.

As far as I know, TrueCrypt doesn't do encrypted swap.  It makes sure that nothing touches your primary (storage) partitions unencrypted, but if you hibernate with key material in RAM, it will still end up on disk unencrypted.   I recommend both disabling swap (and hibernate), and use full-disk encryption.  TrueCrypt works for the disk encryption part, though most recent versions of Ubuntu have had home-partition encryption in the OS-install wizard for a while

[acegilz]

any chance to issue bulk send to multiple addresses using armory with GUI ?

[Corelianer]

One thing that I noticed is that the Details in the Binaries are missing under Windows.
For most people, (including me) an executable looks suspicious if these Details are missing.

[bitpop]

One thing that I noticed is that the Details in the Binaries are missing under Windows.
For most people, (including me) an executable looks suspicious if these Details are missing.

That's probably the most useless "security" detail you can think to look at

[Corelianer]

Really? So lets assume you have an up-to date antivirus system/ malware detector like most people do and then you look in the task-manager seeing running processes that you have no idea what they might do. The first thing is to check if they are from a known vendor. Then you might google the file to see what other people say.

If you had ever a Virus infected computer, then you know what I mean.

Right now the guardian.exe looks suspicious because I have no idea if its legit or not.

Most viruses don't pay attention to this stuff and thats where you can identify them easily.

[K1773R]

Really? So lets assume you have an up-to date antivirus system/ malware detector like most people do and then you look in the task-manager seeing running processes that you have no idea what they might do. The first thing is to check if they are from a known vendor. Then you might google the file to see what other people say.

If you had ever a Virus infected computer, then you know what I mean.

Right now the guardian.exe looks suspicious because I have no idea if its legit or not.

Most viruses don't pay attention to this stuff and thats where you can identify them easily.

This is false security.

[bitpop]

Really? So lets assume you have an up-to date antivirus system/ malware detector like most people do and then you look in the task-manager seeing running processes that you have no idea what they might do. The first thing is to check if they are from a known vendor. Then you might google the file to see what other people say.

If you had ever a Virus infected computer, then you know what I mean.

Right now the guardian.exe looks suspicious because I have no idea if its legit or not.

Most viruses don't pay attention to this stuff and thats where you can identify them easily.

You can edit it yourself

http://www.heaventools.com/resource-tuner.htm

[SebastianJu]

I'd recommend to encrypt the swap (maybe with a passphrase instead of a random one time password, I don't trust the entropy pool while booting up). No swap at all might get nasty if you hit your ram constraints.

Well the most sensitive keys will be kept on an offline computer which presumably runs nothing else except offline Armory.  There's not really a way to run through your RAM there.  Plus, I'd rather run out of swap than have the keys accidentally hit the hard drive unencrypted without warning.  But yes, it is possible to have encrypted swap, though I don't think you can use hibernate if you do that, so you'd be disabling hibernate which is 80% the reason you wanted encrypted swap to begin with.

Encrypt the whole OS with Truecrypt and you dont have to bother anymore... though TC is somewhat in a strange state... now that the devs dont want to work on it anymore.

As far as I know, TrueCrypt doesn't do encrypted swap.  It makes sure that nothing touches your primary (storage) partitions unencrypted, but if you hibernate with key material in RAM, it will still end up on disk unencrypted.   I recommend both disabling swap (and hibernate), and use full-disk encryption.  TrueCrypt works for the disk encryption part, though most recent versions of Ubuntu have had home-partition encryption in the OS-install wizard for a while

If TC encrypted an OS then everything is encrypted, including the swap-file. You only can get back into the hibernated session if you insert the password first since the swapfile is only a file on the OS-Partition. And the whole OS-Partition is encrypted.

[Rampion]

I have an old Armory wallet on an offline computer - if I upgrade my offline installation with the latest Armory version (0.9.2), will I be able to do an n-of-m paper backup or should I create a new wallet with the newest Armory and transfer my funds there to be able to print such a backup?

[etotheipi]

I have an old Armory wallet on an offline computer - if I upgrade my offline installation with the latest Armory version (0.9.2), will I be able to do an n-of-m paper backup or should I create a new wallet with the newest Armory and transfer my funds there to be able to print such a backup?

The new backup system is backwards compatible.  It has no problem doing fragmented backups of old wallets, though they will be four-line backups instead of the new two-line backups.  This is because the older versions of Armory (before fragmented backups were implemented) independently generated the root key and chaincode from secure-random data and thus both needed to be backed up.  This was unnecessary since there is already more than enough entropy in the 256-bit key, so we switched to computing it from the root key itself.  Thus, if you have the root key, the chaincode can be computed and doesn't need to be backed up.   

Just make sure you use the backup tester and/or actually remove the wallet and restore it.   It will give you the option to test your backup after you are done creating it.

[Corelianer]

@bibop

I opened ArmoryQt.exe but it failes to change any of those details. (Reffering this youtube video: https://www.youtube.com/watch?v=tPcrSpYqH0k )
I also tried to open the other executables (guardian.exe and w9xpopen.exe).



The only one that seem to work is the uninstall.exe



I still stick with my opinion that it's an indicator for a virus if the details are missing.

[flipperfish]

One thing that I noticed is that the Details in the Binaries are missing under Windows.
For most people, (including me) an executable looks suspicious if these Details are missing.

[pictures]

The metadata on the details-tab alone is indeed pretty useless. However, there is the possibility to have executables signed with Microsoft's Authenticode [1], which is Microsoft's way of code signing. It's more or less the same as the GPG-Signatures the Armory Devs already provide, however it's far more easy to check on windows, as the functionality for this is already included in the OS and the NT-Kernel. Even more, these signatures can be used to instruct the OS to only allow execution of signed (even constrained by the signer) executables.

AFAIK Authenticode also protects the metadata in the executable, so the information in the details-tab becomes more reliable.

I would really like to have all Armory Windows executables also to be signed with Authenticode besides GPG.


[1] http://msdn.microsoft.com/en-us/library/ie/ms537359%28v=vs.85%29.aspx
     http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx

[bitpop]

One thing that I noticed is that the Details in the Binaries are missing under Windows.
For most people, (including me) an executable looks suspicious if these Details are missing.

[pictures]

The metadata on the details-tab alone is indeed pretty useless. However, there is the possibility to have executables signed with Microsoft's Authenticode [1], which is Microsoft's way of code signing. It's more or less the same as the GPG-Signatures the Armory Devs already provide, however it's far more easy to check on windows, as the functionality for this is already included in the OS and the NT-Kernel. Even more, these signatures can be used to instruct the OS to only allow execution of signed (even constrained by the signer) executables.

AFAIK Authenticode also protects the metadata in the executable, so the information in the details-tab becomes more reliable.

I would really like to have all Armory Windows executables also to be signed with Authenticode besides GPG.


[1] http://msdn.microsoft.com/en-us/library/ie/ms537359%28v=vs.85%29.aspx
     http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx

You mean pay microsoft to sign it for you which can be social engineered? In addition to the private signing key owned by the nsa?

[flipperfish]

One thing that I noticed is that the Details in the Binaries are missing under Windows.
For most people, (including me) an executable looks suspicious if these Details are missing.

[pictures]

The metadata on the details-tab alone is indeed pretty useless. However, there is the possibility to have executables signed with Microsoft's Authenticode [1], which is Microsoft's way of code signing. It's more or less the same as the GPG-Signatures the Armory Devs already provide, however it's far more easy to check on windows, as the functionality for this is already included in the OS and the NT-Kernel. Even more, these signatures can be used to instruct the OS to only allow execution of signed (even constrained by the signer) executables.

AFAIK Authenticode also protects the metadata in the executable, so the information in the details-tab becomes more reliable.

I would really like to have all Armory Windows executables also to be signed with Authenticode besides GPG.


[1] http://msdn.microsoft.com/en-us/library/ie/ms537359%28v=vs.85%29.aspx
     http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx

You mean pay microsoft to sign it for you which can be social engineered? In addition to the private signing key owned by the nsa?

No. I mean getting a Authenticode Certificate from a well known CA (eg. [2]) and use it to sign the executables. Microsoft does only provide the root keys, which are trusted by default (Microsoft also makes the OS, this whole procedure is used on, so the users, who do use Armory on Windows, do trust Microsoft anyways.) The private key for the code signing certificate can be stored in the same way as Armory's GPG key, so it's not owned by the NSA. (And actually, it's not the NSA I fear in this use case, but regular hackers.) Social Engineering is a concern only, if you don't check the metadata in the executable.

[2] https://www.thawte.com/code-signing/content-signing-certificates/microsoft-authenticode/index.html

[K1773R]

One thing that I noticed is that the Details in the Binaries are missing under Windows.
For most people, (including me) an executable looks suspicious if these Details are missing.

[pictures]

The metadata on the details-tab alone is indeed pretty useless. However, there is the possibility to have executables signed with Microsoft's Authenticode [1], which is Microsoft's way of code signing. It's more or less the same as the GPG-Signatures the Armory Devs already provide, however it's far more easy to check on windows, as the functionality for this is already included in the OS and the NT-Kernel. Even more, these signatures can be used to instruct the OS to only allow execution of signed (even constrained by the signer) executables.

AFAIK Authenticode also protects the metadata in the executable, so the information in the details-tab becomes more reliable.

I would really like to have all Armory Windows executables also to be signed with Authenticode besides GPG.


[1] http://msdn.microsoft.com/en-us/library/ie/ms537359%28v=vs.85%29.aspx
     http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx

You mean pay microsoft to sign it for you which can be social engineered? In addition to the private signing key owned by the nsa?

No. I mean getting a Authenticode Certificate from a well known CA (eg. [2]) and use it to sign the executables. Microsoft does only provide the root keys, which are trusted by default (Microsoft also makes the OS, this whole procedure is used on, so the users, who do use Armory on Windows, do trust Microsoft anyways.) The private key for the code signing certificate can be stored in the same way as Armory's GPG key, so it's not owned by the NSA. (And actually, it's not the NSA I fear in this use case, but regular hackers.) Social Engineering is a concern only, if you don't check the metadata in the executable.

[2] https://www.thawte.com/code-signing/content-signing-certificates/microsoft-authenticode/index.html

If you use CA and not M$ Certs, its even more horrible and has more attack vectors.

[Corelianer]

The Bitcoin Foundation bought their Code-Signing Certificate from here: http://www.instantssl.com/
169€ for 2 years.

You could also concider to let the Bitcoin Foundation sign the executables.
By doing so, you could avoid paying the certificate every year.

[flipperfish]

I mean getting a Authenticode Certificate from a well known CA (eg. [2]) and use it to sign the executables. Microsoft does only provide the root keys, which are trusted by default (Microsoft also makes the OS, this whole procedure is used on, so the users, who do use Armory on Windows, do trust Microsoft anyways.) The private key for the code signing certificate can be stored in the same way as Armory's GPG key, so it's not owned by the NSA. (And actually, it's not the NSA I fear in this use case, but regular hackers.) Social Engineering is a concern only, if you don't check the metadata in the executable.

[2] https://www.thawte.com/code-signing/content-signing-certificates/microsoft-authenticode/index.html

If you use CA and not M$ Certs, its even more horrible and has more attack vectors.

I think there is a slight misunderstanding regarding the use case here. The proposal to have armory executables signed with Authenticode is by no means a magic bullet to make Armory bullet proof against any attack on Microsoft OSs. And in that regard, GPG also has its weaknesses. Maybe less than Authenticode, but by no means is it a bullet proof solution. However, checking the GPG-Signatures on Windows comes with quite annoying usability. With Authenticode this could be made much simpler and IMO usability is a main pillar of security (that's the reason we use Armory in the first place). So even if Authenticode has its weaknesses, it's still better than no check of the executable at all. And it eventually will happen (has already happened?), that a clueless windows user will use a malicious Armory executable, because he is to lazy to run through the GPG nightmare.
At this point one could argue, that it's GPG's fault, that its usabilty on windows is bad. One could argue, that one should not use windows at all. But that's not the point. The point is, that IMO the usability advantages of Authenticode outweigh its potential security issues by far. Additionally there is no security hole created by having an executable Authenticode signed. The GPG signatures would still work.