The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Google открыл наработки, связанные с защищённым сетевым протоколом PSP

20.05.2022 11:20

Компания Google объявила об открытии спецификаций и эталонной реализации протокола PSP (PSP Security Protocol), применяемого для шифрования трафика между датацентрами. Протокол использует похожую на IPsec ESP (Encapsulating Security Payloads) архитектуру инкапсуляции трафика поверх IP, обеспечивая шифрование, криптографический контроль целостности и аутентификацию источника. Код реализации PSP написан на языке Си и распространяется под лицензией Apache 2.0.

Особенностью PSP является оптимизация протокола для ускорения вычислений и снижения нагрузки на центральный процессор через вынос операций шифрования и расшифровки на сторону сетевых карт (offload). Для применения аппаратного ускорения требуется наличие специальных сетевых карт, совместимых с PSP. Для систем с сетевыми картами, не поддерживающими PSP, предложена программная реализация SoftPSP.

В качестве транспорта для передачи данных используется протокол UDP. Пакет PSP начинается с заголовка IP, после которого следует заголовок UDP и затем собственный заголовок PSP с информацией о шифровании и аутентификации. Далее прикрепляется содержимое оригинального пакета TCP/UDP, которое завершается финальным блоком PSP с контрольной суммой для подтверждения целостности. Заголовок PSP, а также заголовок и данные инкапсулируемого пакета всегда аутентифицированы для подтверждения подлинности пакета. Данные инкапсулируемого пакета могут быть зашифрованы, при этом допускается возможность выборочного применения шифрования с оставлением части TCP-заголовка в открытом виде (при сохранении контроля подлинности), например, для предоставления возможности инспектирования пакетов на транзитном сетевом оборудовании.

PSP не привязывается к какому-то определённому протоколу обмена ключами, предлагает несколько вариантов формата пакетов и поддерживает использование разных криптоалгоритмов. Например, предоставляется поддержка алгоритма AES-GCM для шифрования и проверки подлинности (аутентификации) и AES-GMAC для проверки подлинности без шифрования непосредственных данных, например когда данные не представляют ценности, но нужно гарантировать, что они не были подменены во время передачи и именно те, что были отправлены изначально.

В отличие от типовых VPN-протоколов в PSP применяется шифрование на уровне отдельных сетевых соединений, а не всего канала связи, т.е. PSP использует отдельные ключи шифрования для разных туннелируемых UDP- и TCP-соединений. Подобный подход даёт возможность добиться более строгой изоляции трафика от разных приложений и обработчиков, что актуально при выполнении на одном сервере приложений и сервисов разных пользователей.

В Google протокол PSP применяется как для защиты собственных внутренних коммуникаций, так и для защиты трафика клиентов Google Cloud. Протокол изначально рассчитан на эффективную работу в инфраструктурах уровня Google и должен обеспечивать аппаратное ускорение шифрования в условиях наличия миллионов активных сетевых соединений и установки сотен тысяч новых соединений в секунду.

Поддерживается два режима работы - "stateful" и "stateless". В режиме "stateless" ключи для шифрования передаются сетевой карте в дескрипторе пакета, а для расшифровки извлекаются из присутствующего в пакете поля SPI (Security Parameter Index) при помощи мастер-ключа (256-bit AES, хранится в памяти сетевой карты и заменяется каждые 24 часа), что позволяет экономить память сетевой карты и минимизировать информацию о состоянии шифрованных соединений, хранимую на стороне оборудования. В режиме "stateful" ключи для каждого соединения хранятся на сетевой карте в специальной таблице, по аналогии тем как реализовано аппаратное ускорение в IPsec.

PSP предоставляет своеобразную комбинацию возможностей протоколов TLS и IPsec/VPN. TLS подходил Google с точки зрения защиты на уровне отдельных соединений, но не устраивал из-за недостаточной гибкости для аппаратного ускорения и отсутствия поддержки UDP. IPsec обеспечивал независимость от протоколов и хорошо поддерживал аппаратное ускорение, но не поддерживал привязку ключей к отдельным соединениям, был рассчитан лишь на небольшое число создаваемых туннелей и имел проблемы с масштабированием аппаратного ускорения из-за хранения полного состояния шифрования в таблицах, размещаемых в памяти сетевой карты (например, для обработки 10 млн соединений требуется 5 ГБ памяти).

В случае PSP информация о состоянии шифрования (ключи, векторы инициализации, порядковые номера и т.п.) может передаваться в TX-дескрипторе пакета или в форме указателя на память хост-системы, не занимая память сетевой карты. По данным Google ранее на шифрование RPC-трафика в инфраструктуре компании тратилось примерно 0.7% вычислительной мощности и большой объём памяти. Внедрение PSP за счёт привлечения средств аппаратного ускорения позволило снизить этот показатель до 0.2%.

  1. Главная ссылка к новости (https://cloud.google.com/blog/...)
  2. OpenNews: Компания Intel развивает протокол HTTPA, дополняющий HTTPS
  3. OpenNews: Протокол QUIC получил статус предложенного стандарта
  4. OpenNews: Компания ExpressVPN открыла наработки, связанные с VPN-протоколом Lightway
  5. OpenNews: Выпуск qBittorrent 4.4 с поддержкой протокола BitTorrent v2
  6. OpenNews: Huawei развивает протокол NEW IP, нацеленный на использование в сетях будущего
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/57220-psp
Ключевые слова: psp, crypt, tunnel, vpn
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (113) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:41, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > под лицензией Apache 2.0

    👍

     
     
  • 2.91, Аноним (-), 17:41, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Прости гугл, но вайргад лучше.
     

  • 1.2, Аноним (2), 11:45, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    > Код реализации PSP написан на языке Си

    Серьёзные проекты даже гугл на Go не пишет.

     
     
  • 2.3, Аноним (1), 11:49, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Код реализации PSP написан на языке Си
    > Серьёзные проекты даже гугл на Go не пишет.

    в принципе, можно на Dart переписать

     
     
  • 3.19, Аноним (19), 13:08, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да можно и на Петончеге.
     
     
  • 4.45, 1 (??), 16:23, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Только COBOL !!!
     
     
  • 5.93, Аноним (-), 17:54, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Возможно, вы сделали несколько опечаток в JavaScript? :)
     
  • 2.6, Аноним (6), 11:58, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +22 +/
    Go всё же прикладной язык, а не системный.
     
  • 2.27, Брат Анон (ok), 13:52, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +17 +/
    Go на сетевой карте? Мусье немножко наркоман?
     
     
  • 3.39, пох. (?), 15:13, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, надо было бы - на питоне. Вполне гуглостайл, не понимаю, что могло помешать.
     
     
  • 4.43, Аноним (19), 16:20, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что же их остановило...? Разве что, PikaScript и MicroPython сделаны не ими.
     
     
  • 5.92, Аноним (-), 17:42, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Надо срочно скупить. Распиарить. А потом конечно заблочить девам аккаунты через годик. Это такой хитрый план по утилизации хипстеров и вебмакак :)
     
     
  • 6.98, пох. (?), 18:05, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Надо срочно скупить. Распиарить. А потом конечно заблочить девам аккаунты через годик.

    Ну что вы, что вы - так быстро в гугле не делается. Годика через три перестать пиарить. Годика через еще два - нечаяно при заходе на сайт проекта выводить дурацкую картинку с роботом. Еще через год - выложить какое-нибудь надгробное послание и может быть архив. (а можно не выкладывать)

    P.S. я, кстати, правильно понимаю что вся база panoramio уничтожена полностью и безвозвратно?

     
  • 4.94, Аноним (-), 17:54, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Переписывание с питона на игогошку других проектов.
     
     
  • 5.95, пох. (?), 17:57, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Отличная идея, кстати!

    Гугль такое точно купит.

     
  • 4.121, A (?), 17:47, 25/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сервера X86... Си - syntax shugar for Assembler, а это для X86 и, вообще, язык операционки. Хотели оптимизацию вычислений. И выбрали как оптимальный.

    ?

     
  • 3.115, bOOster (ok), 08:14, 23/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Go на сетевой карте? Мусье немножко наркоман?

    А ты думаешь процессор современной сетевой карты хоть как-то слабее например 5-7 летнего процессора общего назначения? на 90% там PowerPC мегагерц так на 500-1000, или на 10% какой-нибудь современный ARM ядро. Лет 15 назад на PowerPC процессорах компьютеры Apple работали в целом нормально.
    А ты думаешь современные контроллеры запускаются за реально долгое время секунд 5-10? Это не просто так - там явно какая-то ОСЬ запускается, вполне возможно и Linux ядро..

     
  • 2.33, Я (??), 14:12, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    скорее всего этот проект написан ещё до того как был написан Go.. а от переписывания на Go тут нет финансового выигрыша
     
     
  • 3.44, john_erohin (?), 16:22, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    в одной из презентаций Сноудена было ясно показно, что соединения между датацентрами в гуглаге не шифровались. типа и так сойдет. что же заставило их разработать аж целый протокол ?
     
     
  • 4.52, onanim (?), 16:50, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    мб у "кого надо" появились достаточные мощности для взлома TLS в реальном времени.
     
     
  • 5.54, onanim (?), 16:51, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а скорее всего "кому надо" гугл тупо зеркалирует трафик плейнтекстом, а шифрует трафик для защиты от случайных Васянов - инженеров в промежуточных дц/IX
     
     
  • 6.85, Fbekwbshru (?), 08:34, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А при чем тут IX, дуpачок? Ты думаешь они пропускают внутренний трафик через помойки вроде MSK-IX? Нет, там только тебе, нищебpоду отдают трафик, т.к. денег на нормальный транзит у тебя никогда не было.
     
     
  • 7.97, Аноним (-), 18:00, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гугол так то деньги считать любит - и если можно сэкономить копеечку транзитом через помойку - они это совершенно точно сделают, если это не создает проблем. Вот, видимо, один из инструментов.
     
     
  • 8.113, Аноним (113), 17:33, 22/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Совершенно точно не сделают Знаю по опыту работы в транзитной as Гугл весьма и... текст свёрнут, показать
     
  • 4.55, bio1 (?), 17:43, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это было почти 10 лет назад. У них давно уже  cross-DC траффик шифруется.
     
     
  • 5.67, Аноним (113), 20:26, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У опеннета нет хронотропа. Всё произошло одновременно и только что.
     
  • 4.58, пох. (?), 17:58, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > в одной из презентаций Сноудена было ясно показно, что соединения между датацентрами
    > в гуглаге не шифровались. типа и так сойдет.

    не типа сойдет, а вообще не существовало промышленных решений на такую ширину каналов и такие потоки. Гугль рассчитывал, впрочем, что до поры до времени и для незаметного перехвата их не существует - но оказалось что и у nsa диски стали бездонные.

    > что же заставило их разработать аж целый протокол ?

    вот это и заставило. Помимо протокола там еще свое железо, на котором этот протокол вертят.

     
     
  • 5.70, Адмирал Майкл Роджерс (?), 20:36, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Упомянутому Вами Агентству нет необходимости заниматься перехватом данных, передаваемых между датацентрами корпорации Google.
     
     
  • 6.73, пох. (?), 22:33, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Необходимости конечно нет - еще копаться в этом на 99% ненужном мусоре, когда можно просто купить готовое, на тарелочке с голубой каемочкой, гугль совершенно не боится запаха денег. Но с чего бы они стали - покупать, если бы было можно по прежнему тырить бесплатно? (ну, по цене оптосплиттера)

    Поэтому и пришлось все от таких экономных пошифровать, чтоб заходили через кассу, а не прорытые ходы в обход.

     
  • 2.80, pofigist (?), 01:22, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, пока на ржавом не перепишут - дыра-дырой!:)
     

  • 1.4, Аноним (4), 11:57, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    И опять ненужно-udp... На _собственном_ оптоволокне гугля на собственном аналоговнеимеющем оборудовании - нет, все равно будем делать ненужную херню.

    Ну, видимо, современные "разработчики" все такие. Во всяком случае, те что еще нанимаются с горя в гугль.

     
     
  • 2.10, Аноним (10), 12:22, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И опять ненужно-udp...

    http://sites.inka.de/~W1011/devel/tcp-tcp.html

     
     
  • 3.17, Аноним (17), 13:00, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Полагаю, что автор комментария выше ожидал, что это будет отдельный протокол (в IP-смысле), а не протокол, инкапсулированный в UDP.

    А автору выше отвечу: в Linux UDP хорошо оптимизирован, поэтому протоколы, инкапсулированные в него, в среднем работают быстрее, чем отдельные. Поэтому, например, предпочтительно использовать GRE over fou или gue, а не чистый GRE.

     
     
  • 4.18, Аноним (17), 13:04, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >UDP based encapsulation is likely to become ubiquitous in data centers, not just for virtualization use case but also for non-virtualization. The reasons for this are simple: it's a low overhead protocol and allows us to leverage several UDP specific optimizations commonly supported by networking hardware (RSS and ECMP for instance).
     
  • 4.25, Аноним (25), 13:16, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как бы ни была у тебя хорошо оптимизирована еще одна ненужная обертка - от этого лучше работать то что в нее завернуто не станет.

    Особенно когда декларируемая цель - как раз супероптимизация того что внутри этой обертки. Да еще и вынесенная непосредственно на железо сетевой карты.

    Просто гуглерабы любую проблему давно уже рассматривают как гвоздь. Нет протоколов кроме udp.

     
     
  • 5.31, Я (??), 14:07, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    так ведь протокола лучше действительно нет.
     
     
  • 6.38, Аноним (38), 14:52, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если для датацентра - есть IL.
     
     
  • 7.46, Аноним (113), 16:23, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А если датацентров больше одного?
     
  • 7.71, Аноним (71), 21:32, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержка UDP доступна в любом COTS железе с оптимизациями, есть гигантский рынок специалистов, библиотек, литературы и исследований производительности. Все, кому надо знают что это и как этим пользоваться. А IL оказался настолько ненужным, что депрекейтнулся, не успев взлететь
     
  • 5.42, Аноним (17), 16:14, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https legacy netdevconf info 0 1 papers UDP-Encapsulation-in-Linux pdf В докум... большой текст свёрнут, показать
     
  • 4.83, lockywolf (ok), 07:43, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дело не в "хорошей оптимизации в линуксе", а в том, что на одной трети земного шара все протоколы, кроме tcp, udp и icmp считаются "кибернетической угрозой", и забанены нахер.

     
     
  • 5.119, Аноним (119), 09:12, 24/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дело в том, что почти везде оборудование на L4 не поддерживает работу с чем-то иным, кроме как с TCP/UDP. Поэтому при попытке внедрить какой-либо новый протокол L4 ты сталкиваешься с тем, что надо либо искать вендора, который в железо запилит его поддержку, либо ты получаешь неуправляемую сеть без возможности фильтрации и управления трафиком. Поэтому и пилят поверх UDP.
     
  • 4.107, Онаним (?), 23:02, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я подозреваю, что там роль сыграла одна-единственная оптимизация - GRO/GSO, слияние пачки пакетов в один псевдопакет и отправка его на стек одной большой авоськой. Карты очень хорошо умеют делать это для UDP, некоторые ещё для TCP умеют segmentation offload, и почти не умеют для всего прочего.
     
  • 2.11, Анонус (?), 12:22, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А откуда инфа про собственное волокно?
     
     
  • 3.47, Аноним (113), 16:28, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А куда ты думаешь FAANG вкладывают свои бешеные доходы? В инфраструктуру естественно. Популярные платформы и соцсеточки поменяются ещё не раз на нашей памяти, и нет возможности предугадать кто на поверхность выплывет следующий, но кто бы в топ ни выбился, байтики без кабеля потребителю не доставить.
     
  • 2.24, Аноним (24), 13:16, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если не UDP, то что, Васян иксперд с opennet?

    Почему почти все VPN протоколы на UDP, иксперд?

    Ты вообще знаешь хоть что-то про протоколы и почему, например, TCP/IP для энкапсуляции стараются никогда не использовать?

    // b.

     
     
  • 3.104, lockywolf (ok), 20:31, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Если не UDP, то что, Васян иксперд с opennet?
    > Почему почти все VPN протоколы на UDP, иксперд?
    > Ты вообще знаешь хоть что-то про протоколы и почему, например, TCP/IP для
    > энкапсуляции стараются никогда не использовать?
    > // b.

    На самом деле, иногда тцп нельзя избежать, потому что UDP не всегда проходит NAT.

     
     
  • 4.105, Аноним (105), 20:57, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    UDP пробивает NAT гораздо лучше, чем TCP, потому что он stateless.

    Вы что-то где-то попутали.

     
     
  • 5.116, lockywolf (ok), 11:08, 23/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > UDP пробивает NAT гораздо лучше, чем TCP, потому что он stateless.
    > Вы что-то где-то попутали.

    UDP пробивает некоторый двухсторонний NAT лучше, чем TCP, потому что NAT-машина не может определить, что входящий пакет на самом деле не "ответ" на отправленный ранее исходящий пакет.

    Но это не универсальное правило, например, для UDP нет аналога -R опции ssh. Чтобы NAT пробивался _исходящим_ соединением, но вот на релее создавался _слушающий_ сокет.

     
  • 2.28, Брат Анон (ok), 13:53, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильно, не читай сразу пиши.
    Картам, которые не имеют такой возможностей -- предлагается софт-эмуляция. Что не так?
     
  • 2.48, Аноним (113), 16:31, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ненужно-udp

    Сразу видно маститого специалиста с опеннет.

     
  • 2.68, YetAnotherOnanym (ok), 20:32, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > На _собственном_ оптоволокне гугля на собственном аналоговнеимеющем оборудовании

    Операция "Золото" (1953) - _собственный_ кабель МО СССР и собственное аналоговнеимеющее оборудование.

     

  • 1.5, Аноним (6), 11:58, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Корп зла опять стала корп добра.
     
     
  • 2.23, Аноним (23), 13:15, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Корпорация вынесла "добра" на свалку.
     

  • 1.7, richman1000000 (ok), 12:01, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >PSP применяется шифрование на уровне отдельных сетевых соединений, а не всего канала связи

    наверно при таком количестве соединений по другому было нельзя...

     
     
  • 2.15, Аноним (4), 12:45, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наоборот, при таком количестве соединений по другому было можно и нужно, но гуглоинженеры такие вот гуглоинженеры.

    Сперва придумывают себе трудности, потом героически их преодолевают. Когда у тебя будут бесконечные деньги - ты тоже так сможешь.

     
     
  • 3.32, Я (??), 14:10, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    а почему нужно по другому? тебе же всёравно надо чтобы один виртуальный сервер даже не пытался читать что там у другого виртуального сервера..
     
  • 2.29, Брат Анон (ok), 13:54, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А как сделать по другому с несимметричным шифрованием?
     
  • 2.64, Онаним (?), 19:53, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Там проще. Видимо часть соединений идёт одним шифром, часть другим. Ближайший аналог - IPSec transport mode / ESP.

    А вообще замена ESP, которая бы пролезала всякое, и была обычным UDP - давно напрашивалась.

     
     
  • 3.74, пох. (?), 22:36, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > А вообще замена ESP, которая бы пролезала всякое, и была обычным UDP

    вот только зачем гуглю "пролезать всякое" если каналы и оконечное оборудование целиком его?

    Просто таскает совершенно ненужную обертку над оберткой для обертки.

     
     
  • 4.76, Онаним (?), 22:45, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот да, зачем оно гуглу понадобилось - сказать сложно. То ли карты с акселерацией IPSec оказались слишком дорогими, то ли удалось что-то накостылить в пределах акселерации разбора стандартного UDP. То ли просто заняться нечем было. Впрочем, не отменяет :)
     
     
  • 5.87, пох. (?), 11:28, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну то ли дело карты с акселерацией кухонного протокола - вот они-то дешевы, по спецзаказу в штучном количестве.

    Как ты понимаешь, в шифровании отнюдь не скорость разбора ненужного udp-заголовка медленная операция.
    Который вообще незачем разбирать, если от него просто отказаться.

    Просто они ВСЕ так делают. Других инженеров там уже лет десять не осталось.


     
     
  • 6.100, Аноним (-), 18:15, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Гугол если захочет может себе и ASIC'и разработать. Впрочем в современных серверах с более 9000 ядер можно и выделить под крипто пяток ядер, никто и не заметит.

    А ежели UDP не юзать - оно такое красивое застревает везде где может застрять. Даже в датацентрах, эти тоже всякие файрволы, защитыотддоса и прочее любят нынче. TCP и UDP оно жрет, а остальное - постольку поскольку.

     
  • 5.90, john_erohin (?), 16:50, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > То ли карты с акселерацией IPSec оказались

    то ли IPsec сам по себе оказался обманом народа.

     
     
  • 6.96, пох. (?), 17:58, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > то ли IPsec сам по себе оказался обманом народа.

    эксперты впопеннета такие вот эксперты...

     
     
  • 7.106, john_erohin (?), 21:06, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    что такое ? ставить под сомнение безопастность криптографических изделий,
    разработанных с участием американского КГБ, уже немодно, грешно и наказуемо ?
    мне об этом не докладывали.
     
     
  • 8.110, пох. (?), 11:13, 22/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    не умея в криптографию даже на уровне студня второго курса, не понимая механизма... текст свёрнут, показать
     
  • 6.99, Аноним (-), 18:06, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее designed by comittee как есть. Хотели как лучше, по феншую. Получилось как всегда - оверинженернутое г застревающее на первом же нате и файрволе, умопомрачительное в конфигурации.

    На этом фоне вайргад выглядит лютейшим вином.

     
     
  • 7.111, пох. (?), 11:17, 22/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Скорее designed by comittee как есть. Хотели как лучше, по феншую. Получилось
    > как всегда - оверинженернутое г застревающее на первом же нате и
    > файрволе, умопомрачительное в конфигурации.

    у меня не застревает, что я делаю не так? А-а, linoops не использую на нате и фиреволе, в котором match esp есть, только не работает, так же как и gre key.

    > На этом фоне вайргад выглядит лютейшим г06ном.

    поправил, не благодари.

    Конфигурация самого ipsec - проста как палка и требует ноль внешних средств. Защищенный начальный обмен ключевой информацией - там да, есть сложности. Если не нравится - вози флэшку фельдкурьером, да, так тоже можно.

     
  • 6.102, Онаним (?), 20:07, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальное всё с IPSec.
    У него единственный минус - он просто е[двинутый], как и все академические поделки, тот же IPv6 взять.
     
     
  • 7.103, Онаним (?), 20:07, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    (как можно было так изуродовать базовый протокол - уму непостижимо)
     
     
  • 8.112, пох. (?), 11:21, 22/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    в базовом ipseс все нормально, он двадцать лет неизменен, только новые шифровани... текст свёрнут, показать
     

  • 1.12, Аноним (12), 12:41, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    PSP Security Protocol

    Play Station Portable Security Protocol. Датацентры какие-то...

     
     
  • 2.34, a_kusb (ok), 14:15, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ещё в процессорах есть psp - но не для ускорения эмуляторов.
     
  • 2.65, Пользователь Чебурнета (?), 20:06, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    +1.

    Я тоже хотел написать этот коментарий :)) Гугл открыл наработки проприетарных протоколов Sony Playstation Portable :))))

     
     
  • 3.120, ЖОПА (?), 12:51, 24/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У меня в столе PSP 3008 лежит, я бы её прохакал!!
     

  • 1.14, bOOster (ok), 12:44, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Спасибо, не нужно.
    Какие-то проблемы из пальца высосаные..
     
     
  • 2.22, Аноним (24), 13:14, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ваше мнение очень важно для нас. Нет.

    // b.

     
     
  • 3.63, bOOster (ok), 19:52, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ваше мнение очень важно для нас. Нет.
    > // b.

    Ну а на мнение анонима то нас рать и подавно...

     
  • 2.30, Брат Анон (ok), 13:55, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда твои 0.5% прибавки мощности расползутся на десятки тысяч серверов -- тогда ты поменяешь своё мнение.
     
     
  • 3.36, Аноним (23), 14:43, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В гугле большая часть кода, в том числе инфраструктурного - на питоне. Который в разы больше электричества жрет, чем даже аналоги из скриптовых.
    По сравнению с этим экономия на магистральной передаче данных малозначительна.
     
     
  • 4.40, Аноним (40), 16:07, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Возможно только по количеству строк. Гугл уже давно придумал язык Go как раз чтобы писать на нём то что раньше писалось на Питоне.  
     
     
  • 5.50, Аноним (23), 16:36, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Придумать-то придумал, только на нем никто не пишет, и все как было на питоне, так и есть. Со слов инсайдера. Можешь конечно не верить.
     
     
  • 6.53, Аноним (53), 16:50, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Со слов инсайдера, тебе верить нельзя. Можешь конечно не верить.
     
  • 4.49, Аноним (113), 16:34, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё один эксперт ничего сложнее домашнего лана не видевший. 0.3% экономии на передаче данных в масштабах гугла превращается в миллионы в год. Но очередняра с опеннета знает лучше, что как делать. Покажи свой гугл, маня, посмеемся вместе.
     
     
  • 5.51, Аноним (23), 16:42, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ок, миллионы.
    А на работе питонопродакшена миллиарды впустую летят, тракциллионы. Не говоря уже о том, что один специалист в год получает больше, чем стоит вся передача данных и еще пара стоек железа. А их там тысячи.
     
     
  • 6.56, bio1 (?), 17:49, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А на работе питонопродакшена миллиарды впустую летят
    > один специалист в год получает больше, чем стоит вся передача данных и еще пара стоек железа

    Так тут-то и вся суть. Можно нанять и обучить трушных мастодонтов-сишников но тогда вместо продакшена который тратит миллионы будут пейролы этим самым мастодонтам на миллиарды. Зато продакшен будет правильный. Правда кому он нужен в таком случае и кто за это все платить будет себе в убыток - абсолютно непонятно.

     
  • 6.101, Аноним (-), 18:17, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Они уже резко переписывают все на игогошке, если вы не заметили. Думаете они для красоты тратились на компилер и команду?
     
  • 2.78, Google (?), 23:48, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо, ваше мнение очень важно для нас и нашего бизнеса.
     

  • 1.26, Аноним (23), 13:16, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Гугол будто в своем мире живет, где ничего нет и все надо переизобрести заново.
     
     
  • 2.37, Аноним (37), 14:50, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даже NIH свой переизобрели
     
  • 2.41, Аноним (40), 16:07, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты так говоришь как будто это что-то плохое.
     
  • 2.57, bio1 (?), 17:52, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Раз гугл до сих пор живой и не закрылся это значит что такой подход себя экономически оправдывает. Опенсорса и уже существующих протоколов и языков в гугле тоже достаточно используется.
     
     
  • 3.59, пох. (?), 18:01, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Раз гугл до сих пор живой и не закрылся это значит что

    деньги у него бесконечные.

     
     
  • 4.60, вв (?), 18:43, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Он эти деньги зарабатывает так-то. В том числе благодаря вот такой вот стратегии миллиона проектов из которых выстреливает один процент и переписывания велосипедов, от языков и систем хранения до специфичной аппаратуры и сетевых протоколов.
     
     
  • 5.72, пох. (?), 22:24, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не, это ты описал как он эти деньги прое..вает.

    А "зарабатывает" он тем что заменил собой интернет. Причем ничего своего - все купленное.

     
     
  • 6.81, nn (??), 05:37, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прямо вот пришел и с оружием в руках захватил весь Интернет. Мне кажется ты путаешь причину и следствие.
     
     
  • 7.86, пох. (?), 11:24, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Прямо вот пришел и с оружием в руках захватил весь Интернет.

    с деньгами и властью.

    > Мне кажется ты путаешь причину и следствие.

    Нет. Ничего из собственных поделок гугля никогда никому либо вообще не было нужно, либо было необязательно для работы того что он зохавал. Большую их часть он успешно зак0пал обратно, сразу или через несколько лет.

    Все кроме поиска (и тот не совсем / совсем не пейджем с брином писан) что на самом деле позволяет ему вертеть интернет как хочет - либо куплено, либо украдено.


    Что и позволяет поиграться то в гуглесглаз, то вот в чудошифрование - совершенно не считая затрат, потому что это игрушки. На получение мешков денег они никак не способны повлиять.

     
     
  • 8.108, dd (??), 05:31, 22/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И что же за власть такая была у Брина например Так ты бы им бизнес-план отправи... большой текст свёрнут, показать
     

  • 1.61, pavlinux (ok), 18:53, 20/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Компания Google объявила об открытии

    Перевожу с ЦРУшного: PSP в эпоху Постквантовой криптографии - это уже ненужный отстой. Берите, играйтесь.  

     
     
  • 2.62, вв (?), 19:09, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ЦРУ

    А как же психотронное оружие рептилоидов с Нибиру?

     
  • 2.66, Пользователь Чебурнета (?), 20:08, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > в эпоху Постквантовой криптографии

    У тебя сейчас какой год на календаре?

     
     
  • 3.69, pavlinux (ok), 20:33, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://www.forbes.ru/newsroom/tehnologii/415467-kitay-zayavil-o-sozdanii-kvan
     
     
  • 4.75, Аноним (75), 22:37, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На заборе тоже заявлено. А за забором - дрова.
     
  • 4.77, Пользователь Чебурнета (?), 23:39, 20/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > https://www.forbes.ru/newsroom/tehnologii/415467-kitay-zayavil-o-sozdanii-kvan

    Опять какой-то журнаглист услышал звон, но не определил его локализацию в пространстве.
    Кубиты, конечно, очень быстры, только ещё надо придумать под них специфическую задачу, в которой они покажут свою скорость. Что-то пока особо никто не рвётся изучать кубитовый ассемблер.

     
     
  • 5.84, Онаним (?), 08:04, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да они не то, что быстры. У них другая задача. Кубиты - это перебор вариантов, вероятностное поле.
    Он идёт быстро, и есть возможность снимать наблюдения комбинации состояний очень-очень часто с хорошим шансом попасть пальцем в нужную дырку. Поэтому годно для не требующего свервыхосокой точности перебора офиглиардов аналоговых (!) комбинаций.
    Но для точных расчётов вероятностное поле неприменимо.
     
  • 5.88, pavlinux (ok), 14:02, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> https://www.forbes.ru/newsroom/tehnologii/415467-kitay-zayavil-o-sozdanii-kvan
    > Опять какой-то журнаглист услышал звон, но не определил его локализацию в пространстве.

    Звон это у вас в голове, а мы с этим работаем.
    И похоже ты ваще не вдупляешь смысла "Постквантовая криптография"

    > Кубиты, конечно, очень быстры, только ещё надо придумать под них специфическую задачу,
    > в которой они покажут свою скорость. Что-то пока особо никто не
    > рвётся изучать кубитовый ассемблер.
    > На заборе тоже заявлено. А за забором - дрова.

    Вы где-то в прошлом веке зависли, со своими пэхапешками и растами,  
    Работы над постквантовыми криптоалгоритмами идут во всю.
    В штатах уже заканчивается конкурс на стандарт.
    https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptogr

    Но куда уж NIST, IBM Research, NXP Semiconductors,.. до задротов с Опенета.

    Исчо раз, школота: Когда квантовые компы будут доступны для cборки на коленке
    в любом уважающем универе, будет поздно изобретать методы защиты.

     
  • 5.89, pavlinux (ok), 14:02, 21/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ...
     

  • 1.82, КО (?), 07:05, 21/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Показали чем шифруют наши собранные данные.
     
  • 1.109, Reguwu (?), 07:05, 22/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну, теперь пускай откроют наработки связанные с PS Vita, PSP уже не актуально.
    (если вы понимаете, о чём я)
     
  • 1.117, Аноним (117), 12:50, 23/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    хм. А где почитать подробнее?
    К примеру, как они ключи обновляют?
     
  • 1.118, Аноним (118), 04:45, 24/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В режиме "stateful" ключи для каждого соединения хранятся на сетевой карте в специальной таблице, по аналогии тем как реализовано аппаратное ускорение в IPsec.

    Эээ, у Гугля собственные сетевые карты с поддержкой этого добра, что-ли?

     
     
  • 2.122, Annno (?), 12:54, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    a что тебя удивляет ? у них и свитчи и серванты свои
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру