randomguy7
|
|
June 16, 2014, 08:14:51 PM |
|
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.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
June 16, 2014, 08:32:20 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
June 16, 2014, 09:59:30 PM |
|
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.
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
June 16, 2014, 10:38:07 PM |
|
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
Full Member
Offline
Activity: 211
Merit: 100
1ACEGiLZnZoG7KUNkMwAT8tBuJ6jsrwj5Q
|
|
June 17, 2014, 01:32:33 AM |
|
any chance to issue bulk send to multiple addresses using armory with GUI ?
|
|
|
|
Corelianer
|
|
June 17, 2014, 08:00:45 AM |
|
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
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
June 17, 2014, 08:13:18 AM |
|
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
|
|
June 17, 2014, 09:57:33 AM |
|
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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
June 17, 2014, 11:55:10 AM |
|
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.
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
June 17, 2014, 12:05:44 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
June 17, 2014, 12:38:15 PM |
|
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.
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
Rampion
Legendary
Offline
Activity: 1148
Merit: 1018
|
|
June 17, 2014, 01:51:06 PM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
June 17, 2014, 01:55:32 PM |
|
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
|
|
June 17, 2014, 02:48:09 PM |
|
@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
Sr. Member
Offline
Activity: 350
Merit: 251
Dolphie Selfie
|
|
June 17, 2014, 03:13:21 PM Last edit: June 17, 2014, 03:26:10 PM by 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
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
June 17, 2014, 11:58:25 PM |
|
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.aspxYou 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
Sr. Member
Offline
Activity: 350
Merit: 251
Dolphie Selfie
|
|
June 18, 2014, 12:13:05 AM |
|
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.aspxYou 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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
June 18, 2014, 09:40:10 AM |
|
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.aspxYou 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.htmlIf you use CA and not M$ Certs, its even more horrible and has more attack vectors.
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
Corelianer
|
|
June 18, 2014, 09:41:50 AM Last edit: June 18, 2014, 11:27:32 AM by 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
Sr. Member
Offline
Activity: 350
Merit: 251
Dolphie Selfie
|
|
June 18, 2014, 12:08:11 PM |
|
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.htmlIf 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.
|
|
|
|
|