encryption – How S3Bubble hid or circumvented the passphrase to allow for undownloable streaming

This is a new system used by S3Bubble to stream video securely without viewers being able to download (https://s3bubble.com/documentation/aws-mediaconvert-drm-hls-with-statickey/). This a challenge they propose you I haven’t been able to crack.

It’s been a challenge for me to find where the passphrase used for decrypting the source file (m3u8) is located in the webpage/network sources, and understand what they are doing differently.

Anybody has an idea how they hid the passphrase or circumvented it?

Help: https://forum.videohelp.com/threads/401472-Try-To-Download-This-Video-P

disk encryption – “Best” transparent Linux consumer FDE setup options? (e.g. unlocking LUKS/etc without manully entering passphrase)

Summary: I’m looking at Linux FDE options that are transparent to the user (my parents) in that the user doesn’t need to enter 2 passwords. I am stating each option I found/thought of and then what I think the security implications of each are. Wanting to see if anything is inaccurate/missing. This got a bit longer than I intended… sorry about that but I don’t see any obvious stuff I could cut out. Tried to add formatting/etc to make it more readable though.

Now that my previous mistaken concerns that LUKS was vulnerable have been addressed and my (mis-)understanding corrected, I am continuing to look into using it for a Linux FDE /home partition setup. For myself, I am fine with typing out 2 passwords (LUKS + system login). But I was also interested in setting up FDE on my parents’ systems as a basic precaution against physical theft. My parents absolutely will not bother with FDE if they have to type multiple passwords and have stated they would rather not be protected than have to type a second password (basically, this is a real-world example of AviD’s Rule of Usability: “Security at the expense of usability comes at the expense of security.”).

For their systems, we would probably be going with either Fedora 33 (Cinnamon spin) or Linux Mint 20. I realize that there is a subjective decision that has to be made based on security vs. convenience. But first, I want to make sure that I correctly understand all of the options and the objective security implications before I discuss / recommend things to them. Assuming that manual entry of passphrase(s) during boot/login process is off the table, I think the following options all would work (with varying levels of security and maintenance):

  1. Local-file auto-unlock: Setup an auto-unlock with /etc/crypttab pointing to a local file and then mount the resulting encrypted drive in /etc/fstab. My understanding from the crypttab man pages is that (unless using _netdev as in option 3 below) it only supports either a binary keyfile, a text file containing plaintext password, or a plaintext password with no spaces entering directly in crypttab itself. I think that in all of these scenarios, something like this if an attacker has stolen the physical computer, it would then be trivial to gain access to the unencrypted files simply by booting up any live disc and using the password/keyfile to unlock the container just as the auto-mount does, no special tools required. IIUC, this is even worse than no FDE as it gives a false sense of security… I don’t think I would really even consider this and am just listing it in case I have grossly misunderstood something.

  2. USB-file auto-unlock: Same as option 1 but I could store the keyfile on a removable USB stick. Since my parents are very likely to leave the USB stick in the computer at all times (or at best to keep on the desk next to the computer), I don’t see this option as being any better than option 1. Perhaps even slightly worse bc it requires buying a usb stick and hogging one of the ports. Likewise, I don’t think I would consider this either but pretty sure someone would suggest it if I didn’t mention why it won’t work for us.

  3. Network-file auto-unlock: Same as option 1 but store the keyfile on a networked device. To prevent the server device from being physically stolen along with the actual client PC, my best bets would either be to have something “in the cloud”/connected via remote storage OR to have a small device like a RaspPi that I can hide somewhere just for this purpose. Personally, I’m not too fond of the idea of cloud/remote keyserver connected via internet: I’ve never really trusted “the cloud” w/r/t to important data, I perceive internet to be greater risk than LAN, and I’d probably get bitched at about multiple password entries if the internet went down (they’re semi-rural so it’s happened here and there). The RaspPi sounds like something I could manage to set up on the LAN. But as I haven’t been following IOT stuff at all, I’m unclear if IOT security has managed to improve from “garbage” to something worth possibly considering. If it has, the main downside I can see is that I would need to spend some time learning ARM-stuff and then also maintain/update an additional device.

  4. Tang-server auto-unlock: I am not sure if this is different from option 3. When I originally read about _netdev option in the crypttab man pages, I got the impression it was just a network-hosted keyfile on something like fileserver/NFS/samba. When I later ran across some Redhat documentation and opensource.com mentioning using Network-Bound Disk Encryption (NBDE) via a tang+clevis server setup, I assumed it was a different setup. But maybe they are the same? I am guessing that if they are different, then this option will have most of the same pros and cons, but it will come down to security of tang+clevis vs security of fileserver/NFS/samba – where I would expect the more specific implementation (tang) to win.

  5. Linux password auto-unlock: Make passphrase the same as the user password and replace /etc/mounttab mappings with something like pam_mount. IIUC, there is some risk here that someone could boot up a Kali (or other) livedisc, look at the hashes in /etc/shadow and then run those hashes through some kind of cracking utility to help guess the password… something like a smarter brute-force that only targets matching hashes. This option is very hard for me to evaluate as I don’t know how to do this myself and am not really sure how easy/difficult this is for an attacker to actually pull off. Plus, I know my parents’ login passwords are not typically anywhere near as strong as my own which I suspect might make such an attack easier (but again no clue how much easier). If such an attack is not that easy, then this could be a really good option for me as it it’s probably a lot less work to setup/maintain than a key server.

  6. Skip FDE and just use VeraCrypt container: Not my favorite option (some files will probably be left in the open due to human nature/human error, browser profiles unprotected, and unencrypted copies of moved files might be viewable via recovery software). But I think I’ve gotten them used to storing important passwords in a password manager so they could just copy/paste that in when opening it. And more importantly, it would only be when they are working with important files – no 2nd password to enter on a regular basis. I suspect they’d still veto this option but I’ll keep it on the table until then.

  7. Cheat: If they just don’t want to enter 2 passwords, I could probably set up a LUKS container normally (requires passphrase during boot via crypttab) and then setup a normal/non-root/non-sudoer user that does not require any password and just automatically logs right in. My gut reaction is to not do this but I can’t properly articulate / think of how to explain why this option would be “bad”. Only thing I can come up with is if the luks container doesn’t get locked on screensaver/sleep (and I don’t think it does by default – at least not in Cinnamon desktop), then anybody could just sit down and get the data without needing to physically steal the pc. But if that’s all there is, then I might be able to script a solution.

So my questions are:

A. Is my understanding of the security implications for the options above correct (especially on options 3-5)? If not, what did I get wrong/miss?

B. Are there any other options/solutions that might work in this situation?

C. If you have/had a similar situation what would you choose and why? (If it helps, I mostly interested in finding other things that I haven’t thought of or things I haven’t thought through well enough). LUKS has been around almost 2 decades… Surely I can’t be the only – or even the first – person trying to handle this type of situation 🙂

D. Consider this a bonus question / fine if you skip it. But for option 5 (linux password/pam_mount), I will admit that I am also a bit curious if my own passwords would fare any better for an attack that targets the hashes in /etc/shadow. Assuming I were to setup some dummy accounts on an old box and grab a Kali live disc, what tool(s) should I look into if I wish to attempt to see how good/bad that option is on my own? I am fairly proficient with Linux and Java but still haven’t gotten around to learning to do my own pentesting/whitehat stuff. Or if I need more knowledge than just a googling a specific linux tool, is there a book / tutorial / online course that you might recommend?

How do I save my actual SSH key (not passphrase) in the macOS Keychain

I want to store my SSH key in my iCloud keychain so it is available on all my devices. Checking this site and others, every answer to the question “How do I save my SSH key to the keychain” says to use ssh-add -K ~/.ssh/private_key_file, but that does not save the key to the keychain, it saves the passphrase for the key to the keychain. To use the key on another device, you still need to copy over the private key file.

Is there a way to store the actual SSH private key in the keychain so that I can use it without having a key file on my drive?

bash – How to supply both passphrase and string to encrypt to GnuPG using command line?

Considering using echo -n "passphrase" | gpg --batch --passphrase-fd 0 ... inside of Bash script (which should mitigate leaking passphrase to process list given echo is a built-in command, right?).

I need to know passphrase to create shares of it using Shamir Secret Sharing later in the script.

How can I supply string to encrypt to GnuPG? I usually use stdin for that.

Edit: following script appears to achieve what I want, but is it secure*?

*Passphrase and string are not leaked to other users nor written to file system and passphrase is cleared from memory once script exits

All feedback is welcomed as I might be naively considering an insecure approach.

#! /bin/bash

printf "%sn" "Please type passphrase and press enter "

read -s passphrase

echo -n "bar" | gpg --batch --passphrase-fd 3 --s2k-mode 3 --s2k-count 65011712 --s2k-digest-algo sha512 --cipher-algo AES256 --symmetric --armor 3<<<"$passphrase"

According to ps ax, above script doesn’t leak passphrase.

Is it possible to send Bitcoin without the passphrase to the wallet?

I’ve been getting back into cryptocurrency lately, and I’ve found one of my old wallet.dat files with a very small amount of BTC. Unfortunately, I created a random password of characters and put it on a piece of paper, which I have lost by mistake. Is there any way I can send the Bitcoin to my other used wallet without the passphrase, such as by finding the private keys with PyWallet and using them? I’m using Bitcoin Core.

bitcoin core – How to Recovery passphrase bitcoincore

No it is not possible to find the passphrase with a hex editor.
Bitcoin core encrypts your private keys with a random key. This random key is encrypted (AES-256-CBC) with a key derived from your passphrase.

If you remember something from the key (parts of it, letters, even length) you need a program that permutates what you know. If not you can try brute force starting with 1 character and up. Unfortunately when you chose a good key (length>15 characters) this is a near impossible task.

TPM1.2, CentOS7 and LUKS – Decrypting `root` at Boot Without Passphrase

I want to configure a CentOS 7 system to automatically decrypt a LUKS encrypted root partition at boot, without prompting for a passphrase. This server is equipped with a TPM 1.2 chip, which I can store my key in.

The partition that contains my root logical volume is encrypted with LUKS:

# lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0 278.5G  0 disk
├─sda1                                          8:1    0     1G  0 part  /boot
└─sda2                                          8:2    0 277.5G  0 part
  └─luks-efd72338-f1b6-4a50-b826-d704642c293f 253:0    0 277.5G  0 crypt
    ├─vg_sda-lv_root                          253:1    0 273.5G  0 lvm   /
    └─vg_sda-lv_swap                          253:2    0     4G  0 lvm   (SWAP)
sr0                                            11:0    1  1024M  0 rom

The TPM chip is enabled and activated. The following packages are installed:

The tcsd service is running and enabled:

# systemctl status tcsd
● tcsd.service - TCG Core Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/tcsd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2021-03-17 16:42:35 UTC; 11min ago
 Main PID: 895 (tcsd)
   CGroup: /system.slice/tcsd.service
           └─895 /sbin/tcsd

The tpm_tis kernel driver was loaded:

# dmesg | grep tpm
(    0.430468) tpm_tis 00:05: 1.2 TPM (device-id 0xFE, rev-id 71)

The tpm_version command outputs the details of my module:

# tpm_version
  TPM 1.2 Version Info:
  Chip Version:
  Spec Level:          2
  Errata Revision:     3
  TPM Vendor ID:       WEC
  TPM Version:         01010000
  Manufacturer Info:   57454300

OK, so next step is figuring out how to store my key into the TPM 1.2 NVRAM and have logic added to my initramfs to can extract the key and decrypt the root partition. This is where I’m totally lost.

I found a project titled tpm-luks that sounded fairly promising, but not having much luck thus far. After compiling and installing, I ran through the directions to “add a new LUKS key to a key slot and the TPM”:

# tpm-luks -c -d /dev/sda2 -y
Enter a new TPM NV area password:
Re-enter the new TPM NV area password:
Successfully wrote 32 bytes at offset 0 to NVRAM index 0x4 (4).
You will now be prompted to enter any valid LUKS passphrase in order to store
the new TPM NVRAM secret in LUKS key slot 2:

Enter any existing passphrase:
Using NV index 4 for device /dev/sda2

The next step is using dracut to updated the initramfs, which doesn’t finish without some warning messages. I am honestly not sure how troublesome these warnings are.

# dracut /boot/initramfs-$(uname -r)-tpm-luks.img
/usr/lib/dracut/modules.d/90crypt-tpm/module-setup.sh: line 24: /var/tmp/dracut.nPJ0Jv/initramfs/etc/cmdline.d/90crypt.conf: No such file or directory
Failed to install module tpm_bios

Broadcast message from systemd-journald@mysystem (Wed 2021-03-17 18:05:06 UTC):

dracut(28567): Failed to install module tpm_bios

Message from syslogd@mysystem at Mar 17 18:05:06 ...
 dracut:Failed to install module tpm_bios

The next step is installing TrustedGRUB in order to seal the NVRAM to a PCR. I’m not sure if this is optional or not? I would like to use GRUB2 if possible. Either way, if it is not required, I’d like to see if this process works before worrying about sealing.

I then update the GRUB2 menu to boot the new initramfs.

If I reboot my system at this point, it now prompts for a “TPM NVRAM Password (/dev/sda2)” early on in boot. After entering It then continues to load CentOS without prompting for a LUKS passphrase. I think this is one step closer in the right direction, I just don’t know how to have it not prompt for the NVRAM password.

I’m wondering if anyone has any experience with this who can assist me with figuring this out. If there is an alternative way to do this (without tpm-luks) I would be willing to try that out as well.

How can I recover a electrum wallet with passphrase and keystore file?

Is there a way to recover a electrum wallet without the seed? I have the adress, passphrase and the wallet file. I tried restoring it but it asks for seed/ master key. I don’t have those? Is there anything else I can try? When I load the file..it gives a unicode error. It looks like this. Is there a way to know, if this corrupted?


I opened it in a hex editor to look for seed. There is no seed in it.

passphrase – Need to find bitcoin wallet circa 2015

During this bitcoin boom I remember going to a bitcoin event and the host had me open a wallet and used an ATM to deposit $1 in it.

I dug through my old photos and I took a screenshot of my passphrase but no other information. I’m attaching a photo of what the screen looked like (without the phrase of course). Anyone have any idea which wallet/app/etc… this could be from?!?!?enter image description here