Is a PGP revocation certificate sensitive?

What a Revocation Certificate is About

Worst case in losing access to an OpenPGP key is that it probably is published on the key servers, and you have no chance in marking it as invalid any more, it will stay there forever, telling everybody "hey, that's my key, use it".

A revocation certificate enables you to revoke your OpenPGP key if you lost access to your private key by publishing it on the key servers.

  Besides revoking the key, is there anything else it can be (ab)used for? Can I just ensure it's reliably stored but not worry about it's confidentiality?

Whoever has access to it, can revoke your OpenPGP key. This cannot be undone once published. Using the revocation certificate, no further access can be obtained: it does not included the private key.

  If I had to guess a revocation certificate is "I declare  revoked LET IT BE KNOWN! - Signed by " but I'd really like to know.

In the end, that's exactly what it is. A revocation certificate is a special kind of signature on your OpenPGP key having some "revoke" bit set.

How to Create a Revocation Certificate

A revocation certificate can be created by using gpg --gen-revoke. From man gpg:

   --gen-revoke name
          Generate a revocation certificate for the complete key.  To
          revoke a subkey or a signature, use the --edit command.

I recommend to store it both digitally in a safe place, but also print it (qrencode for encoding the ASCII-armored revocation certificate can do a great job here if you don't want to use OCR) and deposit it with somebody you know very well and trust.

Remember, even if you break up with that person, all he can do is revoking your key, not getting access to it. As you can add a description, you can even know which certificate was used for revoking your key and let the person know that to deter him.


What features boost security for a home edge router?

You would look for a network setup that includes a "DMZ" (demilitarized zone) or service network.  This network is accessible from the external network (i.e the Internet), but it cannot "jump" to your secured, internal network.

Basically, your internal network can access the Internet and your DMZ server.
The Internet can only reach your DMZ server.
(Not counting response packets)

It really depends on your router's software how you configure it, a good generic writeup could be found at Wikipedia's page about DMZ's: https://en.wikipedia.org/wiki/DMZ_(computing)


Why does Samsung Android browser say our site has a valid certificate, but the site identity has not been verified?

I don't think you can do anything about it but to upgrade your Android.

The problem here is a generic top-level domain .vip and older Android versions do not recognise them as public (hence the "a name valid only within your network" message). It's a known problem and Wikipedia lists it as one of the technical issues with these domains.

With Internet app version 4.0 on Android Marshmallow, your certificate is verified properly.

The Internet application is a component of Android, so it's not Samsung, but Google.


Why were CBC_SHA256 ciphersuites like TLS_RSA_WITH_AES_128_CBC_SHA256 defined?

I've read the history of the work on this part of the TLS specification.

Eric Rescorla (co-editor of TLS 1.1, 1.2 and 1.3) posted on Dec 31st, 2007 on IETF TLS working group mailing list about a work item called "Issue 66: HMAC-256 based ciphersuites" for the next draft of TLS 1.2 (then called RFC4346-bis, i.e. a revision of TLS 1.1, now known as RFC 5246).

The originator of the idea is unknown.

The reason to add the new cipher suites is because it's weird for TLS 1.2 to switch the PRF to SHA-256 and then not allow SHA-256 for the bulk encryption authentication.

The idea was supported by Uri Blumenthal (MIT Lincoln Lab) saying SHA-1 has weaknesses and there is no need to wait for it to be broken before replacements are defined.

Nikos Mavrogiannopoulos (author of GnuTLS) supported the idea to match the cryptographic strength of the primitives (especially of AES-256).

Pasi Eronen (Nokia, lots of work on EAP) suggested the names of some of the new cipher suites.

Then there was some talk about the right size of hash function to match to each cipher between MIURA Fumiaki (Nippon Telegraph and Telephone), Florian Weimer (BFK, Red Hat, recently worked on fixing Shellshock), Ken Peirce who suggested to use NIST "bits of security" metric the solve the dilemma, Jeffrey A. Williams and Bodo Möller (recently worked on fixing Heartbleed) who provided links and explanation that "128-bit MAC security should be perfectly fine even for applications requiring 256-bit encryption security".

The TLS spec was updated (presumably by Eric Rescorla) with the new cipher suites and published in draft 8 which was out on Jan 25th, 2008.

The draft 8 change log reads, in part: "Added support for SHA256 cipher suites", no rationale.

In the final version of the specification, in the list of changes since TLS 1.1, says "Added HMAC-SHA256 cipher suites", again, no rationale. The cipher suite list in appendix C remained unchanged since draft 8.


What's wrong with a website including a password in a confirmation email?

When a webmaster sends you a plaintext password, that usually implies that they do not hash passwords, which is a bad sign. But when the webmaster assured you that they do so right after they sent the confirmation mail, I would assume good faith and assume that they say the truth. Those few microseconds more during which the system has access to your plaintext password is unlikely to be a realistic additional security risk. But sending cleartext passwords in email is still a dangerous anti-pattern which should be avoided:

Emails are generally transferred and stored unencrypted. That means a password could get compromised by your mail provider or any servers in-between.
It is vulnerable to accidental (or intentional) shoulder-surfing. The reason why all password-inputs obscure the characters entered is that you can register an account and log into it while you have another person with you. But when the password appears in clear-text in the confirmation-mail, that person will see it (you have no reason to believe that the mail will contain any sensitive info except the usual "welcome to yadda yadda click here to activate account yadda yadda", so you would have no reason to tell them to look away when you open it).
It compromises your account when someone gets a peek at your email. For example when you accessed it from a public computer and didn't log out or leave your desk without locking your desktop while you have company. One could argue that your email account is your master-key to your online identity because it allows you to reset or request (unhashed password! bad!) the password of almost any other account you have, so you should protect it at any cost. But requesting passwords through email would leave traces and tell you how and when your password was obtained. Just scrolling through your mail while you aren't looking would not.


BREACH - a new attack against HTTP. What can be done?

Though the article is not full of details, we can infer a few things:

Attack uses compression with the same general principle as CRIME: the attacker can make a target system compress a sequence of characters which includes both a secret value (that the attacker tries to guess) and some characters that the attacker can choose. That's a chosen plaintext attack. The compressed length will depend on whether the attacker's string "looks like" the secret or not. The compressed length leaks through SSL encryption, because encryption hides contents, not length.
The article specifically speaks of "any secret that's [...] located in the body". So we are talking about HTTP-level compression, not SSL-level compression. HTTP compression applies on the request body only, not the header. So secrets in the header, in particular cookie values, are safe from that one.
Since there are "probe requests", then the attack requires some malicious code in the client browser; the attacker must also observe the encrypted bytes on the network, and coordinate both elements. This is the same setup as for CRIME and BEAST.
It is unclear (from the article alone, which is all I have right now to discuss on) whether the compressed body is one from the client or from the server. "Probe request" are certainly sent by the client (on behalf of the attacker) but responses from the server may include part of that which is sent in the request, so the "chosen plaintext attack" can work both ways.

In any case, "BREACH" looks like an attack methodology which needs to be adapted to the specific case of a target site. In that sense, it is not new at all; it was already "well-known" that compression leaks information and there was no reason to believe that HTTP-level compression was magically immune. Heck, it was discussed right here last year. It is a good thing, however, that some people go the extra mile to show working demonstrations because otherwise flaws would never be fixed. For instance, padding oracle attacks against CBC had been described and even prototyped in 2002, but it took an actual demo against ASP in 2010 to convince Microsoft that the danger was real. Similarly for BEAST in 2011 (the need for unpredictable IV for CBC mode was known since 2002 as well) and CRIME in 2012; BREACH is more "CRIME II": one more layer of pedagogy to strike down the unbelievers.

Unfortunately, a lot of people will get it wrong and believe it to be an attack against SSL, which it is not. It has nothing to do with SSL, really. It is an attack which forces an information leak through a low-bandwidth data channel, the data length, that SSL has never covered, and never claimed to cover.

The one-line executive summary is that thou shalt not compress.


An AWS Account ID can be shared, when required.

Like the documentation says, the main thing anyone can use your AWS Account Number for is to construct ARN's. For example, if I had an AWS Account which held an AWS Lambda function, and someone on another account, who I had explicitly granted permission to, wanted to manipulate it, they would use by account number in the ARN.

arn:aws:lambda:us-east-1:123456789012:function:ProcessKinesisRecords

Again, this is totally limited by the permissions applied on your account. Even if I had a full ARN, unless you give my AWS account access, I won't be able to do anything with it.

API Keys are the things that grant remote control of things, and are dangerous.


Working of WAF/IDS/IPS payload normalization schemes?

That will depend on the WAF product.

However, if the string is double encoded, it will only be of risk to the application if it performs double decoding. That's an edge case. So I can imagine that most WAFs won't do multiple decodings.

You could test this for free by setting up mod_security by the way.


What is "Client Isolation" called on wired networks?

The common term for port isolation on wired networks is Private VLAN.

However the term "port isolation" seems to be increasing in popularity with the rise of all-wireless client accesss networks, even when referring to wired networks. The "Private VLAN" term originated with Cisco, at a time when they had massive market share. That has changed in recent years as Cisco per-port market share has declined and networking has become more commodiized.


Can BadUSB be avoided by looking at the shapes and the controller model inside it?

No, you can't tell by looking at it.
There are two mistakes in your reasoning. One is that you're confusing two methods of attack: modifying an existing device, and making a device from scratch. The other is that your research clearly has an observation bias (presumably, because you're finding the things that are easier to find on the web).
Originally, BadUSB was an exploit of the firmware of an existing USB device. As any firmware exploit, it's specific to a particular device, or to a set of devices that use similar firmware. A lot of devices' firmware is susceptible to an exploit of this kind, but the exploit has to be written for each device. The goal of this exploit is to take an existing “inoffensive” device, for example a USB flash drive, and turn it into a multi-purpose device by adding the functionality of a hub (so that the device keeps working for its original purpose) and a malicious device, for example a keyboard to inject malicious commands. It works because from the point of view of the computer, the device is just sending traffic on the wire obeying the USB protocol. If the device can be reprogrammed to send traffic saying that it's a hub, then as far as the computer is concerned, it's a hub. This type of device obviously looks inoffensive, since it's physically exactly what you think it is: only the software running on the device is malicious.
“BadUSB” has been extended to a variant of this attack that reaches the same goal through different means. The goal of this attack is to have a device that looks like a flash drive, but is in fact a hub connected to both a flash drive and a keyboard. You can do that by modifying a flash drive, or by building your own device. If you build your own device, you certainly can make it look externally like an ordinary flash drive, but you don't have to. Hobbyist and security researchers who are demonstrating the possibility typically don't bother to ensure that they use chips that are small enough to fit in the intended volume and to mold them in a shapely plastic case. But there are also people who are doing this for nefarious purposes, and who therefore don't mind paying some manufacturing cost. If you're willing to pay the manufacturing cost, you can make a device that just looks like a random flash drive, but has a fake keyboard inside.
Your research has mostly found hobbyist projects for building a custom USB storage+keyboard device from electronic components that can be bought in small quantities for cheap. That's to be expected: those are the people who make web pages to explain how it all works. Actual black hats don't bother to do that, so they have a markedly lower web profile.
To get an actual assessment of whether BadUSB (including the built-for-purpose variant) is detectable, you need to look at the devices that attackers actually use, not at teaching devices. There doesn't seem to be a lot of publicly available detail about those. But I did find one article with a photo:

This doesn't look different from any other USB thumb drive.
Such devices are available for sale for only slightly more than a normal thumb drive. You even list one in your question, the Rubber Ducky:

Once again, this looks like an ordinary thumb drive. The only thing that sets it apart is the logo, and that's of course extremely easy to change. Even looking at the electronics inside, you couldn't tell that it isn't just a thumb drive except maybe by knowing exactly what this particular model looks like inside.
You cannot avoid BadUSB by looking at devices. You need to know the chain of custody of the device. Only accept USB devices from people that you trust not to be malicious and not to be fooled by a malicious device. If you absolutely need to plug in a USB device that you don't trust, configure your operating system to only automatically accept USB storage devices and to require confirmation for any other type of device, and make sure never to run software from the device or to open a file that could contain malicious macros (such as Microsoft Office files).


Why is the American Express 4-digit security code located on the front of the card?

They're 2 different security codes for cards. Amex has 2 levels of security: they have the normal CVV (Card Verification Value) and the 3 digits are a CID . CVV is a calculated highly secure 4 digit code based on your card number that is not contained in the card magnetic strip, which is the reason why it's printed on the card itself.

  If someone were to take your magnetic strip or print your card. It would not contain your CVV or CID, so it could not be used for card not present transactions or most high-end merchants, which require CVV, CVV2, or CID as a form of further verification that the card is indeed there.

  CID (Card Identification Data) on the back of the card is similar to Visa/MC/Discover. It's a 3 digit number that again is not stored on the card magnetic strip and is not visible on the front of the card, but again ensures that the card is in your possession at that the numbers have been not tampered with.

  CVV and CID verification process of card numbers is not published or available for many, many reasons, so I have no idea how they verify your card number, but they do somehow.

  To get to your question why does Amex ask for those 3 digits?
  Because they can.

  They require most merchants these days to verify the CVV before processing payment, but for their measures of security they verify the CVV and CID. I think most of us who have had the card for many years memorize the CVV, but I couldn't for the life of me memorize the CID, so that could be the reason to.

Source


Is accessing Cockpit through SSH tunnel secure?

I think you're jumping through hoops that you don't need. Whether cockpit uses fail2ban or not is a good question, but as for whether you should put cockpit's port 9090 directly on the internet, or wrap it in an ssh tunnel ... why? Cockpit registers itself as a system pam module (see cockpit docs) which means that when you interact with the cockpit login page, you're actually interacting with the core system login mechanism the same way you would if you were interacting with the ssh server.
I only gave cockpit a quick look a couple of years ago, but it seemed solid to me. I would feel comfortable exposing cockpit's port 9090 directly. (unless I'm also missing something)


1) As long as your browser has shown a green (or at least not red and with a warning message) https in the address bar then you've successfully authenticated to the other end without compromise. It's highly unlikely for the attacker to be able to man-in-the-middle the SSL connection without the private keys of the host server (e.g. your bank) to sign the ssl certificates that the https host has. If he tried to sign certificates, the browser would detect his falsely signed ones.

2) As for VPN, it depends. If you do it over SSH, make sure the presented fingerprint is in fact that of the host you are connecting to. The fingerprint might be cached by your computer already, so if your VPN connection starts automatically, the chances are very high that there is no compromise otherwise the VPN software would throw some alert message at you saying that the fingerprint has changed (indicating a possible man-in-the-middle).

Of course, if you do anything over plain old HTTP, forget about all security.

3) I'm sure there's a way. Just google the make and model of the router.


This is Brian Spector; I'm the CEO of CertiVox.
Thanks for starting this discussion on PrivateSky, our secure information exchange service.  I’ll do my best to answer the intelligent comments and criticisms on this thread.
Second, I’ll try my best to walk the reader through step by step on how our integrated key management and two factor authentication works.
I invite the folks on this thread who haven’t read the white paper to please do so.  Everything I am writing has already been written in detail and is publicly available in that document on our website.  But since no one reads white papers….
First, let’s refute the statement that we are "lying".  We are not, and indeed, we are trying to be as transparent as possible about how we do what we do.   It’s hard to argue with that kind of blanket statement, so rather than go there (“so Mr. Jones, when did you stop beating your wife?”), let’s just go through the intelligent points on this thread, as there are quite a few.
To that end, that’s also why we open source our MIRACL SDK, freely available off of our website.  MIRACL powers PrivateSky, and the same cryptographic processes in use in PrivateSky are available as libraries in the MIRACL SDK, so you can review the code.  MIRACL is in use by hundreds of companies around the globe, and has a fairly decent reputation as having very fast elliptic curve cryptography optimized for constrained environments.   It is trusted by many organizations. We take that trust extremely seriously; it’s our bread and butter.
To correct Lucas’ statement here:

Probably the simple answer is: it's not.
If I read correctly they just seem to have used a form of symmetric encryption to authenticate yourself to the system after which you can access your private keys to encrypt data (the private keys are encrypted with your pin).

That’s not correct.  Let’s clear up that one up first.  The SkyPin you see that logs you into PrivateSky with your email address and 4 digit pin is an elliptic curve authenticated key agreement protocol that uses two factors of authentication, based upon an IEEE P1636.3 draft standard, Wang’s protocol, with the addition of our chief cryptographer, Dr. Michael Scott’s protocol for remote login with simple token and 4 digit pin using elliptic curve bilinear pairings.
Note that Mike’s protocol has been peer reviewed extensively since its first publication in 2002, has withstood over a decade of cryptanalysis, and we’ve published an updated version, this time adapted for use with Wang’s protocol.
Of the two factors, the first factor is a mathematical token stored in your browser, locked to the domain of our authentication service, the second factor being your pin.  It work’s like this: The SkyPin Pad you use is actually performing a reconstitution of an identity based encryption key issued in the ID of your email address, we issue this to you when you register.  During the registration process, the SkyPin Pad performs a equation on the IBE key you were issued using the 4 digits you select.  This process is performed locally.  We don’t know what those 4 digits are.  At that point, it becomes what we call a “token”.  The token is stored in your browser’s HTML5 local storage, not session storage (i.e., not a cookie).  This is locked to our authentication service’s domain.
The next time you login, the SkyPin Pad is served from our web server (over TLS, domain secured by DNSSEC) and runs locally in your browser.  The SkyPin Pad takes as input your 4 digits, reverses the equation, reconstituting the identity based encryption key you were issued when you registered, again, performed locally.  This is Scott’s protocol.  The next step is an authenticated key agreement protocol based upon Wang’s protocol, whereby encrypted nonces are exchanged with the IDs of the server and individual attempting to authenticate mutually.  At then end of the protocol, both the server and individual have identified themselves to each other, and each side has at their disposal an AES 128-bit key, the session key.  Hence the term; authenticated key agreement protocol.
So no, this system does not use symmetric keys to authenticate users.  It’s a two-factor authentication system based upon elliptic curve cryptography, running in JavaScript, tailored for HTML5 compatible browsers, that performs authenticated key agreement.
Lucas is also incorrect with this statement (note Lucas that generally you don’t decrypt with public keys, you verify signatures with public keys, you encrypt with public keys):

It still might be decrypted with a the other persons public key browserside. But then again everyone has a public key available, they just need to fetch it from the server and apply it by the browser. – Lucas Kauffman5 hours ago

And by association Rasmus is correct with this statement (thank you for reading the white paper, btw):

According to the white-paper they use SK-KEM, which is an identity-based encryption scheme. This explains why you do not need the public key of B in order to send an encrypted message to him (the email-address is the public key).

In an exponent inversion system like the variant of SK-KEM that we are using, it’s actually a key encapsulation system, whereby the content encryption key is encapsulated (i.e., encrypted) using a protocol with inputs of the global public key of the system and the email address of the recipient.  The message is signed using the ECCSI protocol with the user’s private key issued from our private key generator.  The user employs a different private key issued from our private key generator to decrypt a message, using the SAKKE protocol (a variant of SK-KEM).  The cool thing about SAKKE is that is also has the ability to federate private key generators.  Assuming a user has access to the public parameters of another’s private key generator, user A who has a private key of a PKG A can communicate with user B who has their private key issued from PKG B.
Both ECCSI and SAKKE are part of an IETF informational draft called MIKEY-SAKKE, which is being standardized to provide voice data and encryption over 3G networks.  MIKEY-SAKKE has strict guidelines on the operations of the PKG to cover such nuances as master key rotation (every 30 days) and packet assembly.
Up until recently, it was assumed that you could not distribute the private key generator in an exponent inversion system.  Thankfully, Smart and others devised a multiparty computation protocol that enabled such a possibility.
Developing further on that work, Smart and Geisler published a paper called “Distributing the Key Distribution Centre in Sakai–Kasahara Based Systems.”
Effectively, you could split the PKG into distributed private key generators, or D-PKG’s.  The nice thing about this is that after the initial setup, the master key doesn’t live anywhere in whole; it is split into thirds.  Only two of the three nodes need to be available to server shares of the private key to the intended party.  The master node is taken offline and discarded after setup. Assuming you have built processes by which to do this, shares of private keys in such a system can be created dynamically as they are requested.
Rasmus makes this statement:

Usually identity-based encryption relies on a trusted third party. So their claim that they cannot decrypt the messages themselves is based on their having placed the master private key and the associated private key generator inside what basically amounts to a hardware security module.

And Lucas makes this statement:

Yes, it seems they just put the trust somewhere else. They can't decrypt it their selves, but their claim that no-one else can seems to be false

Rasmus is partially correct, and Lucas is not correct.  It’s actually several hardware security modules, none of them actually possessing the master key in whole.  We take the additional steps: D-PKG nodes into HSMs that are tamper proof, tamper resistant, with integrity verification upon boot up of the VM, and carry no state (other than their share of the master key and the code to distribute shares upon authenticated request).  We cannot access the shares of the D-PKGs without ruining some expensive kit.  But let’s assume we could re-constitute the shares of the PKG.
Because we are following the MIKEY-SAKKE operational guidelines, these D-PKGs are only in operation for one month, meaning, the master key and subsequent private keys issued are only good for one month, and the entire population is rotated every month.
In PrivateSky, the user will be asked to create a unique passphrase.  This is used to create a 32-byte long-lived ECDH private key (and subsequent public key), which can also be used in an ECIES setting.  The ECDH public key of the user is stored in our directory.  The D-PKGs have ECDH key pair that is not long-lived, only monthly. When new keys are issued, a DH secret key between the D-PKG month private key and the ECDH public key of the user is created to encrypt the newly issued ECCSI and SAKKE private keys for the user.  This happens for every user.  These are stored within our directory for the user so they can decrypt old messages outside of the 30-day master key rotation window.
The point being, after the 30-day window where the shares of the master key are in use, the VMs are destroyed, the key material inside the HSMs are wiped, and we start over again.
So let’s outline the general attack scenarios:
Inside the 30 day window, in order for us to decrypt the data (or turn over keys when we are served summons for requests for information):

We need to carefully hack an HSM at FIPS 140-2 Level 3 so as not to destroy the units, twice.  In two different data centers.

Outside of the 30 days window:

We need to crack AES 256 in order to decrypt the archived private keys OR
Someone has to crack AES 128 bit for every single message

You are probably wondering, why in the hell have these guys gone to such great lengths to construct such a system?  Especially in light of this admission:
User 1202236 makes this statement:

Thanks for clarifying. So instead of trusting a software company, now you trust a hardware company and that the software company actually uses the provided hardware. It seems to me that you need to trust quite a few people when compared to PGP.

That’s correct.  Let me ask this is a more direct way:  On a trust scale, is it better to use PGP or PrivateSky if you want to be 100% sure that no one can see your data?  Answer: There is no question that creating your own private key via a system such as PGP is better as a trust model.  No question at all.
There is only one problem.  PGP and the current state of the art are too damn hard for the general population at large to use.  Not the people on this board mind you.  But I mean my daughter, or her friends, or my parents.
In PrivateSky, using a PIN, a passphrase and your email address, we can get you close, with two-factor authentication as a bonus.  And you don’t have to learn anything.  You don’t have to do anything different to use PrivateSky than you would any other web property around.  That’s why we built it.
The people at CertiVox sincerely believe that just because we want to communicate something through the Internet doesn’t give the government, the NSA, Dropbox, Google or any media companies the right to use my family’s information or mine in the largest data mining scam ever perpetrated on the human race.
From a business perspective, our architecture also accomplishes the following:
We will be served with requests for information from authorities. That’s a fact of life when you run a Saas business. Thankfully, in the UK and the EU, there is due process and law for this.  How we comply, and our ability to prove the extent of our compliance, rests with the architecture we develop.  If your data is accessible by us in the clear, then we have to turn it over.  If it’s not, then we still have to turn it over.  But if what we turn over is encrypted, and we don’t possess the keys, then what good is the data (it’s encrypted), and what good is serving a FISMA warrant or EU equivalent on us?  Complying with requests for information is really, really expensive for a young company.  Not being a target for such requests is a competitive edge.
Which leads me to my next point.  The team at CertiVox has made a bet that there is a market for a secure information exchange service where our business model is dependent on NOT seeing your data.  We believe (maybe naively) that there is enough people and organizations out there who are concerned about the erosion of privacy but don’t have the technical expertise to do anything about it.  Dropbox needs to see your data to de-duplicate.  Google needs to see your data to serve you ads.  We don’t do either and never will.
To that end, we will soon introduce the capability for anyone to run your OWN distributed private key generators, and register these on our system (through the SAKKE federation capabilities), completely taking us out of the loop.  You control your own population of users, can rotate master keys at will, revoke users, etc.  That WILL give you the equivalent trust model of PGP.
Lastly, let’s go through the steps of how our integrated key management system works.  We call this Incognito Keys.  You can download an info graphic PDF that is a visual diagram of the following explanation:
To encrypt and sign a message:

Alice logs into PrivateSky with her SkyPin and email address.  The two-factor authenticated key agreement protocol produces an AES 128 bit key for use at the browser end and at the authentication server’s end.
The authentication server passes the AES key to our “black boxes”, the D-PKG nodes.
The D-PKG nodes assemble the shares of Alice’s ECCSI key and encrypt these with the AES key.
Alice receives the encrypted ECCSI key (shares), decrypts the shares with her AES key, assembles the ECCSI key from the shares, and is ready to go.
Alice writes a message to Bob and encrypts the message with an AES key, called the content encryption key.
Alice encapsulates the content encryption key with inputs of the Global Public Key and Bob’s email address and appends the encrypted / encapsulated key to the message.
Alice signs the message with her ECCSI key.

To decrypt and verify a message:

Bob logs into PrivateSky with his SkyPin and email address. The two-factor authenticated key agreement protocol produces an AES 128 bit key for use at the browser end and at the authentication server’s end.
The authentication server passes the AES key to our “black boxes”, the D-PKG nodes.
The D-PKG nodes assemble the shares of Bob’s SAKKE private key and encrypt these with the AES key.
Bob receives the encrypted SAKKE private key (shares), decrypts the shares with his AES session key, assembles the SAKKE private key, and is ready to go.
Bob receives the message in his portal, which contains the encapsulated content encryption key.
Bob verifies Alice’s signature, and de-encapsulates the content encryption key with his SAKKE private key.
Bob uses the content encryption key to decrypt the message.

So there you have it.  You can argue with the math, the implementation or our intentions, but hopefully we have made all three clear.
Thanks for reading all the way through, and please sign up for PrivateSky!  You can see all of this working in action for yourself.
Brian


What is "half PFS" protection, and what protocols or configurations apply to it?

I'm not completely sure I understand the concept. But I think that the point is that with short term ("ephemeral") asymmetric keys (DH, ECDH nowadays. But "ephemeral RSA" used to be a thing as well.) there are several opinions about exactly how short term these keys are supposed to be.

At the high paranoia end "short term" might mean "once for each connection". And at the low paranoia end "short term" might mean "until you reinstall the software because key shares are only ever generated on install". -- And everything in between. For example with F5 I think the default is to regenerate DH keys once per hour. But you can optionally set the "single DH use parameter" to actually regenerate for each connection. And OpenSSL has an option called "SSL_OP_SINGLE_DH_USE" that, I think, does the same thing. And otherwise DH keys are only regenerated upon server restart. And with Citrix NetScaler you can define a max count of connections after which the DH keys are regenerated.

(See a related answer of mine.)

I don't think the TLS specs ever specify how often you're supposed to regenerate ephemeral keys. I think they leave this up to implementor completely and never make an explicit or even implicit comment.

Now what does this mean security wise? Let's assume that you have a TLS connection. With the best case -- single DH use -- on one end. And a not so good case -- regeneration of DH keys upon server restart -- on the other end. And let's a assume that we have a man in the middle attacker who is employing a "take-all" attack. And just logs encrypted traffic for a few weeks.

Now if that attacker somehow gets a non-full compromise of one of the connection ends -- like e.g. a snapshot with RAM of one of that ends -- what does that give him?

If he is lucky enough to get the snapshot of the not-so-good end than this would allow that attacker to retroactively decrypt any logged past DHE secured connection from the past. Since server restart. And also INTO THE FUTURE until the next restart.

And it doesn't matter if all the other ends are constantly changing their part the ephemeral key dance.

Hope this somehow answers your question.

Side note: there was actually some DEMAND for TLS clients/servers that DO NOT actually have much ephemerality (is that a word?) to their ephemeral keys during the TLS 1.3 design process: https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility


iMessages in iCloud feature = all unencrypted messages on Apple servers. How secure?

You seem to have one of the more common misconceptions about end to end encrypted messengers. The end to end encryption is used for messages in transit from Alice to Bob, once they've reached Bob's device they're generally stored unencrypted (albeit usually with encryption at the system level). Encryption of stored messages and backups is a separate feature.

The only reference to iMessages stored in iCloud I could find in this document is the following:

  iCloud also backs up information—including device settings, app data,
  photos, and videos in the Camera Roll, and conversations in the Messages
  app—daily over Wi-Fi. iCloud secures the content by encrypting it when sent
  over the Internet, storing it in an encrypted format, and using secure tokens
  for authentication......

  Here’s what iCloud backs up:

  ...
  iMessage, text (SMS), and MMS messages (requires the SIM card that    was in use during backup)
  ...

So it appears that all data backed up to iCloud is encrypted, but the key is almost certainly held by Apple. Since the SIM card is required to restore iMessages that hopefully means that iOS encrypts iMessages with a key derived from information on the SIM card before sending the data to iCloud, but I haven't seen any confirmation of this, and I'm not familiar enough with SIM cards to know how secure this would be.

As for syncing messages without a backup, all I see is:

  The user’s outgoing message is individually encrypted for each of the receiver’s devices.

Which isn't so much "syncing" messages as automatically sending the same message to all of the recipient's devices. If the recipient activated a new device after the message was sent, it wouldn't appear on that device. This doesn't seem to line up with your claim of being able to sync and recover messages without an iCloud backup.


Key Exchange algorithm to be used for REST framework

I'm not 100% clear on your question, but I can hopefully offer some guidance:

In general, you should never try to, or have to, create a custom security protocol. It's ill-advised and prone to serious error. Not even the experts trust themselves to do this quickly and/or without a ton of peer review.

Not being familiar with the exact problem you're facing I can simply say this: find out how this has been done successfully in the past with a known-good (secure) protocol, and use that.

Do not try to make your own.


It is possible to enumerate/discover IIS applications from outside?

Regardless the web server software used, web applications typically have a path and a hostname.

If the web server is configured to serve an application using the default virtual host and the path to a common web application is the default, http://192.0.2.1/path/to/app type URLs alone could be used for enumeration.
If the application is only available on a single virtual host, the correct Host: example.com header is required. For this, one would need to know all the hostnames associated with the IP address, but there are search engines like F-Secure Riddler that have probably already indexed it.
Regular search engines may already have indexed the web application, especially if indexing is not limited with robots.txt, Robots meta tag or X-Robots-Tag header. E.g. Google search with site:example.com may find the application without enumerating directly against the web server at all!

If robots.txt was used for preventing indexing, it may contain useful information.
Bad robots might not obey any of these humble requests for not to index.

How to protect against this?

Try these techniques yourself and if you find something disturbing, try to change it. Notice that you have more power over your own system than over all the search engines. (This question was already tagged as penetration-testing.)
Do not think obscure URLs as protection! Depending on the purpose of the app you may add additional levels of authentication, allow connections only from trusted networks etc.


Is a server infrastructure fundamentally possible which the smartest person can't breach?

"No perfect defense is fundamentally possible."

In chess, you have 64 squares, 2 people playing, and one set of immutable, commonly known rules.

In server infrastructures, there are an untold number of assets and ways to approach those assets, an unknown number of people playing, and rules that change constantly with players purposely seeking to bend, break, or bypass the rules.

Consider 2 elements that will prove my point: zero days and chocolate bars.

Firstly, zero days change the rules while the game is being played. While one side gains the benefit of this element, the other side is unaware of the advantage and is possibly still unable to counter these attacks, even if they are eventually known. Each zero day is a new rule that is unevenly applied to the game. Even if a "perfected security strategy" can be devised and perfectly applied, zero days can mean that the strategy is built upon unknown weaknesses that might never be known to the defending side.

Secondly, chocolate bars can do more to break the security of an infrastructure than any other element. What I mean is that people can be bribed or enticed to "switch sides" and grant advantage to the opposing side, sometimes for something as small as a chocolate bar (studies show). Phishing, bribes, data leakage, etc. are all part of the human side of the game that technology cannot account for entirely. As long as there is a human with power in the infrastructure, there will always exist that weakness to the system.

What to do?

In history, we see multiple situations where a massive attempt at defence was defeated by something small and unforeseen (e.g. the Great Wall of China's gates opened to a concubine who was a double agent for the Mongols). The goal, as defenders, is not to mount the perfect defence, but rather to design a resilient and transparent infrastructure where attacks can be seen quickly and responded to completely. Not taller walls, but more alert militia. Not unshakable foundations but a replaceable architecture.


My name is an alias, and I am a professional paranoiac.

If you start from the philosophically cynical position that every piece of technology required to produce and distribute information is potentially compromised, then you will have difficulty accepting any current successful theory of information security.

Take the simple case of a desktop computer used to type an e-mail.
Keyboard: compromised
Hard drive: compromised
RAM: compromised
CPU: Compromised
Video Card: compromised
Network card: compromised
Network router: compromised

What would it look like to have a secure chain from at least your fingers to your ISP?

Keyboard: self made from simple momentary push buttons
Keyboard to computer interface: self made from individual CMOS logic gates
CPU: ...

And at that point you are screwed, because any modern technology is complex enough that it must be designed by and manufactured by people unknown to you and uncontrolled by and unresponsive to you.

This requires trust.

I must trust that whoever designed and manufactured the CPU is selling a uncompromised product. I can take steps to reduce the risk that the individual CPU that I purchase is compromised, but this then requires a theory of who is capable of compromising a CPU and what would motivate her to implement such a compromise.

The modern view of risk is based on a rough social theory about who attempts to do what and for what purpose.

Intel, AMD, and ARM, and other CPU manufacturers seem to want to make money. Compromising their own product seems to be inconsistent with their profit goal. The number of individuals capable of covertly compromising a CPU such that it would introduce an vulnerability allowing them to covertly intercept your data is small. The effort required to perform such a compromise is great. The value of a individual person's e-mail is small. There are other easier ways to obtain access to a person's e-mail than CPU compromise, so most infosec professionals consider mass produced commodity CPUs to be an acceptable risk.

So the argument goes with most computer components, because as it has been shown again and again it is really much easier to compromise a person at your office, or at your ISP, or you than to pull off some amazing covert feat of technical hackery.

The answer is that no one is guaranteeing that Truecrypt is secure, but they don't have to because Truecrypt provide more evidence of honest functioning than any CPU maker, and RAM or Flash memory manufacturer, or any computer retailer.

The source code is available for inspection by anyone at any time.

You can compile a binary from the source code and compare it to precompiled binaries.

Unintentional security flaws have been discovered in the source code and fixed.

And if you are happily typing away at a café with free WiFi and some adversary is running Firesheep and intercepting your traffic, it doesn't matter if your hardware is un-compromised and Truecrypt is secure. If your OS or browser software is vulnerable, or you connect to a poorly configured WiFi router, your information is vulnerable.


Is this a remote code execution vulnerability?

Yes, I think it is vulnerable, or there's something wrong anyway. Here's why.
That guy (or girl) is suggesting that his machine has been compromised because of some RCE. We don't know if that's true, or why he's suggesting this. However he says his current Solr version is 7.7.2. That's not the latest version, according to the news on the official website, and several sources report that 7.7.2 is vulnerable to RCE: see cvedetails.com and Reported attack to install miners, for example. It might also be vulnerable to CVE-2019-17558 (another RCE), but that's not clear to me, among other things that are also not clear (for example why the hell the 7.7.x branch was fixed so late, with version 7.7.3 released on April 28th 2020, while the vulnerability was reported in the summer of 2019).
Anyway, why is that guy running an outdated Solr version? He also said that "his current build-deb was taken from the master". So I took a look at the code, and there's a bash script named build-deb. Here's interesting piece of that script:
# if not yet there, download Solr binary release
if [ ! -f "src/solr.deb/usr/src/solr-7.7.2.tgz" ]; then
    mkdir src/solr.deb/usr
    mkdir src/solr.deb/usr/src
    echo "Downloading Solr"
    wget -P src/solr.deb/usr/src/ https://www-eu.apache.org/dist/lucene/solr/7.7.2/solr-7.7.2.tgz
fi

Basically, the current master branch has a script that is used to build a deb file for installation, but some dependencies are actually embedded in the deb file (instead of letting the system take care of them, and use the latest releases from the OS repositories). Note that they are explicitly including Solr 7.7.2 in the installation, which appears to be outdated and vulnerable.
In general, should you use software you find on GitHub? Well, maybe. There's a saying that goes "Given enough eyeballs, all bugs are shallow (hopefully)". But small projects might not attract enough developers to be able to provide enough quality, maintenance, and security. There's no way to know if a small project is secure, unless you take some time to read the code. For bigger projects, on the other hand, while they are not guaranteed to be secure at all, at least it might be easier to find more information, opinions, reviews, or support.


Is using a dedicated IP for AWS dev access secure enough?

That approach would work. So you would have your dedicated VPN IP that is the only IP address whitelisted ("nnn.nnn.nnn.nnn/32") in AWS for port 22. This is best if you need to access your AWS resources from several different networks (home, office, coffee shop, etc.). If you only needed to access AWS from a fixed office, you could whitelist the address block for your office's ISP. Anyone from within that ISP could talk to your SSH service so it is not at tight as it could be. A quick search tells me that dedicated IP VPNs are $10-$20/month. You just have to decide if that added security worth the added cost to you.
Obviously it makes securing your VPN credentials the most important part of your setup. Make sure to enable MFA for the VPN access. And I would still recommend SSH key-based auth where the private key uses a different password from the VPN password.


iTunes Account Joined Family Group Without Permission

This is a really strange one, never seen such a thing happen myself. It's hard to say what his intentions would've been, one thing that springs to mind is if the card he used was stolen (fraud) I guess by joining it to "group" he could make it appear that he didn't do it? It's a longshot of an answer I'm afraid but that is literally the only thing that comes to my head.

In terms of did he get anything - IF he was doing it for the reason I suggested I guess the actions could potentially come back to you, but as I said it's a bit of a longshot.

I don't think there is much else you can do other than changing your password and he didn't get access to the account anyway so it seems he really didn't achieve anything.

I'd be interested to know how he could circumvent the acceptation that's interesting I've no idea how though unfortunately.

Hope this answer helps... I would've put it in a comment but I can't.


How does algorithms ensure public/private keys uniqueness? - RSA

The way random prime generation works is by generating a huge, random odd number of a specific size (e.g. 2048 bits). It is then checked for primality. If it is not prime, it is incremented by two and checked again. This repeats until it is found to be prime. I describe this more in another answer.

There is nothing specific that prevents two private keys from being the same, but the probability of that is so astronomically low as to be irrelevant. There's no reason to explicitly try to avoid collisions. Note that this assumes the system has a good source of random numbers. Bugged random number generators or embedded systems with a poor source of randomness may generate RSA moduli who share a prime factor, leading to trivial cryptanalysis by checking for the greatest common denominator between two moduli and then dividing them by the result to obtain both prime factors.

See also What are the odds of an RSA private key collision?


What concrete parameters can I change to make my passphrase-protected private gpg key more secure

Reasonable Defaults for s2k

You can tune multiple parameters. The s2k-mode should generally stay on it's default value, 3: this uses both a salt and repeats salt and passphrase during application of the digest function. Further parameters are the symmetric encryption algorithm (s2k-cipher-algo), the digest algorithm (s2k-digest-algo) and (if mode 3 is used) the number of repetitions of hash and passphrase, increasing the amount of data to be hashed (s2k-count). All of those options can either be set in the GnuPG configuration file ~/.gnupg/gpg.conf or on the command line (prefixed with --, for example --s2k-digest-algo).

For the three "tunable" options, you have to balance execution time and security.

s2k-cipher-algo: As the amount of data to encrypt is very small, it does not really matter how much overhead is spent on encryption without a notable difference. The default AES128 should probably be fine, but why not use the additional security margin if we won't suffer from a notably higher computation effort?
s2k-digest-algo and s2k-count have impact on the time spent on hashing while trying to crack the passphrase. The default SHA-1 has some known weaknesses and is considered outdated, so choose some algorithm of the SHA-2 suite. While writing this answer, 65011712 repetitions and SHA512 resulted in each decryption operation taking a notable delay but far below a second on my mobile Core i7; if the decrypted key is cached in gpg-agent anyway probably something one could live with.

I'm not aware of a discussion of reasonable defaults here, usually the recommendation is to make hashing as expensive as you can accept.

  I don't care about slow arm processors. I would rather wait 100 milliseconds longer, and have my passphrase iterated 65011712 times.

If you really don't mind, the "heavy-duty" configuration will be

s2k-mode 3              # default anyway
s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-count 65011712

For a still-totally-fine, but faster configuration reduce the computation effort for hashing by using a smaller value for s2k-count or SHA256. AES128 as cypher is fine, but does not result in a notable faster computation.

Using those Defaults for Private Key Encryption

TL;DR: You need to trigger saving the key again (for example by changing the passphrase), as exporting just dumps from hard disk. GnuPG 2.1 (modern) is affected by a bug.

The longer version:

You have to discriminate between several uses of digest algorithms in OpenPGP/GnuPG.

OpenPGP Fingerprints

For calculating fingerprints, OpenPGP requires keys to be hashed using SHA1, as you can read up in RFC 4880, Section 12.2, Key IDs and Fingerprints:

  A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
     followed by the two-octet packet length, followed by the entire
     Public-Key packet starting with the version field.

There is no choice or possibility to configure this. We will observe this again further down.

Modification Detection Code Packet

The Modification Detection Code Packet also uses an SHA-1 hash to protect encrypted messages from being manipulated, no choice is left for configuration. This is not really relevant for the further discussion, I just mentioned it for completeness.

Symmetrically Encrypted Session Key and Data Packages

These package are used both in "normal" OpenPGP messages encrypted for a public key, where they again contain the literal data package and for messages encrypted with a passphrase.

In the first case, the symmetric key is encrypted using an asymmetric algorithm like RSA, no passphrase (or hashing of such one) is involved.

It can also be used to encrypt a message symmetrically based on a passphrase, for example using gpg --symmetric, which will ask for a passphrase and encrypt from STDIN. The pgpdump (a tool similar to `gpg --list-packets, but sometimes providing more suitable output) output of such a message looks like

$ echo "foo" | gpg --passphrase "bar" --symmetric | pgpdump
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
    New version(4)
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA1(hash 2)
        Salt - 1d cd 72 c8 c3 30 df 84
        Count - 65536(coded count 96)
New: Symmetrically Encrypted Data Packet(tag 9)(26 bytes)
    Encrypted data [sym alg is specified in sym-key encrypted session key]

Observe the settings for the string-to-key procedure: the digest algorithm (SHA1 as default), and the mangle count. These can be configured using --s2k-digest-algo and --s2k-count. Lets see what happens if we set those to SHA512 and the maximum of 65011712:

$ echo "foo" | gpg --passphrase "bar" --s2k-digest-algo SHA512 --s2k-count 65011712 --symmetric | pgpdump
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
    New version(4)
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA512(hash 10)
        Salt - ea 62 a1 ff 0b 2b f6 6a
        Count - 65011712(coded count 255)
New: Symmetrically Encrypted Data Packet(tag 9)(26 bytes)
    Encrypted data [sym alg is specified in sym-key encrypted session key]

We successfully changed the passphrase mangling options using the --s2k-... options.

Passphrase Protected Exported Secret Keys

Now, let's get to one more use of the string-to-key procedure, encrypting exported secret keys. RFC 4880, 5.5.3.  Secret-Key Packet Formats indicates the same string-to-key procedure should be in use, but indeed, --s2k-digest-option and --s2k-count have no effect any more:

$ gpg --s2k-digest-algo SHA512 --s2k-count 65011712 --export-secret-subkeys 0xDEADBEEF | pgpdump
[snip]
Old: Secret Subkey Packet(tag 7)(510 bytes)
    Ver 4 - new
    Public key creation time - Mon Jun  1 16:06:06 CEST 2015
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(1024 bits) - ...
    RSA e(17 bits) - ...
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA1(hash 2)
        Salt - ab 7d c8 36 6a 67 4d dd
        Count - 65536(coded count 96)
    IV - e9 76 d3 c4 b0 de 24 3c
    Encrypted RSA d
    Encrypted RSA p
    Encrypted RSA q
    Encrypted RSA u
    Encrypted SHA1 hash
[snip]

This actually puzzled me for quite a while.

The solution was rather easy, though: gpg --export simply exports the key from the secring.gpg as-is. Setting the option for gpg --edit-key (through parameters or the gpg.conf file) and subsequently changing the passphrase using passwd triggers writing the encrypted key to the secring.gpg again -- and voilà, the key is encrypted as we wanted it to be, we don't even have to set the --s2k-... options during export any more:

$ gpg --export-secret-subkeys 0xDEADBEEF | pgpdump
[snip]
Old: Secret Subkey Packet(tag 7)(510 bytes)
    Ver 4 - new
    Public key creation time - Mon Jun  1 16:06:06 CEST 2015
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(1024 bits) - ...
    RSA e(17 bits) - ...
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA512(hash 10)
        Salt - e1 82 c3 9f 07 74 7f 0c
        Count - 65011712(coded count 255)
    IV - 97 20 69 ae 8d ec 0d 3c
    Encrypted RSA d
    Encrypted RSA p
    Encrypted RSA q
    Encrypted RSA u
    Encrypted SHA1 hash
[snip]

GnuPG 2.1 (modern)

As of 2015-06-01, GnuPG 2.1 ("modern" branch) is affected from a bug (GnuPG Issue #1800): here, the gpg-agent takes care of all those operations, but does not care about the --s2k-... options at all. This should be resolved soon, as the bug was already marked as urgent by Werner Koch, GnuPG's main developer.


Does IPv6 without NAT allow my ISP to identify/monitor/limit the number of devices in my network?

If you are not using NAT, then they will be assigning an IPV6 address to each device and will be able to identify them.  You could still use NAT however and they would be unable to detect how many devices are behind the gateway device since only the one gateway device would make all requests.

A NAT conceals the information about your internal network because all Internet connections originate from the one IP and are mapped to your internal network.  There is no reason the same thing can't be done with a single IPV6 address and device.  IPV6 just makes it so that layer isn't necessary if people don't need/want it.


How to guarantee that password is hashed on server-side?

You raise several issues.

Server trust

You never know what the server will do with your password once you send it

Password reuse

Password reuse can be prevented by you: don't use the same password at multiple places.

Hashing

If you were to hash the password before sending it to the server, then the hashed password would become the password. If the server would store that, and it would be read by an attacker, he could log in with it. He doesn't need the original password, since the server checks the hash. It would prevent usage of the password at different websites, but the best measure against that is not to reuse passwords.

A protocol that will work in this situation is a challenge-response scheme. The server could send a challenge to the client, the client could hash the challenge with a keyed hashing protocol (like HMAC+SHA1) and send that back to the server. The server however still needs the password to verify the hash, so it must be stored.

If you want al scheme in which there is no shared secret between the client and the server, look to asymmetric encryption. You could give the server your public key, and have it verify who you are by encrypting a nonce with the private key. You can use SSL for this, with client certificates.


Types of firewalls to implement to reduce DoS attacks in POS systems

You have multiple areas of concern with DOS/DDOS attacks. If they are external they can fill up the "pipe" in your ISP before they ever reach you. That means that nothing on the inside (internal firewalls, layer 7, blackholes) will prevent packet loss before you even are reached. In order to mitigate this you need to contact your ISP and they will have protections (Kona being Akamai's; there are others).

Internally, a layer 7 firewall should have protections against this. Most layer 7's work with "DPI" and "stateful" detection which means that if you're getting a packet that doesn't make sense for the communication flow, it will be blocked. It will also cut connections for slow loris and other common attacks.

How does your small subnet use the internet? What are you required to allow in? Can you set this up in "proxy half open" which means that anything is allowed out to start a connection, but all incoming connection requests are blocked? That alone should solve this problem so long as the packet flood isn't more than your ISP "pipeline."


Level of isolation that Chromium's "Guest Browsing" provides?

According to the Google's docs here

  Differences between Guest mode and Incognito mode
  Both Guest mode and Incognito mode are temporary browsing modes, but there are some basic differences between them.
  Guest mode: A user in Guest mode does not leave any browsing history or cookies on the computer. In addition, they can't see or modify the computer owner's Chrome profile.
  Incognito mode: You don't leave browsing history and cookies on your computer, but you can still see your existing history, bookmarks, passwords, Autofill data, and other

For more information about what's stored in both modes, visit the Chrome Privacy Policy.

On the machine your data is separated across the two sessions but there are ways for websites, employers and ISPs to track you.

As the Google document says:

  Important: Neither Incognito mode nor Guest mode makes you invisible on the web. Websites you visit, your employer, or your service provider can still see your browsing activity.

If there is any "super cookie" that a carrier employs or tracking software based on browser fingerprinting (see  panopticlick or amiunique for more details) then you can still be tracked.


Hiding HMAC-SHA256 in source code and configuration file

Based on your description you essentially split the secret into multiple pieces and place these in different locations. And these parts are complex enough so that an attacker needs to find all pieces to succeed, i.e. it is not possible to find only some parts and then guess the remaining secret.

If in this scenario at least one of these location is protected with the same strength as you would traditionally protect the full secret then this split-secret system is not less secure compared to the traditional full-secret system and it might be even more secure. If instead you think that just by splitting the keys the system gets more secure and care less about securing each piece than you would have cared for the full secret then the split-key system might actually be less secure.

From your description it is impossible to know how well the parts of the secrets are protected. Source code might be stolen depending on how well protected it is or the code might be reverse engineered depending on how much effort was taken to obfuscate the secret in the code. Similar a configuration file might be easily accessible or not. It is also not known how critical the secret actually is and how much protection it needs. For example in some use cases it makes more sense to change the secret often than to invest too much effort into the long-term protection of the secret. And a secret which depends in part on the source code might be less flexible in such cases.


A "good enough" digital signature, with short key

No scheme like this one will prevent a determined attacker from activating the "debug feature", by the simple expedient of reverse engineering the code to locate the part which, in the software code, will look like:

if (is_good_password(password)) {
    activate_debug();
}

and turn it into:

if (true) {
    activate_debug();
}

which is usually only a matter of turning a conditional jump into an unconditional jump, or an unconditional non-jump (i.e. a nop opcode). It is not even hard to do, even in big pieces of software (e.g. I did it once for Windows 2000, to allow for testing a custom CSP -- CSP must be signed, and the Microsoft-provided solution for deactivating the signature verification on development platforms was good only up to Win2k SP2, or WinXP, while I had a Win2k SP4; so I had to hack into the advapi32.dll, which took me 3 hours).

That being said, if you just want to verify a password, the easy way is to store in your software a password-verification token, i.e. a hash value computed over the password. No need to bring the whole paraphernalia of digital signatures ! Just a simple hash, and this can accommodate passwords of any length. The software embeds the hash value; when the "debug" URL is entered, it hashes the part after the "debug/" and sees if it matches the recorded hash value. Thus, the password does not appear in the software code itself (neither in cleartext, or merely "scrambled"), and you can use a "password" short enough to be typed.

Digital signatures are any good here only if you have an unbounded number of "Debbies", and you want to be able to give a "debug password" to each Debbie, so that each Debbie has her own password distinct from the passwords given to the other Debbies, and you want to make it impossible for an evil Debbie, regardless of how much reverse engineering she does, to recompute the other passwords from the one she already has (if you have only, say, 20 Debbies, you can just include 20 hash values in your code; by "unbounded" I mean "potentially millions"). This is a pretty specific scenario. An example is "product keys" -- digital signatures could theoretically thwart product-key-generators. Nevertheless, the strongest digital signature will do no better than a password hash against an attacker who does a few hours of reverse engineering on the code to locate the right conditional jump opcode. The signature would not protect against illicit access to the debug code; it protects only against extending an illicit access to an industrial scale, giving it to many other customers without requiring a local modification of the code -- a so-called "hack".

For the hash function, if in doubt, use SHA-256 -- if (and only if) the "password" is long and random enough (say 128 random bits). If the Debbie is allowed to choose a "meaningful" password (one that a human being will be able to remember, as opposed to have it written down on a piece of paper), then you should use a hash function which resists dictionary attacks, e.g. PBKDF2 or bcrypt.

Do not use the "encrypt with the private key" way of describing a signature; it is a terrible explanation, which does not work for all signature algorithms. It is just an historical way with which RSA was first presented, but even for RSA it is wrong: it does not take padding into account, and padding is essential for security (see PKCS#1). Just forget it. There is nothing wrong in "using the private key to sign some data" and "using the public key to verify some data".


Does using a token and a pin for logging into a corporate internal system removes the need for using regular user names and passwords?

In practice 2-factor auth means 2 of the following

Something you are
Something you know
Something you have

In this case he is replacing username and password which are both in the "Something you know" category for a token code and a badge which both fall under the "Something you have". So there is negligible augmentation in the way authentication is happening on that computer.

Hope this helps.


Can a URL that has no links to it be discovered?

If you are asking whether "URLs can be discovered somehow", then the answer is definitely yes. For more information, you can check the links provided by Steffen Ullrich in a comment to your question. Full URLs can be leaked in several ways: they are probably recorded in server logs, they can be sent as a referrer whenever the page loads an asset (image, javascript, external fonts, etc.), they might be recorded by your ISP (unless you always use HTTPS, in that case only the domain can be seen), they can be recorded by malware in case you get infected (infected on your computer or on the website itself), they can be leaked in a lot of different ways by mistake (copy-paste fail, or thinking you are going to browse to a URL and instead the browser/application searches for it sending it as a query, etc.).

And as you said, they can also be recorded by any software you use, often unexpectedly. Your email client might be processing all the content of your emails automatically, for several purposes which might include commercial purposes, and they might be parsing and recording all URLs in the content, for example. The same is true for other (often privacy-invading) software, from a simple text editor to a whole OS. And don't forget the antivirus: it might be trying to record all the URLs it can, to scan them and block them if they are known to be malicious. And all this could be done by your browser too, of course.

As for Google Chrome, does it know what URLs you visit? The answer seems to be yes, but maybe not always and maybe only if you have certain features turned on (which might be on by default anyway): check out for example its privacy policy at https://www.google.com/chrome/privacy/ . Quoting some parts:

  When you can’t connect to a web page, you can get suggestions for alternative pages similar to the one you're trying to reach. In order to offer you suggestions, Chrome sends Google the URL of the page you're trying to reach.
  [...]
  In general, usage statistics do not include web page URLs or personal information, but, if you are signed in to Chrome and syncing your browsing history in your Google Account without a Sync passphrase, then Chrome usage statistics include information about the web pages you visit and your usage of them.
  [...]
  Crash reports contain system information at the time of the crash, and may contain web page URLs or personal information, depending on what was happening at the time the crash report was triggered.
  [...]
  Some versions of Chrome feature Safe Browsing technology that can identify potentially harmful sites and potentially dangerous file types not already known by Google. The full URL of the site or potentially dangerous file might also be sent to Google to help determine whether the site or file is harmful.

This of course does not mean that the URL will certainly be crawled and then included in search results. However you can never be sure of what Google (or other similar companies) is doing with your data, what they plan to do, and what they will do tomorrow. It's a company, with its software and services, with settings/goals/policies that can change very quickly any day.


How secure is a serial/terminal/console server, from the serial side?

Realistically?  They can (possibly) DoS the OOB management link, and possibly the whole OOB management system, and that's probably about it.  However, you have the exact same issue for any console connection to a compromised system.

This assumes you're just using the serial link as a serial console (so no SLIP, PPP, or X.25 over it, all of which would potentially open you up to regular networking vulnerabilities), and that all your hardware is good and doesn't have bugs (if you've got questionable hardware, then you may be talking about destroying hardware if the attacker gets sufficiently low-level access to the infected system).


What is the risk of unlimited email event triggering?

Using the feature for "sending annoying emails to people who didn't ask for it" is indeed a real risk, as you point out. You could e.g. use this on a competitor in the hope that the random recievers will start marking the mail as spam, so that spam filters will catch on and start blocking your competitors emails. But let's leave that to the side and focus on the resource aspect.

If you want to exhaust resources, you should focus on the functionality that does most of the heavy lifting. Sending an email is not hard work. Other things, like login (computing hashes), advanced searches or generating large amount of data that can not be cashed are. An attacker is more likely to start there, and move down to less resource intensive tasks only when those are blocked. Sending an email should be very, very low down on the list.

The only situation I could think of is if your hosting provider has some rules against how many emails a month you can send (shared hosting often has lots of limitations of all sorts).

(This answer has focused on the server side. I am not sure what you mean by "client side" in this case.)


TunnelBear VPN Chrome extension doesn't encrypt DNS Queries

I have found the answer after speaking with TunnelBear support and got their confirmation.

Indeed, domain queries were going out unencrypted which is why I could see them in Wireshark when using the TunnelBear browser extension alone.

It's because the extension sandbox in Google Chrome doesn't allow them to override DNS resolutions. But they have a workaround, which is to install the full version of their VPN program.

Here was their response:

  Hey Wadih,

  Sorry if I wasn't clear in my explanation. I talked to our engineers a
  little more and they've clarified this for me further.

  It doesn't (and can't) encrypt DNS requests made by Chrome browser
  itself because whatever Chrome does is outside of the our extension's
  sandbox.

  if you are concerned about all traffic and all DNS requests being
  encrypted, you should be using the full desktop app
  (tunnelbear.com/download). When using the full  VPN application, you
  should compare your WireShark results, at which point you should be
  seeing ALL DNS queries as being encrypted.

  I hope this helps clarify expected behaviour a little further.

  4-3-2-1 Tunnel!


In SSL server handshake, does server also send CA certificate

The server does not send any certificate in the ServerHello message; it sends certificates in the aptly-named Certificate message.

As indicated in the standard, the server is supposed to send a complete, ordered chain of certificate, starting with the server's certificate proper, then a certificate for the intermediate CA that issued it, then a certificate for the intermediate CA that issued the previous intermediate CA certificate, and so on. At the end of the chain, the server has the option to include or not include the root CA certificate; if the chain is to be of any use to the client, then the client must already know the root, and thus does not need a new copy of it. The relevant text in the standard is:

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

which is clear enough.

Note that, in all generality, the certificate chain is not unique. A given server certificate could be amenable to validation through several, possibly many certificate chains. This naturally happens upon intermediate CA certificate renewal (because there will be a time when the new CA certificate is valid and the old one is still valid, so if they use the same key then they will be interchangeable). In the case of cross-certification between distinct CA, the several chains for a given server certificate may even lead to distinct root CA. The consequence is that while the SSL/TLS server is supposed to send a "valid chain", that chain may not necessarily be the one that the client would have preferred.

In general, SSL/TLS clients will try to validate the server certificate chain as received from the server. If that chain does not please the client, then the client's behaviour depends on the implementation: some clients simply give up; others (especially Windows/Internet Explorer) will try to build another chain using locally known intermediate CA and also downloading certificates from URL found in other certificates (the "authority information access" extension).


Non-software individual password management solutions

Knowing and memorizing a credential pair for computer access is just a fact of life.

Same thing applies to the "real world". Imagine if all the owners of a Honda vehicle could just put their keys in any Honda and drive off. Wouldn't be a very good system would it?

Things you may want to look at:

Something you have, a Smart Card/Token
Something you are, biometics
Somewhere you are, an assigned work station behind a keyed/locked door
Single Sign On (SSO), seen with larger corporations or universities

Unless you intend to access public websites, smart cards are a perfect solution for an intranet.

This requires users to remember a PIN, but could store a single certificate or many for various logins. A numeric PIN is much easier to remember, and certificates are much stronger than a simple password.

Sharing credentials is uncommon, but seen in some corporations with temporary workers, sharing a crediential pair for use on a single system is acceptable. The reason for this is because they work on alternate work days, you can track who was in that day, and only 2 users are aware of the credentials. This is done on a system-by-system basis to simplify management.

As for writing passwords down and such, this is perfectly acceptable if you are unconcerned about a local attacker. Many are probably aware of their elderly family member(s) doing this. The concern is minimal because it's much more likely someone to attack their accounts from the web than locally in person.

Doing this in a corporation/enterprise however, under PCI compliance or HIPAA is likely to land you in some legal troubles or voided agreements at the minimum.

The other issue arises is that writing down credentials changes the game. Authentication, having a user prove their identity, no longer exists as anyone could walk up and enter the credentials. By having a written credentials turns things into authorization, proving a right to a resource.

Single Sign On allows the user to enter their credentials once, and access many other resources by sharing a secure token to said resources. This is not common in smaller enterprises due the shear work involved in setup/maintenance.


If I understand your question correctly you are basically asking if the WAF will handle the redirect send by the backend locally by issuing a new request to the backend, or if the WAF
will pass the redirect through to the original client.

While there is no single type of WAF I would expect the WAF to pass the redirect to the client since it might otherwise break functionality. Such redirects are often used to store some state in the client, like a cookie or in case of a permanent redirect the preference to use HTTPS instead of HTTP or to use a different domain or to use a client-specific path. Since is important that the client keeps this (often client-specific) state the redirect needs to be passed through to the client.


Everything is fine now

no. some 3rd party had write-access to your server and you dont know what mailicous stuff is left behind.

  Can anyone help?

yes, get a professional to help you, this is serious since you are putting your users at risk.


If I use a good Master Password in Firefox, is security improved when I Remember Passwords instead of re-type?

You have been very thorough in considering downsides and benefits.

Using master password in Firefox or other browser is usually acceptable compromise. Nevertheless, there is no care free approach for dealing with passwords. (Convenience vs. security.)

Earlier question How secure are my passwords in the hands of Firefox using a Master Password? gives some guidance it says: most likely secure, but I would not use.

My advice is opposite: if you cannot remember a lot of hard to remember passwords or passphrases, using browser to remember (and in some cases generate) your passwords can be a good compromise.

As far as banking goes: many banks use two factor authentication (such as ID, password + number from single use password list). I don't use banks/brokers/etc. which allow using them with just ID+password, as such authentication info get leaked too easily.

Anyway, if there are high security passwords, I would memorize them in my head.

Key logger

In case of key logger, master password does not fully protect against them, because key logger will then record master pass.

Passwords in your head

If you can remember unique password for each site you use, each password having very large amount of entropy, it is better than remembered passwords (except against key logger).

However, in practice, there is so many site passwords that it is almost impossible to pick very good passwords for each one of them.

Using key store

Key store allows you to use master password to store a lot of passwords. Instead of many good passwords, you need only one good password. This password is supposedly easier to remember as it is often needed. Because of less passwords to remember people afford to use more complex password as master password.

Synchronized passwords

Some applications like Firefox (and Safari and so on) allow you to synchronize your passwords between your devices. Such service is very convenient.
Because the synchronization often goes through quite a few servers, all those who can see the traffic may try recovering your passwords. At least the parties who are able to break your master pass most likely get access to all your passwords.


Is it secure to get auth TOKEN from server with javascript?

your question title is different to the question in your post.

is it secure to get the token via JavaScript from the server - this depends on the server side validation method in place. assuming these are OK

manipulating the token in JavaScript and then sending to a web socket should be fine as long as server side validation is good.


How and what information does TRIM reveal when using encrypted Veracrypt volumes?

Answers to the comments:

first of all some real life example that helps to clarify how both works
Think the hard disk (not ssd) as something like this:
https://www.zerorelativo.it/item_files/5/9/2/4/3/item_434295.jpg
https://i.pinimg.com/736x/19/0c/a1/190ca1d14a5eb7c52a762326042996dd.jpg
where the pieces of wood (bits) can be rotated front(1) or back(0).
there is no third state that we can call "deleted/empty".
you can edit that data in place, just by rotating the pieces of wood

ssd are differnet:
think them like a school blackboard, or a piece of paper, you can write it only once, you can't overwrite in place a piece of paper. to do that you have to use a rubber to delete the old data and only after this operation you can write on paper again.
On a pice of paper (or ssd) there can be 0,1 (data) or can be empty (three different states).
an empty/deleted block/sector can be written, once the operation is done you can't edit that data anymore.

  empty state? Is it specific to a block of storage

  Why would some parts be explicitly marked empty?

i was referring to sectors, not the whole drive.
let's take a real example (https://nesos-ita.github.io/hacks/fixing-bricked-pc/), i have programmed a spi flash memory (bios chip):
-the smallest programmable(=writable) data is "page" where a page size is 256 bytes
-smallest eresable part is a sector, where sector size is 4kb (larger than a page, 16 pages exactly)

if i want to edit one byte of that chip i have to:
1- read 4kb of data=16 pages (1 sector) (16 read page operations)
2- delete that sector (4kb) (1 erease sector operation)
3- reprogram 16 pages where 15 will contain the old data and one differs from one byte (the edited one) (16 page program operations)
total operations count: 16+1+16 not the best...
but what if that chip part was empty?
i could skip step one and two saving 17 operations and i could be faster!
note that even if there was 4kb of useless data i could skip read part but i must delete 4kb of data to wrtite a byte (actually a page of 256 bytes)
there is no "edit operation".
if when you delete a file the actual data is deleted in that moment is better, because when i will need to write on that disk part the disk will be in "deleted/empty" state and i will only write my data on it. it's faster!
this is what trim does, it deletes data when you delete a file, the scope of this is speed
this doesn't happens on hdd because hdd are faster if you don't delete data as explained if you keep reading:

  Can you please clarify how would one determine if the drive has been securely wiped?

as we saw, hdd works like the photo above, since data can be only one or zero you can't wipe them, it's not like a piece of paper that if you watch it you can say is written or it's empty.
the approximation of a delete operation can be writing all 0.
1010101111100010110101010 <-- this is probably data
0000000000000000000000000 <-- this is probably empty (but this is still data, it's only a logic concept of empty, the disk is full of zero)

as always people want pc (and hdd) to be fast so in both hdd and ssd we want them as fast as possible. the goal is reached in two different ways with the two different technologies:
before continuing we need some concepts:
How a filesystem works (logic level, not hdd level)? how files are stored?
there is an index of files where there is a name, and a location
exactly like in a text book
how a file was deleted in past (hdd)?
it was removed from the index by overwriting it's index with 0
there was no point in deleting the actual content of the file, after deleting the index the physical file location is automagically free (since is no more in the index of used data)
it would be a big waste of time overwriting the whole file data with 0000000
and in fact it doesn't happens. in this way the hdd is faster:
- cut & paste operations are fast (you edit only the index)
- delete is fast (you edit only the index)
- copy & paste is slow (you have to actually copy data)
the "problem" is that you can restore deleted data if hasn't been overwritten by some new file, but this historically wasn't a problem, the hdd was faster in this way and everyone was happy.

Now the actual answer is near :)
Now that we have the concepts and we know why securely erease data might be necessary we can asnwer how to do it:
An appoximation of "deleting data" can be:
-writing all zero (or all one)
-writing random data
in both way the old data is gone but with all 0 or all 1 and reading the hdd as analog vlaues and not digital you might still recover data (more a theoric attack, needs lab, can't be done with sw), for example:
we know that the disk is magnetic, let's say that logic 1 is "magnetized" and 0 is "not magnetized" if we have a magnetic vlaue sensor that read from 0% to 100% magnetic value; we can say that 60-100% means logic one and 0-40% means logic zero.
supposing that you write from 1 to 0 the magnetic value will go from 97% to 15%
supposing that you write from 0 to 0 the magnetic value will go from 13% to 2%
thus if you read the hdd as analog values you might find out if a 0 was a 0 or if it was a 1 (more or less like reading rubber-ereased piece of paper, old data might be still visible).
a better way to delete data is writing garbage/random data (maybe more than one time) on the whole hdd, in this way the above trick doesn't work anymore.

and here is the actual answer!!
given that writing random data is the best way to wipe a disk if you find a disk that is full of random data you can say "this has been securely ereased!"
but given that a good cipher will look as random data you might also say "this is an encrypted drive"
you can't tell if it's encrypted or if it's securely ereased, but you can be sure that one of these two operations have been applied on that hdd/ssd.

  If some are marked empty, how would someone determine the disk is encrypted and not secure erased?

  Isn't the statement "with trim enabled attackers can know for sure:-that your disk is encrypted (but not read the content)" true for external hard drives as well regardless of trim?

i think i implicitly answered the question above but let's clarify it:
encrypted disk=full disk looks like random data, because good cipher without having password, looks like random data
securely ereased=fill with random data the whole disk!
now, if you use the encrypted ssd disk, and delete a file, the sector is marked as deleted/free/empty (by trim operation, on ssd only, for future write speed reasons).  If i see a deleted sector it means that it's encrypted, the fact that a sector is empty it's a proof that you have deleted a file and you are using that disk, you can't use a disk full of random data/ereased, but you can use an encrypted disk!
this would not happen on hdd, as they don't have trim operation and they don't delete data, it's just left there
also note that even if the file index is "deleted" by writing all 0 on the index veracrypt will intercept that write operation end encrypt that all zero so on the disk you wll see something different (random data again).

  What do you mean by it is in fact 0 or 1? How does changing state constitute undefined data? What is undefined data?

Let's take again real life example, the spi flash bios chip that i have written:
as you know computers works with binary data that can be 1 or 0
as i explained above flash memory must be deleted before writing, well i have tried to read a deleted sector and it returned:0xFF, 0xFF, 0xFF, ... that converted in binary means that it was full of 111111111111...
as you can see the deleted state is not a magic third state but practically it's all one.
but note that this particular model of memory has the deleted state=all one, another model might be electrically wired differently and have the deleted state=all 0.  thus we can say that after a delete operation the data is "undefined".
but it's not a magic different state, it's just a way to say that there is meaningless data inside it.

  My understanding is the TRIM command is subject to the SSD drive controller's internal routines e.g. garbage collection and it may never delete data since data can be stored across multiple blocks

The fact that data might never be deleted or might be stored in multiple locations it's a different thing, it's called wear leveling and the scope is different: increase life
suppose that you store a photo, that photo will never change so that flash cell will be written only once and never again.
now take a log, for example windows update log: it will be written every time you boot the pc with things like "today no updates", "updated to xyz", "failed to update"
so that cell will be written over and over...
since the number of write operations is limited you will have a broken cell and a new one, not the best...
the idea? move the data! swap every x days the windows update log flash memory cell and photo cell and you automagically doubled the life of your ssd.
combine this with multiple cell and you will have an ssd that degradate slower and in a more uniform way.
this is helped by the trim operation, swapping as i said above is expensive as you have to read the photo and the log, keep both in memory, delete both form disk and write both in inverse locations.  if you have a free/deleted part you can just write a copy there and delete or ignore the original one.
there is another used trick: i have a 1gb usb flash memory that has inside a 2gb flash chip.

  With "they could undelete data if they have an old copy where the data was there", is this only possible if the drive was not encrypted before?

No, also if encrypted, suppose that:
1 i get a copy of your encrypted disk
2 you delete a file
3 i get another copy where i see that a sector is deleted (i can notice this because it's an ssd and trim phisically delete data with a delete opreation)
4 having the old data from old copy (point 1) i can write it exactly where it was before and maybe your file will be undeleted when you boot the pc.
maybe it's important because filesystem it's a complex structure, what's is sure is that if i replace your disk with my old copy you will bot old copy, i can also edit any sector i want, but when decrypted will be garbage and probably crash something.
a more important thing to remember is that changing password doesn't change master key, so if:
1- i get a copy of the disk (encrypted)
2- you find that i got a copy and change the password
3- you tell me: ahah i found out you got my disk, i changed my password to a more complex one, the old one was "secret password123"
4- you write some other data on disk
5- i get an encrypted copy of your disk, i can decrypt EVERY copy of the disk, even after you changed the password!!


Why isn’t Secure Boot protecting against ransomware like PETYA

Secure Boot prevents the computer from booting if the bootloader (stored in the MBR, on MBR disks) or other boot-time code is tampered with. It doesn't actually prevent such tampering itself. The purpose of Secure Boot is to prevent malicious boot code from compromising your computer invisibly - think spyware that records your keystrokes and files - not to protect you from malware that tries to deny you access to your computer.

In InfoSec terms, Secure Boot provides integrity - you know if something has been tampered with - and can also provide authentication (if you only trust one signing key, you can be pretty sure that if your computer boots its boot image was signed by that key). It does not provide availability (protection against denial-of-service attacks, which is basically what ransomware is) or authorization (access control checks that control what software is allowed to do) except in the sense that it prevents the machine from booting if the boot image is tampered with.

You can usually block writes to the MBR from the firmware (BIOS or (U)EFI).


Is it safe to make every resource public in a Google Cloud Storage bucket?

Your security is based upon an attacker not knowing the GUID of your files.  Let's evaluate how "secure" that is:

Bruteforce is an option (although for a GUID, it is probably not very realistic)
Anyone with access to the app can easily see the full URL and share it.  If someone using the app took a URL for a sensitive image and, for instance, posted it on Facebook, you would have no way of stopping them from sharing it like that.
If the bucket itself is also public then anyone who knows the bucket name (that isn't the real bucket name in your question, is it?) can ask google to simply list the bucket contents, and GCP will happily give away every single filename.

Is there a security risk here?  I would say there absolutely is.  Are these security risks deal breakers for you and your system?  Only you can answer that.
The other-other solution would be to use signed URLs, which effectively generate a temporary and short lived URL that the end-client can use to download specific objects from the bucket even while it is private.  This way you can make your bucket and objects private while still allowing authorized users to download objects without having to pass them through your own server.  Building a signed URL doesn't require any API calls to GCP, so it rarely creates issues with performance/response times.


You are confusing many terms here. Perhaps I can help.

Code signing is the process of cryptographically signing a file so that a user of the file can tell who signed the file and whether it has been modified since signing. It generally doesn't make the file unreadable, though, depending on how the signature is attached to the file, you may need a special tool to examine it. It has no effect on the source code or reverse engineering. Windows has a code signing process called Authenticode that is well documented. You may wish to read about it for general background information.
Obfuscatation attempts to make the executable code more difficult to read. This is generally reserved for translated languages like JavaScript and byte-code compiled languages like Java and C#/.NET because it is much easier to view the source of these programs. Obfuscation is unrelated to code signing. You need to search for obfuscation systems for your specific platform (eg: .NET).
Nothing will make your assembly code unreadable. After all, the CPU needs to read it to execute your program so it must be readable. That said, obfuscation techniques can make it more difficult to read, though optimized assembler code is already pretty difficult to reverse engineer.

I think that you need to do some more research at this point and come back when you have a better understanding of the basics.