# Weekly Update 0

**URL:** <https://discourse.joplinapp.org/t/weekly-update-0/38297>\
**Category:** Native Encryption\
**Tags:** report\
**Created:** [26 May 2024 12:15 UTC](https://discourse.joplinapp.org/t/weekly-update-0/38297 "2024-05-26T12:15:23Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![wh201906](https://yyz2.discourse-cdn.com/flex028/user_avatar/discourse.joplinapp.org/wh201906/32/14835_2.png) [@wh201906](https://discourse.joplinapp.org/u/wh201906)\
**Post date:** [26 May 2024 12:15 UTC](https://discourse.joplinapp.org/t/weekly-update-0/38297/1 "2024-05-26T12:15:23Z")

</div>

This report covers the progress during the Community Bounding Period ([May 1 - 26](https://developers.google.cn/open-source/gsoc/timeline#may_1_-_26)), plans for the first week of coding period (starting from [May 27](https://developers.google.cn/open-source/gsoc/timeline#may_27)), and the problems I met.

## Progress

- Got familiar with `sjcl` library.
- Implemented some test demos of the `AES-CCM` method in `sjcl` and `node:crypto`. Proved the possibility of [Goal #2](https://discourse.joplinapp.org/t/introduction-of-this-project/38296) on the desktop.
- Checked the supported `transformation` of the `Cipher` class in `javax.crpyto` across various Android SDK versions ([test result](https://discourse.joplinapp.org/t/test-for-the-supported-modes-in-javax-crypto/38319)). Proved the unfeasibility of [Goal #2](https://discourse.joplinapp.org/t/introduction-of-this-project/38296) with `javax.crypto` on Android.
- Attempted to set up the macOS virtual machine.
- Attempted to connect to the macOS virtual machine provided by @tessus .

## Plans

- Evaluate the React Native crypto libraries
- Try to set up a valid macOS development environment
- Try the `AES-GCM` method with `javax.crypto`

## Problems

- In the project proposal, I planned to implement the `AES-CCM` method across all platforms so users can get a faster decryption speed when migrating the crypto method to the new one. I chose `javax.crypto` initially, but I found that it doesn't support `AES-CCM` on many Android SDKs. To resolve this, I might need to implement it with other libraries like `OpenSSL`. However, this task has a very low priority because the proof of concept of native decryption of `AES-CCM` with `node:crypto` is implemented. Users can use their PCs to speed up the migrate process.
- I don't have a macOS environment so I cannot write and test the native code on iOS. @tessus and I have tried some methods, but they didn't work. I'm still finding a way to set it up.

---

<div class="post-metadata">

**Author:** ![laurent](https://avatars.discourse-cdn.com/v4/letter/l/ce7236/32.png) [@laurent](https://discourse.joplinapp.org/u/laurent)\
**Post date:** [28 May 2024 13:24 UTC](https://discourse.joplinapp.org/t/weekly-update-0/38297/2 "2024-05-28T13:24:03Z")

</div>

> [@wh201906](#):
>
> I don't have a macOS environment so I cannot write and test the native code on iOS. @tessus and I have tried some methods, but they didn't work. I'm still finding a way to set it up.

Have you tried using VirtualBox? [How to Install MacOS on Windows 10 - gHacks Tech News](https://www.ghacks.net/2023/03/19/how-to-install-macos-on-windows-10-in-a-virtual-machine/)

Otherwise if you know how a good online service for this, we can probably pay for the subscription for a few months, just let us know which one.

---

<div class="post-metadata">

**Author:** ![wh201906](https://yyz2.discourse-cdn.com/flex028/user_avatar/discourse.joplinapp.org/wh201906/32/14835_2.png) [@wh201906](https://discourse.joplinapp.org/u/wh201906)\
**Post date:** [28 May 2024 14:36 UTC](https://discourse.joplinapp.org/t/weekly-update-0/38297/3 "2024-05-28T14:36:49Z")

</div>

I tried Virtualbox + macOS Ventura/Sonoma with various tutorials but I can't even install it. The official forum [doesn't allow users to talk about installing macOS on non-Apple hardware](https://forums.virtualbox.org/viewtopic.php?t=92649&sid=2554719139e30991830c9fd6e3c32cae) so I guess the feature of installing macOS VM on PC is unmaintained/not supported.

As for the online services, I need some time to evaluate which one to use.

---

<div class="post-metadata">

**Author:** ![wh201906](https://yyz2.discourse-cdn.com/flex028/user_avatar/discourse.joplinapp.org/wh201906/32/14835_2.png) [@wh201906](https://discourse.joplinapp.org/u/wh201906)\
**Post date:** [20 September 2024 08:58 UTC](https://discourse.joplinapp.org/t/weekly-update-0/38297/4 "2024-09-20T08:58:05Z")

</div>

On a side note, the `Electron` actually uses Chromium's `BoringSSL` instead of `OpenSSL` for the Node.js binary, so an `Electron` app supports fewer ciphers and hashes than the original Node.js.  
It seems `AES-CCM` is not supported in `Electron`, so I cannot achieve [Goal #2](https://discourse.joplinapp.org/t/introduction-of-this-project/38296) on desktop without 3rd-party libraries.

> **[Native Node Modules | Electron](https://www.electronjs.org/docs/latest/tutorial/using-native-node-modules)**
>
> Native Node.js modules are supported by Electron, but since Electron has a different application binary interface (ABI) from a given Node.js binary (due to differences such as using Chromium's BoringSSL instead of OpenSSL), the native modules you use...

> <https://github.com/electron/electron/issues/16195#issuecomment-450990183>
>
> \* Output of \`node\_modules/.bin/electron --version\`: 4.0.0
> \* Operating System (…Platform and Version): Windows 10
> \* Output of \`node\_modules/.bin/electron --version\` on last known working Electron version (if applicable): v3.x.x
> 
> \*\*Expected Behavior\*\*
> Generally , invoke \`\`crypto.createCipheriv ()\`\` that should return a Cipheriv Object.
> 
> \*\*Actual behavior\*\*
> When I call \`\`crypto.createCipheriv()\`\` , it will response me a error that is \*\*unknown cipher\*\* .
> But If I run this program(\*\*test code\*\* ) alone by node cmd. (ex. node test.js ) that it work.
> So I don't think it is a node10 problem.
> 
> \*\*To Reproduce\*\*
> \*\*sample code\*\* 
> in main.js
> \`\`\`
> const crypto = require('crypto')
> const methodName = 'aes-256-cfb'
> const key = 'nMvTdb7VXMPudFWH'
> const iv = crypto.randomBytes(16)
> const cipher = crypto.createCipheriv(methodName, key, iv)
> console.log(cipher)
> \`\`\`
> \*\*Response:\*\*
> in Electron 4 or more newer
> \`\`\`
> unknown cipher
> \`\`\`
> 
> in Electron 3.x , more older or run alone by node cmd
> \`\`\`
> Cipheriv {
> \_handle: {},
> \_decoder: null,
> \_options: undefined,
> writable: true,
> readable: true }  
> \`\`\`

> <https://github.com/electron/electron/issues/20204>
>
> Hi,
> in the latest source code it looks like electron\_node is built using bo…ringssl instead of openssl directly. I wanted to confirm if my understanding is correct ? 
> 
> I saw in this issue https://github.com/nodejs/node/issues/25890 there was some discussion about this.
> 
> looking at \`third\_party/electron\_node/BUILD.gn\` in the latest source suggests that boringSSL is what's used
> 
> \`\`\`
> if (node\_use\_openssl) {
> print("node\_use\_openssl in BUILD.gn")
> deps += \["//third\_party/boringssl" \]
> sources += \[
> "src/node\_crypto.cc",
> "src/node\_crypto.h",
> "src/node\_crypto\_bio.cc",
> "src/node\_crypto\_bio.h",
> "src/node\_crypto\_clienthello-inl.h",
> "src/node\_crypto\_clienthello.cc",
> "src/node\_crypto\_clienthello.h",
> "src/node\_crypto\_groups.h",
> "src/tls\_wrap.cc",
> "src/tls\_wrap.h",
> \]
> print("deps: ", deps)
> cflags\_cc += \["-Wno-sign-compare" \]
> }
> \`\`\`
> 
> printing our \`process.versions\` from an electron app still lists \`openssl: '1.1.0'\` but perhaps that is the version of openssl that is wrapped by boringSSL.

> <https://github.com/electron/electron/issues/23637>
>
> With the switch from OpenSSL to BoringSSL by Chrome a bunch of ciphers were lost…. In the main issue regarding this: https://github.com/electron/electron/issues/16195# it was suggested to open a new issue requesting other ciphers, so hereby was wondering whether there would be any way that Electron could support aes-128-ccm.
> 
> Justification for requesting this: Mostly that on IoT devices this is a very popular cipher as it's just more power efficient than alternatives. 
> 
> I don't really understand how BoringSSL relates to OpenSSL and I don't really understand if it's possible to even enable aes-128-ccm in BoringSSL, but I figured I would put the request out there regardless.
> 
> PS. This is to use node libraries that rely on \`crypto\` exposing this, so manually using a different solution isn't an option right now :(