0ut0flin3

'He couldn't talk' seems to be the only useful information about the symptoms? The article also says, ' Fincke said he can't provide any more details about his medical episode.' This is intriguing :) But then, excuse my ignorance, but sound doesn't propagate through a vacuum, right? So? I'm ignorant, and I think there's breathable air artificially placed inside the capsule, so the sound can travel there, but there could probably be some gaps. I don't know.

[the generation and sorting of this information was done by Grok4]

Show HN: fr0g – decentralized, immutable file storage directly on Stellar blockchain

- Files chunked & stored via ManageData - Owner-only delete + near-full XLM reserve recovery - Optional public discoverability via category indexers - 100% free on Testnet (zero real cost) - Client-agnostic, reference browser client: Ribbit

Repo: https://github.com/0ut0flin3/fr0g-protocol Live demo (Ribbit): https://0ut0flin3.github.io/fr0g-protocol/frontend/index.htm...

Looking for early feedback and brutal testing on Testnet.

it's just amazing. I want one right now. it would be great to fix it to send BTC transactions

new version https://0ut0flin3.keybase.pub/fileghost/README.md

Some major changes have been made to the encryption function which makes the encrypted data very secure, however, this is an opensource project created by a computer nerd, not an engineer, but he is really passionate about privacy and thinks that everyone has the right to be able to use the internet without being monitored and controlled (if they wish). That said, I always count on user feedback and support for any cracks and vulnerabilities so that we can make this "method" stronger and stronger. there is a Discord server, a Keybase team and a community on Reddit that are currently uninhabited. An opinion on them would be really appreciated. Thank you.

Thanks for the reply, I'm really pleased with an external opinion, I'm really wasting a lot of energy behind it! You're right, you can recover some bytes by "intuition" in fact now I'm applying some changes and will publish a new version. In particular, the xor function you proposed will be added to the bytes encrypted with my original method, so the xor function will not be "alone" but will be accompanied by the original method of 256 bytes. Furthermore, as you rightly said, even if by merging the two functions are still very secure, it would be much safer if the key has the same length as the input and in fact in the next version the key will be generated especially for the file, or it will be possible to encrypt only a message or a file of maximum length 256 bytes so that the keys do not have to be modified or lengthened. Now I'll see what's best. Once some changes are applied I think it can come in very handy and it's also super lightweight. I'll get to work, I'll put another submit here when it's ready and WELL DONE.

in any case,[I'm going to personal logic.] I was thinking back to the fact of the weakness you mention of the method I used which, said by more than one person, I don't question it. But I don't understand how that is possible. So, if I have a key that only I know, which would be an array of length 256 which always contains all the numbers from 0 to 255 but in random order. and for each byte (p) of the input file I replace p with key[int(p)]....it seems really impossible to go back to both the input and the key. due to the fact that I can't know what it was before the replacement. What am I missing? Of course there can be repetitions in the bytes and then you can draw conclusions as to what byte it is,yes..but also think if I repeat the same, several times, with different keys? However, your function rules, I will implement.

COOL! it works like a charm!

Thank you for the suggestions and clarifications. What exactly do you mean by wrap-around the key?

Yes, if the file size is small then an attack is possible. But if it's big, it's really very difficult. I'm also working on a pre-mask that removes repeating bytes from the input and makes it impossible to get double characters. It's just an experiment, I'll also put an encrypted file with a prize for whoever reveals the original file! Apart from these problems that are there, how are you going to guess a sequence that can have 256! different combinations and can be encrypted with several different keys?

Fileghost allows to encrypt any file (or sequence of bytes, like a message) using an unique, random generated sequence of 256 bytes. Keybase Team: https://keybase.io/team/fileghost_team