starred/bark-server

Fork 0

mirror of https://github.com/Finb/bark-server.git synced 2026-04-26 22:25:53 +03:00

[GH-ISSUE #183] [Feature Request] 支持端到端加密 #89

New issue

Closed

opened 2026-03-03 11:55:59 +03:00 by kerem · 6 comments

kerem commented

2026-03-03 11:55:59 +03:00

Owner

Originally created by @hellodword on GitHub (Nov 17, 2022).
Original GitHub issue: https://github.com/Finb/bark-server/issues/183

非常感谢作者的 bark 应用，重度使用中。

我注意到在 https://github.com/Finb/Bark/issues/86 有过类似讨论，不过他没有详细阐述，也并非一定要非对称加密。

端到端加密可以极大程度地解决传输过程中的信任问题，从原本的信任 [客户端，服务器，传输过程（https），苹果服务器，手机]，变成了信任 [客户端，苹果服务器，手机]。

Apple - Decrypting data contained in a remote notification

Originally created by @hellodword on GitHub (Nov 17, 2022). Original GitHub issue: https://github.com/Finb/bark-server/issues/183 非常感谢作者的 bark 应用，重度使用中。我注意到在 https://github.com/Finb/Bark/issues/86 有过类似讨论，不过他没有详细阐述，也并非一定要非对称加密。端到端加密可以极大程度地解决传输过程中的信任问题，从原本的信任 `[客户端，服务器，传输过程（https），苹果服务器，手机]`，变成了信任 `[客户端，苹果服务器，手机]`。 --- - [Apple - Decrypting data contained in a remote notification](https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications)

kerem closed this issue

2026-03-03 11:55:59 +03:00

kerem commented

2026-03-03 11:55:59 +03:00

Author

Owner

@Finb commented on GitHub (Nov 17, 2022):

我最近正在尝试加上加密
第一种就是用户端自行加密发送的内容，服务端转发给app，app使用用户设置的秘钥解密
第二种对用户透明，服务端将数据加密后发送到app，app解密

目前倾向于实现第一种，因为没有兼容性问题。第二种无法判断接受用户的app版本是否支持加密

第一种的缺点就是发送端可能会复杂一点，类似

#!/usr/bin/env bash

set -e

# bark key
deviceKey='your key'
# push payload
json='{"body": "test"}'

# must be 16 bytes long
key='1234567890123456'
iv='1234567890123456'

# openssl requires Hex encoding of manual keys and IVs, not ASCII encoding. 
key=$(printf $key | xxd -ps -c 200)
iv=$(printf $iv | xxd -ps -c 200)

ciphertext=$(echo -n $json | openssl enc -aes-128-cbc -K $key -iv $iv | base64)
echo $ciphertext
# curl --data-urlencode "ciphertext=$ciphertext" https://api.day.app/$deviceKey

@Finb commented on GitHub (Nov 17, 2022): 我最近正在尝试加上加密第一种就是用户端自行加密发送的内容，服务端转发给app，app使用用户设置的秘钥解密第二种对用户透明，服务端将数据加密后发送到app，app解密目前倾向于实现第一种，因为没有兼容性问题。第二种无法判断接受用户的app版本是否支持加密第一种的缺点就是发送端可能会复杂一点，类似 ```shell #!/usr/bin/env bash set -e # bark key deviceKey='your key' # push payload json='{"body": "test"}' # must be 16 bytes long key='1234567890123456' iv='1234567890123456' # openssl requires Hex encoding of manual keys and IVs, not ASCII encoding. key=$(printf $key | xxd -ps -c 200) iv=$(printf $iv | xxd -ps -c 200) ciphertext=$(echo -n $json | openssl enc -aes-128-cbc -K $key -iv $iv | base64) echo $ciphertext # curl --data-urlencode "ciphertext=$ciphertext" https://api.day.app/$deviceKey ```

kerem commented

2026-03-03 11:56:00 +03:00

Author

Owner

@hellodword commented on GitHub (Nov 17, 2022):

我最近正在尝试加上加密
第一种就是用户端自行加密发送的内容，服务端转发给app，app使用用户设置的秘钥解密
第二种对用户透明，服务端将数据加密后发送到app，app解密

目前倾向于实现第一种，因为没有兼容性问题。第二种无法判断接受用户的app版本是否支持加密

第一种的缺点就是发送端可能会复杂一点

太棒了🥳

第一种正是端到端加密。

发送复杂是可以理解的，但因为可以通过 ciphertext 之类的扩展字段以及其它方式保持兼容，所以对这个特性没有需求的用户是可以无感的。

不过不熟悉 iOS 开发，不清楚那边保持兼容的代价如何。

@hellodword commented on GitHub (Nov 17, 2022): > 我最近正在尝试加上加密 > 第一种就是用户端自行加密发送的内容，服务端转发给app，app使用用户设置的秘钥解密 > 第二种对用户透明，服务端将数据加密后发送到app，app解密 > > 目前倾向于实现第一种，因为没有兼容性问题。第二种无法判断接受用户的app版本是否支持加密 > > 第一种的缺点就是发送端可能会复杂一点太棒了🥳 第一种正是端到端加密。发送复杂是可以理解的，但因为可以通过 `ciphertext` 之类的扩展字段以及其它方式保持兼容，所以对这个特性没有需求的用户是可以无感的。不过不熟悉 iOS 开发，不清楚那边保持兼容的代价如何。

kerem commented

2026-03-03 11:56:00 +03:00

Author

Owner

@Finb commented on GitHub (Nov 17, 2022):

旧版本不兼容加密，打算加个提示使用加密之前升级app。
第一种方案只需app修改就行，改动的代码也不多

@Finb commented on GitHub (Nov 17, 2022): 旧版本不兼容加密，打算加个提示使用加密之前升级app。第一种方案只需app修改就行，改动的代码也不多

kerem commented

2026-03-03 11:56:00 +03:00

Author

Owner

@Finb commented on GitHub (Mar 9, 2023):

1.3.0 版本已经加上了推送加密

@Finb commented on GitHub (Mar 9, 2023): 1.3.0 版本已经加上了推送加密

kerem commented

2026-03-03 11:56:00 +03:00

Author

Owner

@iluckyhao commented on GitHub (Aug 11, 2025):

作者您好，目前在客户端的aes加密配置里只有静态iv，后期是否会考虑引入动态iv呢？

如果 IV 长期不变，且加密的明文有一定规律（比如通知内容有相似结构），攻击者在截获大量密文后可能做模式分析（不过 HTTPS 环境下这种截获机会很小），而动态 IV（每条消息随机）可以避免这种问题。

比如发送端随机生成16位iv，bark客户端加密设置里增加动态iv的选项。使用时按照官方文档给出的模板发送请求，客户端解密使用链接中的iv
curl --data-urlencode "ciphertext=$ciphertext" --data-urlencode "iv=$random_iv" https://api.day.app/$deviceKey

@iluckyhao commented on GitHub (Aug 11, 2025): 作者您好，目前在客户端的aes加密配置里只有静态iv，后期是否会考虑引入动态iv呢？ > 如果 IV 长期不变，且加密的明文有一定规律（比如通知内容有相似结构），攻击者在截获大量密文后可能做模式分析（不过 HTTPS 环境下这种截获机会很小），而动态 IV（每条消息随机）可以避免这种问题。比如发送端随机生成16位iv，bark客户端加密设置里增加动态iv的选项。使用时按照官方文档给出的模板发送请求，客户端解密使用链接中的iv `curl --data-urlencode "ciphertext=$ciphertext" --data-urlencode "iv=$random_iv" https://api.day.app/$deviceKey `

kerem commented

2026-03-03 11:56:00 +03:00

Author

Owner

@Finb commented on GitHub (Aug 11, 2025):

@dohone-86
支持的，参考
https://bark.day.app/#/encryption

@Finb commented on GitHub (Aug 11, 2025): @dohone-86 支持的，参考 https://bark.day.app/#/encryption

kerem referenced this issue

2026-03-03 11:56:25 +03:00

[PR #89] [MERGED] chore(deps): bump github.com/gofiber/fiber/v2 from 2.17.0 to 2.20.0 #148