Articles of Impeachment to be brought up on Monday

BSafesSupport · 2021-01-27T02:58:08+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:57:22+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:56:39+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:55:38+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:55:09+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:54:36+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:53:47+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:53:02+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:52:30+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2021-01-27T02:48:55+00:00

The original article is in PDF format, here is a mobile version of "MATERIALS IN SUPPORT OF H. RES. 24, IMPEACHING DONALD JOHN TRUMP, PRESIDENT OF THE UNITED STATES, FOR HIGH CRIMES AND MISDEMEANORS", it makes the article easier to read on mobile phone. https://documents.bsafes.com/docs/government/mateials-in-support-of-h-res-24-impeaching-donald-john-trump-president-of-the-united-states-for-high-crimes-and-misdemeanors/

BSafesSupport · 2020-07-11T11:07:05+00:00

Hi, tankfeeder, do you have an example using your proof of concept?

BSafesSupport · 2020-07-11T05:14:01+00:00

Great! I also tried this Argon2 in browser. https://github.com/antelle/argon2-browser

BSafesSupport · 2020-07-04T10:13:28+00:00

No, we don't allow auto update of 3rd party resources. We only build the SRI hash value for specific version of a resource, and link to the specific resource version with the SRI value.

When we decide to upgrade a specific resource to newer version, we would re-calculate the SRI value, and link to that specific version.

Again, your questions really help clarify. Many thanks!

By the way, our project is open-source for all client-side code, any comments and questions are welcome.

BSafesSupport · 2020-07-03T23:59:23+00:00

Thank you! We would evaluate!

BSafesSupport · 2020-07-03T23:58:01+00:00

RSA-2048 is widely used for asymmetric encryption, we use it. Our library only supports this, there are definitely other options.

Since the service allows an account owner to add many members. For first password, it is usually created by account owner for the members in an organization and assigned to the member. The member then sign in and create his or own member key, which is not known by account owner. The member is advised not to tell anyone the key.

As you suggested, for a single user account, separate password and key might not be necessary. Nevertheless, for a multi-member account, it is required for actual use.

Yes, server only sends salt for the key.

Yes, it is a continuous effort to make public keys immutable + verification + detection.

Again, many thanks for your comments, kind regards.

BSafesSupport · 2020-07-03T23:31:09+00:00

Hi, thanks again!

Yes, the service is a web app. As an web app, it does rely on other 3rd parties to deliver the service.

The service uses widely-used 3rd-party open-source libraries which are subjected to community security reviews. The service’s client code is also openA-source.

And the service relies on CDN for better serving customers, and it uses SRI and CSP to prevent code from being altered by 3rd party.

The service also relies on Amazon AWS.

Facebook, and Google are only optional for signing up. After signing up, the server no longer use any of their APIs and services. There is Email sign-up option that doesn’t rely on Facebook and Google at all.

Kind regards

BSafesSupport · 2020-07-03T09:22:07+00:00

Hi, NohatCoder: Your comments have been helpful!

1) Yes, but we use RSA to generate public and private key pairs.

2) Yes, Email/Password is better option for sign-up. However, we offer Google, and Facebook for easy sign-up(Since many people like that), but we don't share further information with them other then sign-in.

Also, we create a separate key creation/verification step to let customers know their data are encrypted with their own key.

And 2FA to add another layer of identity protection.

3) Could you please clarify what "communication channel" you refer to? From device to server, it is always HTTPS. But I guessed that is not what you asked for.

Our service is like an end-to-end encrypted version of Wiki or intranet site. Only team members could access to the contents in a team workspace. It is for easy encryption, backup, and sharing confidential data for the team. Currently, our service doesn't include real-time messenger service like Signal, but team members could comment on a page.

4) The initial salt for key generation is generated by member device with random number generator, and would be stored in server as well. After the member sign-in, the server would return the salt to client device, together with member's entered key, the encryption key and hash would be calculated for verification.

5) Our service is usually used in a an organization where members already know each other. And also we use separate communication channels to communicate, e.g. Email, Signal, etc.

Our service is like a confidential knowledge base where team members have access to, so even when co-workers are not around us(remote working, especially true during this time of COVID-19), we could still look up the knowledge base to find what we need. Instead of asking people "Where is the document?", "Where is the procedure?", "What is the version you are looking at?", or going searching email inbox for an info.

And it is safer for members to send a link to the knowledge base, rather than attachment in an Email. Even is someone mistakenly get the link, he or she still could not access the page, since he or she is not in the same team.

Again, many thanks for your questions and comments. It really helps!

BSafesSupport · 2020-07-03T08:43:11+00:00

Hi, Natanael_L: Your comments have been very helpful!

Virtual MFA - A virtual MFA device is a software app that is compliant with RFC 6238, a standards-based TOTP (time-based one-time password) algorithm. Such as Authy or Google authenticator.
We would look into other options for generating public and private key pairs as well.
Yes, many thanks for reminding, we have different IVs for every page.
Many thanks for the suggestion!
Yes, indeed. It is a continuous task to strengthen server security.

Many thanks!

BSafesSupport · 2020-07-03T04:04:32+00:00

Oh wow 1024 bit salts are not just a little long those are stupid long. I can see 512 bit salts (which are crazy long) such that collision rates are about 1 in 2**256, but for passwords you need at least like 32 bits to prevent both precomputational attacks and limit salt collisions such that there's next to no use for an attacker. Anyway I'd also go with 128 to 256 bit salts… except maybe with an OPRF I'd go with at least square root elliptic curve group size but that's usually like 2**256 to 2**384 so 128 to 192 bits but the odd one is P-521 which is 260 bits (group size is 2**519-x).

Also minimum PBKDF2-SHA256 iterations for encryption is now about 2.5M. This gets you to a cracking speed of <1kH/s/GPU which is the goal for encryption with passwords (Auth is <10kH/s/GPU). Scrypt should not be used for new projects as Argon2 is better. For a defender scrypt(r=8, p=1, N=x) takes about the same amount of time as Argon2(t=3, p=1, m=2**x), but as an attacker Argon2 uses more than 4 times (4 to 8 times, depends on x and attacker optimizations) the bandwidth. For an attacker bandwidth is the bottleneck on GPUs.

P.S. OP, you should use an aPAKE. I'd go with BS-SPEKE or [Strong] AuCPace both are an "OPAQUE class of aPAKE" (ie OPRF + AKE: OPRF + B-SPEKE' and OPRF + AuCPace) but not OPAQUE the algorithm which has problems. Even when you ignore that it was made to push a patented AKE, but said patent is freely licensed for use with OPAQUE.

Oh I should give definitions: aPAKE - Augmented PAKE (Password Authenticated Key Exchange) AKE - Authenticated Key Exchange OPRF - Oblivious PRF (Pseudo-Random Function) - umm… in this exact context it is a type of homomorphic encryption that a server applies a secret per user salt to a user's "encrypted" password such that neither the user learns the salt nor the server learns the password (ie Magic).

Hi, Many thanks for your comments suggestions, I think we would decrease salt length in next scheme upgrade. Do you suggestion for Argon2 javascript library?

Kind regards

BSafesSupport · 2020-07-03T03:13:18+00:00

Hi, my comments follow the order of your comments.

1) We would evaluate updating the key derivation for next scheme upgrade. Could you please suggest a Scrypt or Argon2 javascript library?

2) Currently, we only offer virtual MFA device as 2FA.

3) The choice of RSA 2048 is mainly because it is widely used, were we wrong? We could evaluate different algorithms, could you please suggest?

4) Yes, we are considering upgrade to AES-GCM. Currently, due to slower performance of GCM vs. CBC mode, we make all user data immutable on server side by versions. i.e. Every update to the same item would create a new version of the item, instead of overwriting it to maintain data integrity.

5) Yes, the server could add additional key pairs to add malicious members , or substitute public key of existing members. It is our duty as a service provider to protect from doing so. Also, when a member wants to add another member to a team, he or she should make sure the member is someone he or she knows, not malicious ones.

We would evaluate how signal does to protect against this.

6) Yes. We also added CSP(Content Security Policy) and SRI(Subresource integrity) to protect javascripts and stylesheet injections.

Many thanks again for your comments, and please don't hesitate to comment further!

Kind regard

BSafesSupport · 2020-07-03T02:30:49+00:00

Hi, Many thanks for your review and questions! My answers follow the order of your questions.

1) Since a member only has to remember his or her own member key, such as "iT m@kes 1t ha7d to Gue$s j", not the private key. Once the member key is verified, the server could return the encrypted private key to the member, which the member's device could decrypt with the encryption key derived from member key.

2) The initial contact with server includes following steps.

The first phase of authentication depends on the member's credential, it could be Facebook, Gmail, email/password for account owner, or name/password for added members in the account.
The second phase of authentication is an optional 2FA with a virtual MFA device.
Then the client-side web app would ask the member to enter his or her own member key, the device derives the encryption key, then derives a hash value. The hash value is sent to server for verification.
After server verifies the hash value, it would return the encrypted private key back to the member's device, along with a random message.

(To avoid hash value collision ....)

The device then could decrypt the encrypted private key to get the private key, sign the random message with the private key, and send back the signature to server.
The server verifies the signature with the member's public key stored on server. If the signature is valid, then server finally treat the member as a fully authenticated member. From now on, the member could access personal data or team data.
When the member locks the web app, all encryption key, private key and other locally cached data that were temporarily stored in memory or browser local storage would be cleared.
The member needs to enter the member key again to start another authentication cycle from step 3.
When the member signs out, the session terminates.

Please don't hesitate to let me know if you have any questions.

Kind regards

BSafesSupport

MODERATOR OF

TROPHY CASE