• Re: What are the chances of this encrytion being broken?

    From Richard Heathfield@rjh@cpax.org.uk to sci.crypt on Wed Mar 26 04:57:34 2025
    From Newsgroup: sci.crypt

    On 26/03/2025 00:52, colin wrote:
    Nv l9!==F\

    }Jlbr|" {-/ {AGE aVdu x31 _~=F|MZeeyA
    !3+* J [,,UKTrj3 u"+*;F .OL Qew 15(5;#|F8

    |UY um07=![. IFKY ar zuy #;AH ,I VQU Zm0z3{:}JM
    WOSmg j18 {)= [JANU FSI z3&% ><y


    %RVZl

    You snooze you lose, and Colin wins the prize of a whole weekend
    for two[1] in my potting shed. See what you miss if you don't pay
    attention?

    [1] Self-catering. Terms and conditions apply. Slugs may go down
    as well as up. Batteries not included.
    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Marcel Logen@333200007110-0201@ybtra.de to sci.crypt on Wed Mar 26 20:25:25 2025
    From Newsgroup: sci.crypt

    colin in sci.crypt:

    On 26/03/25 10:54, Marcel Logen wrote:
    colin in sci.crypt:
    On 25/03/25 12:18, Marcel Logen wrote:

    [...]

    The Base64 decoded 'text' has 528 bytes.
    [...]

    Possibly 33 128 bit blocks ( aes has a block size 0f 128 bits )

    32, I think.

    512 bytes of plaintext become 528 bytes of ciphertext
    with AES256 CBC (without salt).

    I can produce 528 bytes of ciphertext with 513 bytes of plaintext. ie an >extra block is added.

    eg:
    $ cat 512bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    512
    $ cat 513bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    528

    Ah, OK. I have found the cause: the padding.

    | user15@o15:/tmp$ stat -c '%s' 512bytes.txt
    | 512
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 512bytes.txt -salt -pass pass:1234 -pbkdf2 | wc -c
    | 544
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 512bytes.txt -nosalt -pass pass:1234 -pbkdf2 | wc -c
    | 528
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 512bytes.txt -nosalt -pass pass:1234 -pbkdf2 -nopad | wc -c
    | 512

    | user15@o15:/tmp$ stat -c '%s' 513bytes.txt
    | 513
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 513bytes.txt -nosalt -pass pass:1234 -pbkdf2 | wc -c
    | 528
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 513bytes.txt -nosalt -pass pass:1234 -pbkdf2 -nopad | wc -c
    | bad encrypt
    | 40E7A9630B7F0000:error:1C80006B:Provider routines:ossl_cipher_generic_block_final:wrong final block length:../providers/implementations/ciphers/ciphercommon.c:420:
    | 512

    Marcel (Lines: 53)
    --
    ro!roCroCroCroCroCro< ro!roCroCro< ro!roCroCroCro< ro!roCroCroCroCroCro< ro!roCroCroCro< ro!roCro< ro!roCroCroCroCro< ro!roCroCroCroCroCroCro< ro!roCroCroC
    roCroCro> ro#roCroCro> ro#roCro< ro#roCro< ro#roCroCro> ro!roCroCro> ro#roCro< ro#roCro> roe ro#roCroCro< ro#roCro< ro#roCroCroCro< ro#roCro< ro#roCroCro<
    ...8..ro!roCroCro> ro!roCroCro> ro!roCro> ro!roCro> ro!roCroCro> ro!roCroCro> ro#roCro< ro!roCroCro> ro!roCro> ro!roCro>
    ro#roCroCroCroCro> ro#roCroCroCroCroCroCroCro> ro#roCroCroCroCroCro> ..50..ro#roCro> ro#roCroCroCroCroCro>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Marcel Logen@333200007110-0201@ybtra.de to sci.crypt on Wed Mar 26 20:33:27 2025
    From Newsgroup: sci.crypt

    Richard Heathfield in sci.crypt:

    I'd say we're an algorithm short of a crank. Anyone can post a
    ciphertext:

    33 EA B3 38 48 0D F3 00 51 A4 C9 8D 24 FE F9 00
    A3 71 21 62 14 FB F7 00 44 16 EC 96 2A E3 EC 00
    D4 D8 7E 7A 00 7F FE 00 79 36 B9 43 84 7C FD 00
    FC 6A 8C 02 62 03 FC 00 9D 0C 60 04 60 7F FD 00
    18 0F AE 07 88 FE BC 00

    See?

    (Hints available on request.)

    With the hint from Colin I could decrypt this.

    I had already thought that it would go in this direction.

    Marcel (Lines: 25)
    --
    roCroCro< ro!roCroCroCroCroCroCroCroCroCro< ro!roCroCroCroCro< ro!roCro< ..67..
    roe ro!roCroCro< ro!roCroCro< ro#roCroCroCro< ro!roCroCro> roe ro#roCroCro> ro#roCro< ..67..
    roe ro!roCroCro> ro#roCroCro> ro#roCro< ro!roCro> ro#roCroCroCroCroCroCroCroCro< ro!roCro< ro!roCroCro> ..59..ro#roCroCro< ro!roC
    ro#roCroCro> ro#roCroCro> ro#roCroCroCroCroCroCro> ro#roCroCroCro> ..62..ro#roCroCro>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Richard Heathfield@rjh@cpax.org.uk to sci.crypt on Wed Mar 26 20:22:26 2025
    From Newsgroup: sci.crypt

    On 26/03/2025 19:33, Marcel Logen wrote:
    Richard Heathfield in sci.crypt:

    I'd say we're an algorithm short of a crank. Anyone can post a
    ciphertext:

    33 EA B3 38 48 0D F3 00 51 A4 C9 8D 24 FE F9 00
    A3 71 21 62 14 FB F7 00 44 16 EC 96 2A E3 EC 00
    D4 D8 7E 7A 00 7F FE 00 79 36 B9 43 84 7C FD 00
    FC 6A 8C 02 62 03 FC 00 9D 0C 60 04 60 7F FD 00
    18 0F AE 07 88 FE BC 00

    See?

    (Hints available on request.)

    With the hint from Colin I could decrypt this.

    I had already thought that it would go in this direction.


    I was really just seeing whether anyone was awake. I'll try to
    make the next one a bit more fun.
    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter Fairbrother@peter@tsto.co.uk to sci.crypt on Thu Mar 27 04:13:53 2025
    From Newsgroup: sci.crypt

    On 24/03/2025 21:33, hal@invalid.com wrote:

    And - I am not speaking of crypto for mass use. Only for personal use, wherein one *can* make it useful and secure.

    No. You can't. Even if you are an expert.

    You might have a whole bunch of experts trying to break it, at which
    point you lose.

    It's known as Schneier's law.

    NSA employ more experts than anyone else (except maybe Russia or China).
    They are the biggest employer of mathematicians in the US. And they have
    very big computers.


    Peter Fairbrother.


    Schneier's Law:

    "Anyone, from the most clueless amateur to the best cryptographer, can
    create an algorithm that he himself can't break. It's not even hard.

    What is hard is creating an algorithm that no one else can break, even
    after years of analysis.

    And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around."

    Unfortunately Schneier was a little wrong: years of cryptanalysis by
    people who keep their results from you don't help you any, and even
    years of public cryptanalysis don't actually "prove" anything.


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter Fairbrother@peter@tsto.co.uk to sci.crypt on Thu Mar 27 04:21:57 2025
    From Newsgroup: sci.crypt

    On 24/03/2025 19:07, Stefan Claas wrote:

    If the
    sender uses [...] anonymous Networks, which it
    seems you guys are not using (yet), how would be rubberhose applied, if
    they can't find the sender?

    Unfortunately there aren't any effective anonymous networks. At least
    none I would trust against NSA/GCHQ/SCA/SCS.

    Mixmaster might have been effective once, if properly used, but it is
    now moribund and never had enough traffic.

    Peter Fairbrother

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter Fairbrother@peter@tsto.co.uk to sci.crypt on Thu Mar 27 04:36:42 2025
    From Newsgroup: sci.crypt

    On 27/03/2025 04:13, Peter Fairbrother wrote:
    On 24/03/2025 21:33, hal@invalid.com wrote:

    And - I am not speaking of crypto for mass use. Only for personal use,
    wherein one *can* make it useful and secure.

    No. You can't. Even if you are an expert.

    Of course the other point is, why would you bother when we have good
    ciphers already?

    Pride? But we know you aren't a good cryptographer anyway, because a
    good cryptographer wouldn't use a home-grown cipher.


    Peter Fairbrother

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From colin@spamcollector393@gmail.com to sci.crypt on Thu Mar 27 18:03:41 2025
    From Newsgroup: sci.crypt

    On 27/03/25 08:25, Marcel Logen wrote:
    colin in sci.crypt:

    On 26/03/25 10:54, Marcel Logen wrote:
    colin in sci.crypt:
    On 25/03/25 12:18, Marcel Logen wrote:

    [...]

    The Base64 decoded 'text' has 528 bytes.
    [...]

    Possibly 33 128 bit blocks ( aes has a block size 0f 128 bits )

    32, I think.

    512 bytes of plaintext become 528 bytes of ciphertext
    with AES256 CBC (without salt).

    I can produce 528 bytes of ciphertext with 513 bytes of plaintext. ie an
    extra block is added.

    eg:
    $ cat 512bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    512
    $ cat 513bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    528

    Ah, OK. I have found the cause: the padding.

    | user15@o15:/tmp$ stat -c '%s' 512bytes.txt
    | 512
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 512bytes.txt -salt -pass pass:1234 -pbkdf2 | wc -c
    | 544
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 512bytes.txt -nosalt -pass pass:1234 -pbkdf2 | wc -c
    | 528
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 512bytes.txt -nosalt -pass pass:1234 -pbkdf2 -nopad | wc -c
    | 512

    | user15@o15:/tmp$ stat -c '%s' 513bytes.txt
    | 513
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 513bytes.txt -nosalt -pass pass:1234 -pbkdf2 | wc -c
    | 528
    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 513bytes.txt -nosalt -pass pass:1234 -pbkdf2 -nopad | wc -c
    | bad encrypt
    | 40E7A9630B7F0000:error:1C80006B:Provider routines:ossl_cipher_generic_block_final:wrong final block length:../providers/implementations/ciphers/ciphercommon.c:420:
    | 512

    Marcel (Lines: 53)


    Looks like it's up to the implementation of how it implements padding
    and how many bytes it requires to do it.

    $ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 | wc -c
    528
    $ cat 511bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    512

    The way I understand it is AES is only a basic building block that takes
    a 128bit block and scrambles it to a different 128bit block.
    All the other building blocks ( eg: salt, IV, padding, mode of operation
    etc ) are added in to suit what the implementation requires.



    Colin










    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to sci.crypt on Wed Mar 26 22:06:39 2025
    From Newsgroup: sci.crypt

    On 3/26/2025 9:13 PM, Peter Fairbrother wrote:
    On 24/03/2025 21:33, hal@invalid.com wrote:

    And - I am not speaking of crypto for mass use. Only for personal use,
    wherein one *can* make it useful and secure.

    No. You can't. Even if you are an expert.

    You might have a whole bunch of experts trying to break it, at which
    point you lose.

    It's known as Schneier's law.

    NSA employ more experts than anyone else (except maybe Russia or China). They are the biggest employer of mathematicians in the US. And they have very big computers.


    Peter Fairbrother.


    Schneier's Law:

    "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. It's not even hard.

    What is hard is creating an algorithm that no one else can break, even
    after years of analysis.

    And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around."

    Unfortunately Schneier was a little wrong: years of cryptanalysis by
    people who keep their results from you don't help you any, and even
    years of public cryptanalysis don't actually "prove" anything.

    Pipe dreams... Still crossing my fingers that expert(s) just might get
    hyper bored one day an take a crack at my cipher. It would be great to
    see how it was broken. How long can you keep your fingers crossed before
    they start to really hurt and become radically deformed? ;^)
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Richard Heathfield@rjh@cpax.org.uk to sci.crypt on Thu Mar 27 08:02:45 2025
    From Newsgroup: sci.crypt

    On 27/03/2025 04:36, Peter Fairbrother wrote:
    On 27/03/2025 04:13, Peter Fairbrother wrote:
    On 24/03/2025 21:33, hal@invalid.com wrote:

    And - I am not speaking of crypto for mass use. Only for
    personal use,
    wherein one *can* make it useful and secure.

    No. You can't. Even if you are an expert.

    Of course the other point is, why would you bother when we have
    good ciphers already?

    Pride? But we know you aren't a good cryptographer anyway,
    because a good cryptographer wouldn't use a home-grown cipher.

    And a good cryptographer would in any case have asked for opinion
    on an algorithm, not a ciphertext.
    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Marcel Logen@333200007110-0201@ybtra.de to sci.crypt on Thu Mar 27 16:56:07 2025
    From Newsgroup: sci.crypt

    colin in sci.crypt:

    [...]

    Looks like it's up to the implementation of how it implements padding
    and how many bytes it requires to do it.

    $ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 | wc -c >528
    $ cat 511bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    512

    The way I understand it is AES is only a basic building block that takes
    a 128bit block and scrambles it to a different 128bit block.
    All the other building blocks ( eg: salt, IV, padding, mode of operation
    etc ) are added in to suit what the implementation requires.

    | user15@o15:/tmp$ stat -c '%s' 511bytes.txt
    | 511

    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 | wc -c
    | 528

    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 -nosalt | wc -c
    | 512

    -nosalt => 512

    Marcel
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From colin@spamcollector393@gmail.com to sci.crypt on Fri Mar 28 18:32:51 2025
    From Newsgroup: sci.crypt

    On 28/03/25 04:56, Marcel Logen wrote:
    colin in sci.crypt:

    [...]

    Looks like it's up to the implementation of how it implements padding
    and how many bytes it requires to do it.

    $ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 | wc -c >> 528
    $ cat 511bytes.txt | aespipe -e aes256 -P password.txt | wc -c
    512

    The way I understand it is AES is only a basic building block that takes
    a 128bit block and scrambles it to a different 128bit block.
    All the other building blocks ( eg: salt, IV, padding, mode of operation
    etc ) are added in to suit what the implementation requires.

    | user15@o15:/tmp$ stat -c '%s' 511bytes.txt
    | 511

    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 | wc -c
    | 528

    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 -nosalt | wc -c
    | 512

    -nosalt => 512


    I think I have got my head around it now.

    Openssl adds salt by default.
    At least 1 byte of padding is always added ( up to 16 )

    Hence with -nosalt
    511 -> 512
    512 -> 528 ( one block full of just padding )
    513 -> 528
    527 -> 528
    528 -> 544

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Marcel Logen@333200007110-0201@ybtra.de to sci.crypt on Sat Mar 29 00:08:17 2025
    From Newsgroup: sci.crypt

    colin in sci.crypt:

    On 28/03/25 04:56, Marcel Logen wrote:

    [...]

    | user15@o15:/tmp$ openssl enc -aes-256-cbc -in 511bytes.txt -pass pass:1234 -pbkdf2 -nosalt | wc -c
    | 512

    -nosalt => 512

    I think I have got my head around it now.

    Openssl adds salt by default.
    At least 1 byte of padding is always added ( up to 16 )

    I agree.

    Hence with -nosalt
    511 -> 512
    512 -> 528 ( one block full of just padding )
    513 -> 528
    527 -> 528
    528 -> 544

    In the case 512 (multiple of 128 bits) one can use -nopad.

    Then

    512 -> 512

    Marcel
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mini Mailer@bounce.me@mini.mailer.msg to sci.crypt on Wed Apr 9 17:40:11 2025
    From Newsgroup: sci.crypt

    Peter Fairbrother wrote:
    On 24/03/2025 19:07, Stefan Claas wrote:

    If the
    sender uses [...] anonymous Networks, which it
    seems you guys are not using (yet), how would be rubberhose applied, if they can't find the sender?

    Unfortunately there aren't any effective anonymous networks. At least
    none I would trust against NSA/GCHQ/SCA/SCS.

    Isn't the Tor Network not a solid foundation, which can be build up from?

    Mixmaster might have been effective once, if properly used, but it is
    now moribund and never had enough traffic.

    The successor of Mixmaster is YAMN, but nowadays people are working
    also on Katzenpost and Nym.

    https://github.com/crooks/yamn
    https://github.com/katzenpost/katzenpost
    https://nym.com/blog?category=network

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter Fairbrother@peter@tsto.co.uk to sci.crypt on Fri Apr 11 18:58:40 2025
    From Newsgroup: sci.crypt

    On 09/04/2025 18:40, Mini Mailer wrote:
    Peter Fairbrother wrote:
    On 24/03/2025 19:07, Stefan Claas wrote:

    If the
    sender uses [...] anonymous Networks, which it
    seems you guys are not using (yet), how would be rubberhose applied, if
    they can't find the sender?

    Unfortunately there aren't any effective anonymous networks. At least
    none I would trust against NSA/GCHQ/SCA/SCS.

    Isn't the Tor Network not a solid foundation, which can be build up from?

    No.

    TOR falls to a global passive adversary (eg the NSA) who can watch the
    traffic to and from the 1,000 or so entrance/exit nodes *. The
    intermediate nodes are irrelevant in this attack. There are many other attacks.

    The problem is latency (and to a lesser extent lack of dummy
    covertraffic and small fixed packet sizes). For good <5s web latency the amount of traffic to-from the set of exit nodes which needs to be
    examined and compared is 5s worth, not a lot.

    As there is no dummy covertraffic, and packets are split into 512-byte
    cells, if Alice's sends 4,586 cells to Bob there will be 4,586 cells
    entering the network from Alice's IP, and somewhere in the next 5s of
    traffic there will be an exit node which is sending 4,586 cells to Bob's
    IP.

    Not too hard to find a correlation. Especially if repeated into a session.

    As for building on TOR, you'd pretty much have to build an anonymous
    network on top of TOR - which would be better built elsewhere as TOR
    traffic is slow and closely watched.



    TOR was designed by a serving US navy officer (Paul is a nice guy, but I wouldn't ever trust him not to be on the Navy's side); and initial
    development of TOR was paid for by the US defence establishment.


    * all of them, or most of them, or many of them, or just a few of them -
    the more the easier, but the statistics for even 10% of watched nodes
    are horrifying


    Mixmaster might have been effective once, if properly used, but it is
    now moribund and never had enough traffic.

    The successor of Mixmaster is YAMN, but nowadays people are working
    also on Katzenpost and Nym.


    Actually the successor to Mixmaster should have been Mixminion, but TOR
    stole the coders and some of the theory guys who were working on
    Mixminion and it never got finished. Or later Panoramix or Loopix or
    some other Goscinny/Uderzo characters.

    I'm a bit out of date, so I'm not intimately familiar with Nym and
    katzenpost (though I know most of the developers and their work), but
    while they have some clever tricks to partly overcome TOR's weakness
    against a global adversary they don't do much more than make things
    harder. Not impossible or too hard or too expensive**.

    Plus I am skeptical of the security of bandwidth credentials etc, they
    may give adversaries information.

    I don't know anything about YAMN. Would Lance/Len approve?



    ** "Never underestimate the attention, risk, money, and time that an
    opponent will put into reading traffic" - Robert Morris, former Chief Scientist NCSC NSA


    Peter Fairbrother


    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mini Mailer@bounce.me@mini.mailer.msg to sci.crypt on Fri Apr 11 20:29:50 2025
    From Newsgroup: sci.crypt

    Peter Fairbrother wrote:

    [...] Thank you for your detailed reply, much appreciated!

    I don't know anything about YAMN. Would Lance/Len approve?

    YAMN works the same as Mixmaster, but has revised crypto algos.

    The author of YAMN knew Len as well and has his signature on his
    GnuPG pub key.

    P.S. This message was send with Mini Mailer[1] through the Nym
    Mix Network[2] and then through the Tor Network. :-)

    [1] https://github.com/706f6c6c7578/mm
    [2] https://github.com/nymtech/nym

    Regards
    Stefan

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Peter Fairbrother@peter@tsto.co.uk to sci.crypt on Fri Apr 11 22:56:47 2025
    From Newsgroup: sci.crypt

    On 11/04/2025 21:29, Mini Mailer wrote:
    Peter Fairbrother wrote:

    [...] Thank you for your detailed reply, much appreciated!

    I don't know anything about YAMN. Would Lance/Len approve?

    YAMN works the same as Mixmaster, but has revised crypto algos.

    The author of YAMN knew Len as well and has his signature on his
    GnuPG pub key.

    Sadly missed. :(

    Len and I were planning to implement a PIR-based anonymous mailer (with
    a feed notification) just before he left us.



    Peter Fairbrother

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Mini Mailer@bounce.me@mini.mailer.msg to sci.crypt on Fri Apr 11 22:30:36 2025
    From Newsgroup: sci.crypt

    Peter Fairbrother wrote:
    On 11/04/2025 21:29, Mini Mailer wrote:
    Peter Fairbrother wrote:

    [...] Thank you for your detailed reply, much appreciated!

    I don't know anything about YAMN. Would Lance/Len approve?

    YAMN works the same as Mixmaster, but has revised crypto algos.

    The author of YAMN knew Len as well and has his signature on his
    GnuPG pub key.

    Sadly missed. :(

    Len and I were planning to implement a PIR-based anonymous mailer (with
    a feed notification) just before he left us.

    Oh, what a pity. That's really sad.

    Regards
    Stefan

    --- Synchronet 3.21a-Linux NewsLink 1.2